Return to Answer

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.

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.

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

At a first glance, inheritance sometimes might 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 only 8 of those 10 methods should be exposed publicly through a reusing component, then one has to write down 8 delegating calls, and let the 2 others 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 forget 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.

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.

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

Why is this tolerable? Look at the methods which are replicated in a composition scenario - these methods are only 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 forget 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.

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

At a first glance, inheritance sometimes might 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 only 8 of those 10 methods should be exposed publicly through a reusing component, then one has to write down 8 delegating calls, and let the 2 others 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 forget 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.