How to avoid class coupling when the specs insist on it

Question

I have two coupled classes DhcpServer and SessionManager. I got the following requirements in my specs that led to that coupling:

DhcpServer must not issue an IP address lease if SessionManager forbids that (e.g. an error occurred while creating a session)
SessionManager must start a session upon creation of a new lease by DhcpServer and destroy a session as soon as that lease expires or gets released explicitly by a client
On the other hand DhcpServer must destroy the lease if SessionManager stopped a corresponding session (e.g. by sysadmin's request)

At first it was tempting to put all the code into a single class. But the responsibilities were distinct, so I split them into two and created two interfaces:

class ISessionObserver(object):
    def onSessionStart(**kwargs): pass
    def onSessionStop(**kwargs): pass

class IDhcpObserver(object):
    def onBeforeLeaseCreate(**kwargs):
        """
        return False to cancel lease creation
        """
        pass
    def onLeaseCreate(**kwargs): pass
    def onLeaseDestroy(**kwargs): pass

Then I implemented IDhcpObserver in SessionManager and ISessionObserver in DhcpServer. And that led to coupling. Even though the classes do not depend on each other directly they do depend on the interfaces declared in each other's packages.

Later I want to add another protocol for session initiation leaving SessionManager's logic intact. I don't want it to implement IAnotherProtocolObserver as well.

Also DHCP server as such has nothing to do with my notion of session. And since there's no DHCP protocol implementation for Twisted (which I'm using) I wanted to release it as a separate project that has no dependencies neither on SessionManager nor on its package.

How can I satisfy my spec requirements while keeping the code pieces loosely coupled?

score 5 · Accepted Answer · answered Aug 23 '12 at 08:50

5

A good way to decouple classes is to use events.

So what you need to do is to "fire" events when something happens. Example: Send an event "session created" when the SessionManager could create a session. Make the DhcpServer listen for that event and prepare a lease when it receives it.

Now all you need is a third class which creates the other two and configures the event listeners.

The beauty of this solution that it keeps everything simple. When you write unit tests, you will always only need one of the classes because all you need is to check whether the correct event has been fired.

answered Aug 23 '12 at 08:50

Aaron Digulla

321,842
108
597
820

That's exactly what I was doing. My observer interfaces serve for the same purpose. But that doesn't fix the problem: `DhcpServer` would need to know the type of events `SessionManager` would fire and vice versa. That's the same coupling revised. – Ihor Kaharlichenko Aug 23 '12 at 08:57
As I said: You need a class between them which wires the events. It will take the "session created" event and then call the methods on the DHCP server and vice versa. Since this class is on a higher level than the other two, it can do the connection. This keeps the service classes clean. – Aaron Digulla Aug 23 '12 at 09:15
2

So, if I understood you correctly, my observer interfaces are ok. But instead of cross-implementing them in `DhcpServer` and `SessionManager` I should introduce a third one. This class would be a mediator that implements both observer interfaces and invokes methods of both `DhcpServer` and `SessionManager`, right? – Ihor Kaharlichenko Aug 23 '12 at 09:25
@IhorKaharlichenko: Yes, that's exactly right. Move the coupling to a "config" or "setup class – Aaron Digulla Aug 23 '12 at 09:38

How to avoid class coupling when the specs insist on it

1 Answers1