Is this considered low coupling & high cohesion? Any chance to improve?

Question

I'm trying to get hold of the SOLID principles by Robert C. Martin. Currently I'm looking into low coupling & high cohesion. I've created some code which represents my current understanding of this subject. Could you guys tell me if on the right track? Any chance to improve the current design?

Main app which creates two addresses and assigns these to the employee:

public class App {

    public static void main(String[] args) {
        Address homeAddress = new HomeAddress("This is my Home Address");
        Address workAddress = new WorkAddress("This is my Work Address");        
        Employee employee = new Employee(homeAddress, workAddress);

        employee.getAddresses();
    }

}

Employee class:

public class Employee {

    private Address homeAddress;
    private Address workAddress;

    Employee(Address homeAddress, Address workAddress) {
        this.homeAddress = homeAddress;
        this.workAddress = workAddress;
    }

    public void getAddresses() {
        System.out.println("homeAddress: " + homeAddress.getAddress());
        System.out.println("workAddress: " + workAddress.getAddress());
    }

}

Address interface:

public interface Address {

    String getAddress();

}

Specific Address implementation 1(HomeAddress):

public class HomeAddress implements Address {

    String specificAddress;

    public HomeAddress(String specificAddress) {
        this.specificAddress = specificAddress;
        System.out.println("In HomeAddress Constructor");
    }

    public String getAddress() {
        return specificAddress;
    }
}

Specific Address implementation 2(WorkAddress):

public class WorkAddress implements Address {

    String specificAddress;

    public WorkAddress(String specificAddress) {
        this.specificAddress = specificAddress;
        System.out.println("In WorkAddress Constructor");
    }

    public String getAddress() {
        return this.specificAddress;
    }
}

Any help/feedback would be greatly appreciated! Thanks in advance.

Marc.

Why do you need a type to discriminate a work address from a home address? In the code you provided, you are not enriching any of the subclasses with new functionalities, making them redundant. — Alexandre Dupriez, Nov 02 '18 at 10:30
Both addresses do the same. Maybe you actually don't need two implementations — Héctor, Nov 02 '18 at 10:30
Concerning low coupling and high cohesion your code is correct. But note that with a so light model, it is hard to not respect these principles. — davidxxx, Nov 02 '18 at 10:33
I agree. In this example both addresses do the same thing. So just one implementation would do it in this case. In case they both had a different implementation, I should've created two separate ones. Thank you. How do you guys think about the high cohesion and low coupling in this example? Am I doing the right thing here? — M. Groenhout, Nov 02 '18 at 10:36
@davidxxx Thank you. I understand that this is just a simple design. For me it's all about understanding the basics. — M. Groenhout, Nov 02 '18 at 10:38

score 0 · Accepted Answer · answered Nov 05 '18 at 11:49

It's a smallish example, but it could be improved in terms of coupling/cohesion.

The objects are cohesive. Why? In the Employee object both the constructor and the getAddresses() (which should be called printAddresses() by the way) refer to both instance variables (which means they are concerned with the same thing). Same for the Address objects.

On the coupling part I think you could do better. As it stands now, the Employee objects "knows about" (i.e. is coupled to) the internal representation of the Address object. That is because you "export" the data (the String) from the Address object instead of printing it right there where the data is.

This makes your objects more coupled, and will cause any change (for example introducing Street and City and things like that) in the Address objects to leak up to the Employee. So it has real downsides.

The solution is to define a print() method in the Address and do the System.out.println() there. This is in line with other concepts, such as the Law of Demeter, Tell Don't Ask.

Thank you @Robert Bräutigam. Great feedback. I agree. `Employee` knowing about (or deciding on) the internal representation of the `Address` object is indeed a bad idea. In this case the changes will affect three classes `Employee`, `HomeAddress` and `WorkAddress`. I personally would also describe this as a 'wrong level of abstraction'. — M. Groenhout, Nov 06 '18 at 22:32

Is this considered low coupling & high cohesion? Any chance to improve?

1 Answers1