Method Chaining vs Encapsulation – Object-Oriented Design

encapsulationobject-oriented

There is the classic OOP problem of method chaining vs "single-access-point" methods:

main.getA().getB().getC().transmogrify(x, y)

main.getA().transmogrifyMyC(x, y)

The first seems to have the advantage that each class is only responsible for a smaller set of operations, and makes everything a lot more modular – adding a method to C doesn't require any effort in A, B or C to expose it.

The downside, of course, is weaker encapsulation, which the second code solves. Now A has control of every method that passes through it, and can delegate it to its fields if it wants to.

I realize there's no single solution and it of course depends on context, but I would really like to hear some input about other important differences between the two styles, and under what circumstances should I prefer either of them – because right now, when I try to design some code, I feel like I'm just not using the arguments to decide one way or the other.

Best Answer

I think the Law of Demeter provides an important guideline in this (with its advantages and disadvantages, which, as usual, should be measured on a per case basis).

The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.

A disadvantage of the Law of Demeter is that it sometimes requires writing a large number of small "wrapper" methods to propagate method calls to the components. Furthermore, a class's interface can become bulky as it hosts methods for contained classes, resulting in a class without a cohesive interface. But this might also be a sign of bad OO design.

Related Solutions

Encapsulation in OOP – Using Lambdas for Better Encapsulation

I think the important point here is code locality: Code that should be read together should be close together.

My rule of thumb is: If both the called (lambda) function and the caller can be read, understood, maintained, tested (and possibly, but not necessarily, reused) separately, then extract the lambda function into a separate function or class. If the two are so closely tied together that you can't really make sense of one without knowing what the other does, then keep them as closely together as possible; lambdas are perfect for this, if the language you use doesn't allow nested functions.

Encapsulation – How Encapsulation Enhances Safety

How will encapsulation help when making changes in code and from its rippling effects. For a data member, if I change its type from int to float, (even if I am exposing this using property) I will need to change variable type where I am using already using this code.

The benefit of encapsulation is that it lets you change the internal implementation without breaking client code. It doesn't protect you if you decide that you need to change the interface to your code, but that's a different matter.

Example: Say you have a value representing the price per unit of some commodity. The price is expressed in cents, and because you don't deal in fractional cents you decided to make the property an integer (I'll use C here because I'm not very familiar with C#):

int _price

int pricePerUnit(void) {
    return _price;
}

int priceForUnits(int units) {
    return units * _price;
}

That all works out fine until one day when somebody notices that your firm is losing a lot of money due to rounding errors. Many of the commodities that you track are bought and sold in lots of many thousands of units, so you need to start tracking the price to an accuracy of at least 0.001 cent. Because you were smart enough to encapsulate the price instead of letting clients access it directly, you can make that change pretty quickly:

double _dprice

int pricePerUnit(void) {
    return (int)_dprice;
}

int priceForUnits(int units) {
    return (int)(units * _dprice);
}

The interface that clients use to obtain prices stays the same, but the data they get back is now more accurate. If the price per unit is $1.001, priceForUnits(1000000) will now return a price that's $1000 greater than before. That happens even though you haven't changed the interface to your system at all, and you therefore haven't broken any client code.

Now, that may not always be all that you need to do. Sometimes you'll need to change or augment your interface so that you can report the price more accurately to clients, too:

double pricePerUnit() {
    return _dprice;
}

A change like that will break client code, so you might instead keep the old interface and provide a newer, better routine:

int pricePerUnit() {
    return (int)_dprice;
}

double accuratePricePerUnit() {
    return _dprice;
}

You and the rest of your team can then embark on the process of converting all the clients of your system to use the newer, better accuratePricePerUnit(). The client code will get more accurate as you make progress on that task, but even the old stuff should continue to work as well as it did in the past.

Anyway, the point is that encapsulation lets you change the way the internals work while presenting a consistent interface, and that helps you make useful changes without breaking other code. It doesn't always protect you from having to update other code, but it can at least help you do that in a controlled manner.

Best Answer

Related Solutions

Encapsulation in OOP – Using Lambdas for Better Encapsulation

Encapsulation – How Encapsulation Enhances Safety

Related Topic