Design Problem: Modularizing Sockets

In the hope of some words of wisdom from you:

My telephone application (OS X) for calling and receiving calls via Mac grows, but I have come to a sudden halt realizing I have some serious design problem at its core.
Initially, I wanted to have a substitute for Gigaset’s Quicksync Software that doesn’t run on current MacOS X anymore. Basically it gives ways of synchronizing the phone books and a system service to dial from every string on the screen that can get selected.

My phone offers an ethernet connection, so I built everything around a timer-polled TCPsocket (a global instance that runs without any window being open). The Dataavailable event calls the parsing routine, which means that in case of an incoming call this will be shown on the monitor, including phonenumber, caller end the like. You get the idea.

Having found a few testers, I realized many phones are not connected via Ethernet but through USB or Bluetooth, so I need a Serial instead of a TCPsocket. Coming that way, I found it a nice idea to modularize the app even more so that it can handle several phones at once.

But this is where the problems start. Like said the core of the class is a TCPsocket. I could replace it by a Serial and change the few routines that are different in handling, but then I would have most of the code twice – the parsing and handling of its result is part of my module, as well as the properties it derives from parsing.
I thought of restructuring the class, making say the phone information the core and adding either a TCPsocket and a serial from which I could chose which one to use. This works basically, but the sockets’ event handlers are not accessible when I instantiate the ports as properties inside a class. I can subclass the sockets of course, but I cannot figure out how to have the data available event communicate with its parent. Of course I could have the data available event write its contents to a string buffer and have the main timer look for a change in it, but this would be too clumsy – when the socket fires event-driven, there should be no delay in processing its content.

How would you handle such a design when you are going for a nicely reusable and maintainable code instead of just making it work anyhow?

(In order to clarify, here’s the overall structure so far:)

[code]Class Telsocket (super TCPsocket) {

Timer: Polls the socket every soandso seconds

Event: Dataavailable fires Parse

Module: Parse performs Actions
Modules: Actions according to the parsed data, setting properties

Properties: being used by windows to display the phone status. }
[/code]

I tried to change it to something like

[code]Class Teldata (super Phonedata [a properties collection of individual phone parameters) {

Timer: Polls the socket every soandso seconds

Event: !! none available !!

Modules: Actions according to the parsed data, setting properties

Properties: TCPsocket and (!) Serial, only one being opened at a time. Their events only being accessible when I create a subclass – and inside this subclass, not in Teldata –, and they cannot access Teldata methods)
Properties: being used by windows to display the phone status. }[/code]

I bet there must be an easy way to design this, but I only programmed myself against the wall.

Would seem to me that you need to split the “inbound data receiver” (TCPSocket, serial, etc) from the “telephone handling”

Then the teldata can have a “data receiver property”

But the data receiver should probably be a subclass of serial or tcp socket that implements a common interface so the telephone handling code can generically deal with any kind of data receiver you create that implements the interface

Thanks, Norman. This whole data receiving this is still a mystery to me, and I find the manual a bit shallow on this topic. Do you know about some more resources on this?

the idea is to use an interface and has less to do with “data receiving”

say you create an interface “DataReceiver”
Then you create a subclass of TCPSocket that gets data from the ethernet based phone - it implements the DataReceiver interface
Then you create a subclass of Serial that gets data from the blue tooth / serial based phones - it implements the DataReceiver interface

Now I can’t say much about what the specifics of the might need as I don’t know your code
It probably needs a Poll method since you mention that
And some way to get the data received

So the TelData class can take an array of “DataReceivers” - poll them, get the data from them and it really doesn’t matter if the receiver is a tcp based one or a serial port one