javaumlencapsulationclass-designooad

Choose class methods when there is OOP delegation

This is a simple scenario for understanding this problem about persons and their house.

Person can change color of their House

I created this UML diagram:

enter image description here

As shown in above diagram:

I would implement the above scenario using java code as shown below. Please note this code as pseudo code, so syntax can be wrong.

class Person {
    private House house;

    Person(House house) {
        this.house = house;
    }

    public void changeHouseColor() {
        house.changeColor(); // Delegation call
    }
}

class House {
    private String color;

    public string getColor() {
        return color;
    }

    public void changeColor(String color) {
        this.color = color;
    }
}

I want to know:

Solution

  • In short my answers are:

    1. No, encapsulation is not violated.
    2. The fact that the Person can change the color is already given by the Association.
    3. The Person's actions can involve calling its own Operations, but many other actions are possible.

    Further Explanations:

    point 1: Encapsulation in its formal description just says, you should not directly use the attributes of other Classes. It is completly Ok to call an Operation of another Class and it is Ok to offer an own Operation that delegates something to another Class. Whether it is good design depends on your specifc domain, as the other answers have suggested.

    point 2: When a Class has access to instances of another Class, it can potentially use all of its public Features. In your example, there is an Assocation between Person and House. Therefore, Person can call changeColor, but is not required to do it. In a more complete model House could have many more Features and not all of them might be meant to be used by Person. In this case it is useful to define a client specific Interface, only containing the Features needed by the Person Class. The Association would then be directed to this Interface, which in turn gets realized by the House Class. The Person Class is still technically not required to use all the Features of the Interface. However, I would view an Association to an Interface as a strong indication of the modelers intent, that all Features get used eventually.

    point 3: In OOAD Activity Diagrams are commonly used for analysing Use Cases. In this case the Actions are not connected to specific Classes and therefore no Operations are defined in this step.

    In a complete design model, the Behavior of the Person Class would be specified somehow. It could be with an Activity. In this Activity there could be many Actions. One could be a CallOperationAction, that calls changeColor. This would be an explicit specification of how the Person Class uses the House Class. It could also call its own Operation changeHouseColor, which in turn could be specified with an Activity.

    There are many other Actions defined in UML, like ReadStructuralFeatureAction or CreateObjectAction. They are not used very often, since it doesn't make much sense to model at this level of detail. However, I think it is helpful to know about them, to better understand how Operations and Actions are connected.