0

I am given this set of code and need to suggest ways to improve the code's cohesion and coupling of the classes. But I thought these classes are quite well de-coupled since it looks like they are making use of events. And in terms of cohesion, all the init() calls are placed together, everything seems quite alright to me.

public class A
{
    private C t;
    private B g;
    public static void main(String args[]) {
        // Creates t and g.
        t = new C();
        t.init();
        g = new B();
        g.init();
        g.start(this);
    }
    pubic void update (Event e)
    {
        // Performs updating of t based on event
    }
}

public class C
{
    public C() { ... }
    public void init() { ... }
}

public class B
{
    public B() { ... }

    public void init() { ... }

    public void start(A s) {
        e = getNextEvent();
        while (e. type != Quit)
            if (e.type == updateB)
                update(e) ;
            else
                s.update(e) ;
        e = getNextEvent();
    }

    public void update(Event e) { ... }
    }
}

Are there still ways to improve the classes cohesion and coupling? It looks ok to me but I think I am missing something out.

Thanks for any suggestions on this.

3
  • 3
    Cohesion is a desirable characteristic but coupling is definitely not. Perhaps you misunderstand these terms. Jun 16, 2011 at 19:07
  • More specifically, tight coupling is undesirable. See en.wikipedia.org/wiki/Loose_coupling Jun 16, 2011 at 20:17
  • @Robert well, I view those as opposite ends of the "coupling" spectrum. Tight and loose are basically equivalent to more and less. Jun 17, 2011 at 0:22

3 Answers 3

2

Is the updating of t in A similar/the same as the update method in B?

If that's the case, then you can move that update logic into C.... but then you'll notice that B and C are duplicating behaviour... and can be 1 class instead, or at least can implement shared behaviour from a separate class (depending on what's in 'start()')

Reducing the coupling at that point, you can create an interface that defines init and update functionality (again, possibly 'start' as well... post the content and we might be able to better work with it).

I also wonder what init does, because if 'start' can't be called (and doesn't throw an exception if init isn't called) until init is called, then the object is possibly in an invalid state after construction. You might be able to take the logic from init and put it into 'start' or the constuctor.

1

C and A can be uncoupled by using interfaces.

With so much missing from this it's hard to say what else could be improved. Cohesion usually means a "measure" of how much a class is about one, solitary idea.

With that in mind, it is possible that C is doing too much by implementing an event loop. One might be inclined to make an event loop class that polls interfaces.

The if statement in start(A) looks like a fairly significant violation of the Liskov Substitution Principle.

0

Without knowing what the classes are supposed to do I'd say merge all three of them and it will be highly cohesive without any coupling (on the class level at least).

Class B is grabbing an event off off some queue and then distributing them to A or handling it himself. So class B is both distributing and handling events, this is poor cohesion, B is doing multiple things. Better cohesion would be for B to -only- distribute events. Creating a new class that would handle what B handles would increase cohesion.

Why not let A and B subscribe to the events themselves? That would remove B's distribution as the middle man and decrease coupling (B doesn't need to know the world of classes able to response to update events).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.