Is “composition over inheritance” violating “dry principle”?

Question

For example, consider I have a class for other classes to extend:

public class LoginPage {
    public String userId;
    public String session;
    public boolean checkSessionValid() {
    }
}

and some subclasses:

public class HomePage extends LoginPage {

}

public class EditInfoPage extends LoginPage {

}

In fact, the subclass has not any methods to override, also I would not access the HomePage in generic way, i.e.: I would not do something like:

for (int i = 0; i < loginPages.length; i++) {
    loginPages[i].doSomething();
}

I just want to reuse the login page. But according to https://stackoverflow.com/a/53354, I should prefer composition here because I don't need the interface LoginPage, so I don't use inheritance here:

public class HomePage {
    public LoginPage loginPage;
}

public class EditInfoPage {
    public LoginPage loginPage;
}

but the problem comes here, at the new version, the code:

public LoginPage loginPage;

duplicates when a new class is added. And if LoginPage needs setter and getter, more codes need to be copied:

public LoginPage loginPage;

private LoginPage getLoginPage() {
    return this.loginPage;
}
private void setLoginPage(LoginPage loginPage) {
    this.loginPage = loginPage;
}

So my question is, is "composition over inheritance" violating "dry principle"?

Answer 1

Er wait you're concerned that repeating

public LoginPage loginPage;

in two places violates DRY? By that logic

int x;

can now only ever exist in one object in the entire code base. Bleh.

DRY is a good thing to keep in mind but come on. Besides

... extends LoginPage

is getting duplicated in your alternative so even being anal about DRY wont make sense of this.

Valid DRY concerns tend to focus on identical behavior needed in multiple places being defined in multiple places such that a need to change this behavior ends up requiring a change in multiple places. Make decisions in one place and you will only need to change them in one place. It doesn't mean only one object can ever hold a reference to your LoginPage.

DRY shouldn't be followed blindly. If you're duplicating because copy and paste is easier than thinking up a good method or class name then you're probably in the wrong.

But if you want to put the same code in a different place because that different place is subject to a different responsibility and is likely to need to change independently then it's probably wise to relax your enforcement of DRY and let this identical behavior have a different identity. It's the same kind of thinking that goes into forbidding magic numbers.

DRY isn't just about what the code looks like. It's about not spreading the details of an idea around with mindless repetition forcing maintainers to fix things using mindless repetition. It's when you try to tell yourself that the mindless repetition is just your convention that things are headed in a real bad way.

What I think you are really trying to complain about is called boilerplate code. Yes, using composition rather than inheritance demands boilerplate code. Nothing gets exposed for free, you have to write code that exposes it. With that boilerplate comes state flexibility, the ability to narrow the exposed interface, to give things different names that are appropriate for their level of abstraction, good ol indirection, and you're using what you're composed of from the outside, not the inside, so you're facing it's normal interface.

But yes, it's a lot of extra keyboard typing. As long as I can prevent the yo-yo problem of bouncing up and down an inheritance stack as I read the code it's worth it.

Now it's not that I refuse to ever use inheritance. One of my favorite uses is to give exceptions new names:

public class MyLoginPageWasNull extends NullPointerException{}

Answer 2

A common misunderstanding with the DRY principle is that it is somehow related to not repeating lines of code. The DRY principle is "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". It's about knowledge, not code.

LoginPage knows about how to draw the page for logging in. If EditInfoPage knew how to do this then that would be a violation. Including LoginPage via composition is not in any way a violation of the DRY principle.

The DRY principle is perhaps the most misused principle in software engineering and it should always be thought of not as a principle for not duplicating code, but as a principle for not duplicating abstract domain knowledge. Actually, in many cases if you apply DRY correctly then you will be duplicating code, and this is not necessarily a bad thing.

Answer 3

Short answer: yes, it does - to some minor, acceptable degree.

At a first glance, inheritance sometimes can save you some lines of code, since it has the effect of saying "my reusing class will contain all the public methods and attributes in a 1:1 manner". So if there is a list of 10 methods in a component, one does not have to repeat them in code in the inherited class. When in a composition scenario 9 of those 10 methods should be exposed publicly through a reusing component, then one has to write down 9 delegating calls, and let the remaining one out, there is no way around this.

Why is this tolerable? Look at the methods which are replicated in a composition scenario - these methods are exclusively delegating calls to the interface of the component, so containing no real logic.

The heart of the DRY principle is to avoid having two places in code where the same logical rules are encoded - because when these logical rules change, in non-DRY code it is easy to adapt one of those place and forget about the other one, which introduces an error.

But since delegating calls don't contain logic, these are normally not subject of such a change, so not causing a real problem when "prefering composition over inheritance". And even if the interface of the component changes, which might induce formal changes at all classes using the component, in a compiled language the compiler will tell us when we forgot to change one of the callers.

A note to your example: I don't know how your HomePage and your EditInfoPage look like, but if they have login functionality, and a HomePage (or an EditInfoPage) is a LoginPage, then inheritance might be the correct tool here. A less debatable example, where composition will be the better tool in a more obvious manner, would probably make things clearer.

Assuming neither HomePage nor EditInfoPage are a LoginPage, and one wants to reuse the latter, as you wrote, than it is pretty likely that one requires only some parts of the LoginPage, not everything. If that is the case, a better approach than using composition in the shown way might be to

• extract the reusable part of LoginPage into a component of its own

• reuse that component in HomePage and EditInfoPage the same way it is used now inside LoginPage

That way, it will typically become much clearer why and when composition over inheritance is the right approach.