Related
UPDATE: My original question wasn't quite clear. I'm looking for the name of the principle that code like the example below violates.
(I've updated the code example to better resemble the scenario I'm talking about. The original code example I included can be found at the bottom. This was a poorly chosen example because it illustrated a hierarchical structure that actually should provide access to sub-members at an arbitrary "depth" level and furthermore had almost nothing to do with composition, which is what I meant to be asking about.)
I'm pretty sure there's a term for this and I'm just having trouble thinking of it.
Example of bad code:
public interface IJumper
{
void Jump();
}
public class Creature
{
public IJumper Jumper;
}
var c = new Creature();
c.Jumper.Jump();
Example of better code:
public class Creature : IJumper
{
private IJumper _jumper;
public void Jump()
{
_jumper.Jump();
}
}
var c = new Creature();
c.Jump();
I'm pretty sure I've heard this (exposing a member object directly so that all its properties/methods are publicly accessible) described as a bad thing due to [insert name of principle here]. What is the word I'm looking for?
(Note that I'm not asking why this is/isn't a bad thing; I'm just looking for the term, which for the life of me I can't remember.)
Original (bad) code example:
public class Person
{
public Person Child;
// ...
}
Person p = new Person("Philip J. Fry");
// what is the term for this?
Person greatGrandchild = p.Child.Child.Child;
Principles that may apply to this example are:
Information Hiding: Segregate design details in your code that are likely to change. Create a stable interface that protects the rest of the program from the implementation.
Encapsulation: Compartmentalize the elements of an abstraction that constitute its structure and behavior. Separate the contractual interface of an abstraction from its implementation. Use standard language mechanisms to bundle the data with the interface.
Note that the definitions of Information Hiding and Encapsulation I've given are quite similar, and various people have their own definitions of what these mean. I've pulled these from Wikipedia.
Interface Segregation Principle: The dependency of one class to another should depend on the smallest possible interface.
The question you must determine is whether writing your class this way, where Child itself is part of the interface, is a stable and minimal interface for clients to depend on. In most cases, OO programmers prefer to rely on an explicit set of methods as their interface instead of data members, so that they can change out the data members at will. Some will recommend that technique as a dictum. It may or may not apply in your case.
There's another principle that may or may not apply to your example:
Law of Demeter: Only talk to your immediate friends.
The Law of Demeter discourages deep access hierarchies like p.Child.Child.Child. Why? Because clients are then assuming deep structural knowledge about the objects they are talking to, and it increases coupling between the client and those objects. Having said this, I think there are plenty of examples in the world where this coupling is acceptable; you'd need to decide whether it applies in your case as well.
EDIT: With your revised example, the Law of Demeter looks to me much closer to what you're looking for.
It seems to qualify for several: Message Chains, Middle Man, Indecent Exposure, and maybe Feature Envy.
http://www.codinghorror.com/blog/2006/05/code-smells.html
If that pattern is used frequently, you probably need a property called GreatGrandChild that looks it up internally.
It's called method chaining (well... in this example it could be property chaining).
It's strongly linked with fulent interface.
On of these should be the term you're looking for.
Violating encapsulation?
Take Java syntax as an example, though the question itself is language independent. If the following snippet takes an object MyAbstractEmailTemplate as input argument in the method setTemplate, the class MyGateway will then become tightly-coupled with the object MyAbstractEmailTemplate, which lessens the re-usability of the class MyGateway.
A compromise is to use dependency-injection to ease the instantiation of MyAbstractEmailTemplate. This might solve the coupling problem
to some extent, but the interface is still rigid, hardly providing enough flexibility to
other developers/ applications.
So if we only use primitive data type (or even plain XML in web service) as the input/ output of a method, it seems the coupling problem no longer exists. So what do you think?
public class MyGateway {
protected MyAbstractEmailTemplate template;
public void setTemplate(MyAbstractEmailTemplate template) {
this.template = template;
}
}
It's pretty difficult to understand what you are really asking, but going the route of typing everything to Object does not lead to loose coupling because you can't do anything with the input without downcasting, which would break the Liskov Substituion Principle.
Taken to the extreme it leads you here:
public class MyClass
{
public object Invoke(object obj);
}
This is not loose coupling, it's just obscure and hard-to-maintain code.
The name MyAbstractEmailTemplate makes me believe that you are talking about an abstract class.
You should always program against interfaces, so instead of having MyGateway depend on MyAbstractEmailTemplate, it should depend on an EmailTemplate interface, where MyAbstractEmailTemplate implements EmailTemplate. Then, you can pass your custom implementations around as you want to, without further tight coupling.
Combine this with DI and you've got yourself a pretty decent solution.
Not exactly sure what you mean with "the interface is still rigid", but obviously you should design your interface in such a way that it provides the functionality you need.
MyGateway has to assume something about the inputs. Even if it used XML, it would have to assume something about the structure and content of the XML. Coupling isn't an evil in its own right; expresses the contract between two pieces of code. The oft-repeated advice to avoid tight coupling is really just saying that coupling should express the essence of a contract, not more and not less. Passing a specific type (particularly an interface type) is a very good way to achieve this balance.
The first problem you will run into is that a lot of types are simply not representable by a primitive data type (It's a Java problem that there are primitive types at all.).
The coupling should be reduced by using a proper inheritance hierarchy. What means proper? The method should take exactly that part of the interface as a parameter that is need. Not more not less.
After all you won't be able to avoid dependencies. Methods have to know about what they can do with their input or have to able to make assumptions (see C++ concepts) about the capabilities of the input.
IMHO there is nothing inherently wrong in using objects (wth small cap, not Objects) as method parameters and/or class members. Yes, these create dependencies. You can manage this in (at least) two ways:
acknowledge that by creating this dependency, the two classes become tightly coupled. This is entirely appropriate in many cases, where two (or more) classes in fact form a component, which is a meaningful unit of reuse in itself, and its parts may not make much sense or be interchangeable.
if there are multiple interchangeable candidates for a method parameter, these are obvious candidates to form a class hierarchy. Then you program for the interface and can pass any object of any class implementing that interface as parameter to your method. Note that the phrase "there are multiple interchangeable candidates for a method parameter" is a loose rephrasing of the Liskov Substitution Principle, which is the foundation of polymorphism.
in some languages, e.g. C++, the third way would be using templates. Then you need no common interface, only specific methods/members need to resolvable when the template is instantiated. However, since instantiation happens at compile time, this is entirely static binding.
sThe problem is I would say, that the best java can offer are interfaces and people start to see that they are too rigid. It would be interesting to use something like what is in Go language, that allows flexible checking for all methods of an interface to be present in the type, you do not have to be explicit about implementing some interface. We also need something better than interfaces to specify the constraints - maybe some sort of contracts. Another thing is the interface evolution.
The template method pattern and the strategy pattern do roughly the same thing. I understand the basic differences between them (template method is inheritance based, strategy is composition based), but are there any decent guidelines on when to choose one over the other? It seems like they do basically the same thing.
Strategy allows for a reusable algorithm to be used in more than one place. If you have an algorithm that can be provided by your consumer and can be used in several places, this is a good spot for Strategy (sorting algorithms, predicates, comparers... are good examples of that).
Template method is specifically targeted at cases where you want people to be able to inherit from your class and want them to be able to override your implementation in a controlled manner (basically preventing them from replacing all your plumbing and offering them a specific extension point without risking a problem because they did not call the base method or called it at the wrong time).
They can be similar, and they can serve the same kind of purpose depending on what you are actually doing.
As with all design patterns, it is difficult to answer such a question because there is not really a definitive answer. It's actually easier to decide in context...
The two can actually be used together quite effectively.
Here's a video that details how
Don't think of patterns as recipes with specific code to implement them.
It's the design intent that is the key, and there can be many implementations. By mentioning a pattern name in your code somewhere, you're letting a reader in on your intent when you wrote that code. The implementation is secondary.
Template method gives you an "algorithm with replaceable steps". (The algorithm is normally defined in a non-overridable method (final or private for example) )
The GoF implementation of this concept uses inheritance and method overriding to replace those steps.
However, you're still using Template method if those steps are replaced by strategies.
For example, think about a class that wants to walk a binary tree inorder and "do something" at each node.
The intent is that the inorder() method is a template method - the structure of the walk is always the same.
The "hook" method, the part that "does something" can be implemented as a method in the same class (and overridden in subclasses to change behavior), or externally, in which case it's a strategy for "doing something".
I use Template method when the algorithm needs knowledge of the internals of the objects it runs on.
In all other cases (i.e. when the algorithm only needs to use the object's interface), I try to use Strategy.
Further, Strategy is only useful when there are actual algorithms to implement: If the only difference between classes is (for example) what simple value to return, use Template method.
Consider usage strategy when:
Your object behaviour needs to be changed in runtime.
You already have class hierarchy by other criteria.
You want to share strategy logic across different classes.
In other cases it should be enought to use template pattern.
I disagree with this statement (from this answer):
"Template method is specifically targeted at cases where you want
people to be able to inherit from your class and want them to be able
to override your implementation in a controlled manner."
If you WANT people to inherit from your class then you're WANTING a specific implementation, rather than wanting a particular behaviour. That smells bad to me.
A valid thing to WANT is the ability to override or provide implementations of individual steps of an algorithm. That goal can be achieved by both Template Methods (where we can selectively override protected methods) or the Strategy Pattern (where we inject implementations).
If you are building a class that implements an algorithm, and you want to allow steps in that algorithm to be altered by other developers, that's your requirement. Your only decision is whether to allow them to do that via inheritance or composition.
All other things being equal we should favour composition over inheritance, but we should only even get to the inheritance/composition decision by first figuring out what our goal is (we may need neither).
I would never start with "I want to allow them to inherit from this class". That's cart before the horse IMO.
You can create big inheritance tree just to change one of the N behavior. And you can create second big inheritance tree to change second of the N behavior.
But also you can unload your tree by creating small strategy trees.
So if you noticed that you add more and more classes just to add some changes in some behavior - it is time to supply your classes with strategies.
I would like to agree and second Scott's explanation.
Template pattern = cares about drawing the generic lines along which an operation will be carried on - templating - basically an "algorithm with replaceable steps" (very well coined) where the replaceable steps can be delegated using the Strategy pattern concept.
Strategy pattern = cares only about decoupling the client from the underlining implementation of an operation whose outcome needs to always abide by some predetermined rules (like sorting where the outcome is always a sorted list but you may deffer de actual sorting to bubble sort or to quick sort).
Cheers.
One of the central OO Design principles is "Favour Composition over Inheritance", so that suggests to favour the Strategy pattern. It obviously depends on what you are trying to accomplish in a particular scenario.
My summary: The Strategy Pattern is more loosely coupled than the Template Method pattern, which is generally a good thing.
Robert C. Martin in TEMPLATE METHOD & STRATEGY: Inheritance vs. Delegation
Thus, the STRATEGY pattern provides one extra benefit over the
TEMPLATE METHOD pattern. Whereas the TEMPLATE METHOD pattern allows a
generic algorithm to manipulate many possible detailed
implementations, by fully conforming to the DIP the STRATEGY pattern
additionally allows each detailed implementation to be manipulated by
many different generic algorithms.
DIP is the Dependency Inversion Principle:
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
I would almost always go for strategy for the very important reason that client code has no dependency on implementation whereas in template pattern part of implementation stays in the abstract class and any change in abstract class may need to change the client which very often result in rigid code and we end up developer telling that "this came out to be a bigger change than I expected".
But in cases when it is really helpful to get common code in an abstract class I would not hesitate to do it and also try to keep code related to client code away from it
I think the answer from #Lennaert is correct. I would like to add some details to it:
The Template pattern differs from the Strategy pattern in a sense that the Template Method uses inheritance and the Strategy pattern uses composition to achieve a common goal. The Strategy pattern is preferred in case the strategies/algorithms are ‘self-contained’ (e.g. more then just a difference in a ‘simple’ return) and must be shared amongst possible other clients/Contexts. The Template pattern is preferred in case the algorithms diverge in their fine details (e.g. just a difference in a ‘simple’ return) and/or access of the internal details of the concrete implementation is required by the base class.
This means:
from client reusability point of view, the Strategy pattern is
preferred over the Template method. Each Strategy can be reused
within a different Context (=client). A new Context solely depends
on the interface of the Strategy and not on the 'extensive'
interface of the full Context. (A compliment to the Interface
Segregation principle). In contrast, within the Template method the
base and concrete implementation are ‘glued’ together. This means
clients, whom would like to re-use the concrete template-method
implementation, are ‘automatically’ bounded to the base class
implementation as well. Even if they don’t want that! This could
violate Interface Segregation. Adhering to Interface Segregation
enables in this case: less recompilation, more confident of changing
an interface (less search hits) and the client is constraint
(‘role’ interface).
the Template pattern might be preferred in case the base algorithm
(=Context or Base Template) requires access to the internals of the
concrete algorithm (=Strategies or Concrete Template). In the
Template Method pattern, the base class can get access to the
concrete implementation via “the Hollywood principle”. This can be
done via a relative encapsulated approach, by making the members
protected. In contrast, the Strategy pattern does not provide this
encapsulated approach (in this particular use-case). Each Strategy
would need to expose its internals on its interface, making it
available to all clients. This might violate encapsulation,
resulting in possible unwanted coupling that is provoked by the
design.
I would prefer using a mix of both, dumping default implementation (from Template pattern) into Context class of strategy pattern. This way, I can enforce user to call method I want them to call so that the order of execution on algorithm's steps remains controlled.
/**
* enables replaceable steps in algorithm
*/
public interface HouseStrategy{
void buildWalls();
void buildPillars();
}
public class HouseContext{
//public API that enforces order of execution
public void build(HouseStrategy strategy){
buildFoundation();//default implementation
strategy.buildPillars();//delegated to concrete strategy
strategy.buildWalls();//delegated to concrete strategy
buildWindows();//default implementation
}
//default implementation
private void buildWindows() {
System.out.println("Building Glass Windows");
}
//default implementation
private void buildFoundation() {
System.out.println("Building foundation with cement,iron rods and sand");
}
}
public class WoodenHouse implements HouseStrategy {
#Override
public void buildWalls() {
System.out.println("Building Wooden Walls");
}
#Override
public void buildPillars() {
System.out.println("Building Pillars with Wood coating");
}
}
public class GlassHouse implements HouseStrategy {
#Override
public void buildWalls() {
System.out.println("Building Wooden Of glass");
}
#Override
public void buildPillars() {
System.out.println("Building Pillars with glass coating");
}
}
As we can see, concrete strategies are still open to extension. As in,
public class GlassHouse implements HouseStrategy,EarthquakeResistantHouseStrategy{......}
The usage
HouseContext context = new HouseContext();
WoodenHouse woodenHouseStrategy = new WoodenHouse();
context.build(woodenHouseStrategy);
GlassHouse glassHouseStrategy = new GlassHouse();
context.build(glassHouseStrategy);
One disadvantage I see here is that concrete strategies can only change the variant behavior of algorithm i.e. buildWalls() and buildPillars(). If we need to change invariant parts i.e. buildFoundation() and buildWindows(), we need to make another Context class implementing the new behavior.
Still, we get some code reusability which is not found in pure Strategy Pattern :-)
This is quite a controversial topic, and before you say "no", is it really, really needed?
I have been programming for about 10 years, and I can't honestly say that I can recall a time where inheritance solved a problem that couldn't be solved another way. On the other hand I can recall many times when I used inheritance, because I felt like I had to or because I though I was clever and ended up paying for it.
I can't really see any circumstances where, from an implementation stand point, aggregation or another technique could not be used instead of inheritance.
My only caveat to this is that we would still allow inheritance of interfaces.
(Update)
Let's give an example of why it's needed instead of saying, "sometimes it's just needed." That really isn't helpful at all. Where is your proof?
(Update 2 Code Example)
Here's the classic shape example, more powerful, and more explicit IMO, without inheritance. It is almost never the case in the real world that something really "Is a" of something else. Almost always "Is Implemented in Terms of" is more accurate.
public interface IShape
{
void Draw();
}
public class BasicShape : IShape
{
public void Draw()
{
// All shapes in this system have a dot in the middle except squares.
DrawDotInMiddle();
}
}
public class Circle : IShape
{
private BasicShape _basicShape;
public void Draw()
{
// Draw the circle part
DrawCircle();
_basicShape.Draw();
}
}
public class Square : IShape
{
private BasicShape _basicShape;
public void Draw()
{
// Draw the circle part
DrawSquare();
}
}
I blogged about this as a wacky idea a while ago.
I don't think it should be removed, but I think classes should be sealed by default to discourage inheritance when it's not appropriate. It's a powerful tool to have available, but it's like a chain-saw - you really don't want to use it unless it's the perfect tool for the job. Otherwise you might start losing limbs.
The are potential language features such as mix-ins which would make it easier to live without, IMO.
Inheritance can be rather useful in situations where your base class has a number of methods with the same implementation for each derived class, to save every single derived class from having to implement boiler-plate code. Take the .NET Stream class for example which defines the following methods:
public virtual int Read(byte[] buffer, int index, int count)
{
}
public int ReadByte()
{
// note: this is only an approximation to the real implementation
var buffer = new byte[1];
if (this.Read(buffer, 0, 1) == 1)
{
return buffer[0];
}
return -1;
}
Because inheritance is available the base class can implement the ReadByte method for all implementations without them having to worry about it. There are a number of other methods like this on the class which have default or fixed implementations. So in this type of situation it's a very valuable thing to have, compared with an interface where your options are either to make everyone re-implement everything, or to create a StreamUtil type class which they can call (yuk!).
To clarify, with inheritance all I need to write to create a DerivedStream class is something like:
public class DerivedStream : Stream
{
public override int Read(byte[] buffer, int index, int count)
{
// my read implementation
}
}
Whereas if we're using interfaces and a default implementation of the methods in StreamUtil I have to write a bunch more code:
public class DerivedStream : IStream
{
public int Read(byte[] buffer, int index, int count)
{
// my read implementation
}
public int ReadByte()
{
return StreamUtil.ReadByte(this);
}
}
}
So it's not a huge amount more code, but multiply this by a few more methods on the class and it's just unnecessary boiler plate stuff which the compiler could handle instead. Why make things more painful to implement than necessary? I don't think inheritance is the be-all and end-all, but it can be very useful when used correctly.
Of course you can write great programs happily without objects and inheritance; functional programmers do it all the time. But let us not be hasty. Anybody interested in this topic should check out the slides from Xavier Leroy's invited lecture about classes vs modules in Objective Caml. Xavier does a beautiful job laying out what inheritance does well and does not do well in the context of different kinds of software evolution.
All languages are Turing-complete, so of course inheritance isn't necessary. But as an argument for the value of inheritance, I present the Smalltalk blue book, especially the Collection hierarchy and the Number hierarchy. I'm very impressed that a skilled specialist can add an entirely new kind of number (or collection) without perturbing the existing system.
I will also remind questioner of the "killer app" for inheritance: the GUI toolkit. A well-designed toolkit (if you can find one) makes it very, very easy to add new kinds of graphical interaction widgets.
Having said all that, I think that inheritance has innate weaknesses (your program logic is smeared out over a large set of classes) and that it should be used rarely and only by skilled professionals. A person graduating with a bachelor's degree in computer science barely knows anything about inheritance---such persons should be permitted to inherit from other classes at need, but should never, ever write code from which other programmers inherit. That job should be reserved for master programmers who really know what they're doing. And they should do it reluctantly!
For an interesting take on solving similar problems using a completely different mechanism, people might want to check out Haskell type classes.
I wish languages would provide some mechanisms to make it easier to delegate to member variables. For example, suppose interface I has 10 methods, and class C1 implements this interface. Suppose I want to implement class C2 that is just like a C1 but with method m1() overridden. Without using inheritance, I would do this as follows (in Java):
public class C2 implements I {
private I c1;
public C2() {
c1 = new C1();
}
public void m1() {
// This is the method C2 is overriding.
}
public void m2() {
c1.m2();
}
public void m3() {
c1.m3();
}
...
public void m10() {
c1.m10();
}
}
In other words, I have to explicitly write code to delegate the behavior of methods m2..m10 to the member variable m1. That's a bit of a pain. It also clutters the code up so that it's harder to see the real logic in class C2. It also means that whenever new methods are added to interface I, I have to explicitly add more code to C1 just to delegate these new methods to C1.
I wish languages would allow me to say: C1 implements I, but if C1 is missing some method from I, automatically delegate to member variable c1. That would cut down the size of C1 to just
public class C2 implements I(delegate to c1) {
private I c1;
public C2() {
c1 = new C1();
}
public void m1() {
// This is the method C2 is overriding.
}
}
If languages allowed us to do this, it would be much easier to avoid use of inheritance.
Here's a blog article I wrote about automatic delegation.
Inheritance is one of those tools that can be used, and of course can be abused, but I think languages have to have more changes before class-based inheritance could be removed.
Let's take my world at the moment, which is mainly C# development.
For Microsoft to take away class-based inheritance, they would have to build in much stronger support for handling interfaces. Things like aggregation, where I need to add lots of boiler-plate code just to wire up an interface to an internal object. This really should be done anyway, but would be a requirement in such a case.
In other words, the following code:
public interface IPerson { ... }
public interface IEmployee : IPerson { ... }
public class Employee : IEmployee
{
private Person _Person;
...
public String FirstName
{
get { return _Person.FirstName; }
set { _Person.FirstName = value; }
}
}
This would basically have to be a lot shorter, otherwise I'd have lots of these properties just to make my class mimic a person good enough, something like this:
public class Employee : IEmployee
{
private Person _Person implements IPerson;
...
}
this could auto-create the code necessary, instead of me having to write it. Just returning the internal reference if I cast my object to an IPerson would do no good.
So things would have to be better supported before class-based inheritance could be taken off the table.
Also, you would remove things like visibility. An interface really just have two visibility settings: There, and not-there. In some cases you would be, or so I think, forced to expose more of your internal data just so that someone else can more easily use your class.
For class-based inheritance, you can usually expose some access points that a descendant can use, but outside code can't, and you would generally have to just remove those access points, or make them open to everyone. Not sure I like either alternative.
My biggest question would be what specifically the point of removing such functionality would be, even if the plan would be to, as an example, build D#, a new language, like C#, but without the class-based inheritance. In other words, even if you plan on building a whole new language, I still am not entirely sure what the ultimate goal would be.
Is the goal to remove something that can be abused if not in the right hands? If so, I have a list a mile long for various programming languages that I would really like to see addresses first.
At the top of that list: The with keyword in Delphi. That keyword is not just like shooting yourself in the foot, it's like the compiler buys the shotgun, comes to your house and takes aim for you.
Personally I like class-based inheritance. Sure, you can write yourself into a corner. But we can all do that. Remove class-based inheritance, I'll just find a new way of shooting myself in the foot with.
Now where did I put that shotgun...
Have fun implementing ISystemObject on all of your classes so that you have access to ToString() and GetHashcode().
Additionally, good luck with the ISystemWebUIPage interface.
If you don't like inheritance, my suggestion is to stop using .NET all together. There are way too many scenarios where it saves time (see DRY: don't repeat yourself).
If using inheritance is blowing up your code, then you need to take a step back and rethink your design.
I prefer interfaces, but they aren't a silver bullet.
For production code I almost never use inheritance. I go with using interfaces for everything (this helps with testing and improves readability i.e. you can just look at the interface to read the public methods and see what is going on because of well-named methods and class names). Pretty much the only time I would use inheritance would be because a third party library demands it. Using interfaces, I would get the same effect but I would mimic inheritance by using 'delegation'.
For me, not only is this more readable but it is much more testable and also makes refactoring a whole lot easier.
The only time I can think of that I would use inheritance in testing would be to create my own specific TestCases used to differentiate between types of tests I have in my system.
So I probably wouldn't get rid of it but I choose not to use it as much as possible for the reasons mentioned above.
No. Sometimes you need inheritance. And for those times where you don't -- don't use it. You can always "just" use interfaces (in languages that have them) and ADPs without data work like interfaces in those languages that don't have them. But I see no reason to remove what is sometimes a necessary feature just because you feel it isn't always needed.
No. Just because it's not often needed, doesn't mean it's never needed. Like any other tool in a toolkit, it can (and has been, and will be) misused. However, that doesn't mean it should never be used. In fact, in some languages (C++), there is no such thing as an 'interface' at the language level, so without a major change, you couldn't prohibit it.
No, it is not needed, but that does not mean it does not provide an overall benefit, which I think is more important than worrying about whether it is absolutely necessary.
In the end, almost all modern software language constructs amount to syntactic sugar - we could all be writing assembly code (or using punch cards, or working with vacuum tubes) if we really had to.
I find inheritance immensely useful those times that I truly want to express an "is-a" relationship. Inheritance seems to be the clearest means of expressing that intent. If I used delegation for all implementation re-use, I lose that expressiveness.
Does this allow for abuse? Of course it does. I often see questions asking how the developer can inherit from a class but hide a method because that method should not exist on the subclass. That person obviously misses the point of inheritance, and should be pointed toward delegation instead.
I don't use inheritance because it is needed, I use it because it is sometimes the best tool for the job.
I guess I have to play the devil's advocate. If we didn't have inheritance then we wouldn't be able to inherit abstract classes that uses the template method pattern. There are lots of examples where this is used in frameworks such as .NET and Java. Thread in Java is such an example:
// Alternative 1:
public class MyThread extends Thread {
// Abstract method to implement from Thread
// aka. "template method" (GoF design pattern)
public void run() {
// ...
}
}
// Usage:
MyThread t = new MyThread();
t.start();
The alternative is, in my meaning, verbose when you have to use it. Visual clutteer complexity goes up. This is because you need to create the Thread before you can actually use it.
// Alternative 2:
public class MyThread implements Runnable {
// Method to implement from Runnable:
public void run() {
// ...
}
}
// Usage:
MyThread m = new MyThread();
Thread t = new Thread(m);
t.start();
// …or if you have a curious perversion towards one-liners
Thread t = new Thread(new MyThread());
t.start();
Having my devil's advocate hat off I guess you could argue that the gain in the second implementation is dependency injection or seperation of concerns which helps designing testable classes. Depending on your definition of what an interface is (I've heard of at least three) an abstract class could be regarded as an interface.
Needed? No. You can write any program in C, for example, which doesn't have any sort of inheritance or objects. You could write it in assembly language, although it would be less portable. You could write it in a Turing machine and have it emulated. Somebody designed a computer language with exactly one instruction (something like subtract and branch if not zero), and you could write your program in that.
So, if you're going to ask if a given language feature is necessary (like inheritance, or objects, or recursion, or functions), the answer is no. (There are exceptions - you have to be able to loop and do things conditionally, although these need not be supported as explicit concepts in the language.)
Therefore, I find questions of this sort useless.
Questions like "When should we use inheritance" or "When shouldn't we" are a lot more useful.
a lot of the time I find myself choosing a base class over an interface just because I have some standard functionality. in C#, I can now use extension methods to achieve that, but it still doesn't achieve the same thing for several situations.
Is inheritance really needed? Depends what you mean by "really". You could go back to punch cards or flicking toggle switches in theory, but it's a terrible way to develop software.
In procedural languages, yes, class inheritance is a definite boon. It gives you a way to elegantly organise your code in certain circumstances. It should not be overused, as any other feature should not be overused.
For example, take the case of digiarnie in this thread. He/she uses interfaces for nearly everything, which is just as bad as (possibly worse than) using lots of inheritance.
Some of his points :
this helps with testing and improves readability
It doesn't do either thing. You never actually test an interface, you always test an object, that is, an instantiation of a class. And having to look at a completely different bit of code helps you understand the structure of a class? I don't think so.
Ditto for deep inheritance hierarchies though. You ideally want to look in one place only.
Using interfaces, I would get the same effect but I would mimic inheritance by using
'delegation'.
Delegation is a very good idea, and should often be used instead of inheritance (for example, the Strategy pattern is all about doing exactly this). But interfaces have zero to do with delegation, because you cannot specify any behaviour at all in an interface.
also makes refactoring a whole lot easier.
Early commitment to interfaces usually makes refactoring harder, not easier, because there are then more places to change. Overusing inheritance early is better (well, less bad) than overusing interfaces, as pulling out delegate classes is easier if the classes being modified do not implement any interfaces. And it's quite often from those delegates than you get useful interfaces.
So overuse of inheritance is a bad thing. Overuse of interfaces is a bad thing. And ideally, a class will neither inherit from anything (except maybe "object" or the language equivalent), nor implement any interfaces. But that doesn't mean either feature should be removed from a language.
If there is a framework class that does almost exactly what you want, but a particular function of its interface throws a NotSupported exception or for some other reason you only want to override one method to do something specific to your implementation, it's much easier to write a subclass and override that one method rather than write a brand new class and write pass-throughs for each of the other 27 methods in the class.
Similarly, What about Java, for example, where every object inherits from Object, and therefore automatically has implementations of equals, hashcode, etc. I don't have to re-implement them, and it "just works" when I want to use the object as a key in a hashtable. I don't have to write a default passthrough to a Hashtable.hashcode(Object o) method, which frankly seems like it's moving away from object orientation.
My initial thought was, You're crazy. But after thinking about it a while I kinda agree with you. I'm not saying remove Class Inheritance fully (abstract classes with partial implementation for example can be useful), but I have often inherited (pun intended) badly written OO code with multi level class inheritance that added nothing, other than bloat, to the code.
Note that inheritance means it is no longer possible to supply the base class functionality by dependency injection, in order to unit test a derived class in isolation of its parent.
So if you're deadly serious about dependency injection (which I'm not, but I do wonder whether I should be), you can't get much use out of inheritance anyway.
Here's a nice view at the topic:
IS-STRICTLY-EQUIVALENT-TO-A by Reg Braithwaite
I believe a better mechanism for code re-use which is sometimes achieved through inheritance are traits. Check this link (pdf) for a great discussion on this, including the distinction between traits and mixins, and why traits are favored.
There's some research that introduces traits into C# (pdf).
Perl has traits through Moose::Roles. Scala traits are like mixins, as in Ruby.
The question is, "Should inheritance (of non-interface types) be removed from programming languages?"
I say, "No", as it will break a hell of a lot of existing code.
That aside, should you use inheritance, other than inheritance of interfaces? I'm predominantly a C++ programmer and I follow a strict object model of multiple inheritance of interfaces followed by a chain of single inheritance of classes. The concrete classes are a "secret" of a component and it's friends, so what goes on there is nobodies business.
To help implement interfaces, I use template mixins. This allows the interface designer to provide snippets of code to help implement the interface for common scenarios. As a component developer I feel like I can go mixin shopping to get the reusable bits without being encumbered by how the interface designer thought I should build my class.
Having said that, the mixin paradigm is pretty much unique to C++. Without this, I expect that inheritance is very attractive to the pragmatic programmer.
Almost every Java book I read talks about using the interface as a way to share state and behaviour between objects that when first "constructed" did not seem to share a relationship.
However, whenever I see architects design an application, the first thing they do is start programming to an interface. How come? How do you know all the relationships between objects that will occur within that interface? If you already know those relationships, then why not just extend an abstract class?
Programming to an interface means respecting the "contract" created by using that interface. And so if your IPoweredByMotor interface has a start() method, future classes that implement the interface, be they MotorizedWheelChair, Automobile, or SmoothieMaker, in implementing the methods of that interface, add flexibility to your system, because one piece of code can start the motor of many different types of things, because all that one piece of code needs to know is that they respond to start(). It doesn't matter how they start, just that they must start.
Great question. I'll refer you to Josh Bloch in Effective Java, who writes (item 16) why to prefer the use of interfaces over abstract classes. By the way, if you haven't got this book, I highly recommend it! Here is a summary of what he says:
Existing classes can be easily retrofitted to implement a new interface. All you need to do is implement the interface and add the required methods. Existing classes cannot be retrofitted easily to extend a new abstract class.
Interfaces are ideal for defining mix-ins. A mix-in interface allows classes to declare additional, optional behavior (for example, Comparable). It allows the optional functionality to be mixed in with the primary functionality. Abstract classes cannot define mix-ins -- a class cannot extend more than one parent.
Interfaces allow for non-hierarchical frameworks. If you have a class that has the functionality of many interfaces, it can implement them all. Without interfaces, you would have to create a bloated class hierarchy with a class for every combination of attributes, resulting in combinatorial explosion.
Interfaces enable safe functionality enhancements. You can create wrapper classes using the Decorator pattern, a robust and flexible design. A wrapper class implements and contains the same interface, forwarding some functionality to existing methods, while adding specialized behavior to other methods. You can't do this with abstract methods - you must use inheritance instead, which is more fragile.
What about the advantage of abstract classes providing basic implementation? You can provide an abstract skeletal implementation class with each interface. This combines the virtues of both interfaces and abstract classes. Skeletal implementations provide implementation assistance without imposing the severe constraints that abstract classes force when they serve as type definitions. For example, the Collections Framework defines the type using interfaces, and provides a skeletal implementation for each one.
Programming to interfaces provides several benefits:
Required for GoF type patterns, such as the visitor pattern
Allows for alternate implementations. For example, multiple data access object implementations may exist for a single interface that abstracts the database engine in use (AccountDaoMySQL and AccountDaoOracle may both implement AccountDao)
A Class may implement multiple interfaces. Java does not allow multiple inheritance of concrete classes.
Abstracts implementation details. Interfaces may include only public API methods, hiding implementation details. Benefits include a cleanly documented public API and well documented contracts.
Used heavily by modern dependency injection frameworks, such as http://www.springframework.org/.
In Java, interfaces can be used to create dynamic proxies - http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html. This can be used very effectively with frameworks such as Spring to perform Aspect Oriented Programming. Aspects can add very useful functionality to Classes without directly adding java code to those classes. Examples of this functionality include logging, auditing, performance monitoring, transaction demarcation, etc. http://static.springframework.org/spring/docs/2.5.x/reference/aop.html.
Mock implementations, unit testing - When dependent classes are implementations of interfaces, mock classes can be written that also implement those interfaces. The mock classes can be used to facilitate unit testing.
I think one of the reasons abstract classes have largely been abandoned by developers might be a misunderstanding.
When the Gang of Four wrote:
Program to an interface not an implementation.
there was no such thing as a java or C# interface. They were talking about the object-oriented interface concept, that every class has. Erich Gamma mentions it in this interview.
I think following all the rules and principles mechanically without thinking leads to a difficult to read, navigate, understand and maintain code-base. Remember: The simplest thing that could possibly work.
How come?
Because that's what all the books say. Like the GoF patterns, many people see it as universally good and don't ever think about whether or not it is really the right design.
How do you know all the relationships between objects that will occur within that interface?
You don't, and that's a problem.
If
you already know those relationships,
then why not just extend an abstract
class?
Reasons to not extend an abstract class:
You have radically different implementations and making a decent base class is too hard.
You need to burn your one and only base class for something else.
If neither apply, go ahead and use an abstract class. It will save you a lot of time.
Questions you didn't ask:
What are the down-sides of using an interface?
You cannot change them. Unlike an abstract class, an interface is set in stone. Once you have one in use, extending it will break code, period.
Do I really need either?
Most of the time, no. Think really hard before you build any object hierarchy. A big problem in languages like Java is that it makes it way too easy to create massive, complicated object hierarchies.
Consider the classic example LameDuck inherits from Duck. Sounds easy, doesn't it?
Well, that is until you need to indicate that the duck has been injured and is now lame. Or indicate that the lame duck has been healed and can walk again. Java does not allow you to change an objects type, so using sub-types to indicate lameness doesn't actually work.
Programming to an interface means respecting the "contract" created by
using that interface
This is the single most misunderstood thing about interfaces.
There is no way to enforce any such contract with interfaces. Interfaces, by definition, cannot specify any behaviour at all. Classes are where behaviour happens.
This mistaken belief is so widespread as to be considered the conventional wisdom by many people. It is, however, wrong.
So this statement in the OP
Almost every Java book I read talks about using the interface as a way
to share state and behavior between objects
is just not possible. Interfaces have neither state nor behaviour. They can define properties, that implementing classes must provide, but that's as close as they can get. You cannot share behaviour using interfaces.
You can make an assumption that people will implement an interface to provide the sort of behaviour implied by the name of its methods, but that's not anything like the same thing. And it places no restrictions at all on when such methods are called (eg that Start should be called before Stop).
This statement
Required for GoF type patterns, such as the visitor pattern
is also incorrect. The GoF book uses exactly zero interfaces, as they were not a feature of the languages used at the time. None of the patterns require interfaces, although some can use them. IMO, the Observer pattern is one in which interfaces can play a more elegant role (although the pattern is normally implemented using events nowadays). In the Visitor pattern it is almost always the case that a base Visitor class implementing default behaviour for each type of visited node is required, IME.
Personally, I think the answer to the question is threefold:
Interfaces are seen by many as a silver bullet (these people usually labour under the "contract" misapprehension, or think that interfaces magically decouple their code)
Java people are very focussed on using frameworks, many of which (rightly) require classes to implement their interfaces
Interfaces were the best way to do some things before generics and annotations (attributes in C#) were introduced.
Interfaces are a very useful language feature, but are much abused. Symptoms include:
An interface is only implemented by one class
A class implements multiple interfaces. Often touted as an advantage of interfaces, usually it means that the class in question is violating the principle of separation of concerns.
There is an inheritance hierarchy of interfaces (often mirrored by a hierarchy of classes). This is the situation you're trying to avoid by using interfaces in the first place. Too much inheritance is a bad thing, both for classes and interfaces.
All these things are code smells, IMO.
It's one way to promote loose coupling.
With low coupling, a change in one module will not require a change in the implementation of another module.
A good use of this concept is Abstract Factory pattern. In the Wikipedia example, GUIFactory interface produces Button interface. The concrete factory may be WinFactory (producing WinButton), or OSXFactory (producing OSXButton). Imagine if you are writing a GUI application and you have to go look around all instances of OldButton class and changing them to WinButton. Then next year, you need to add OSXButton version.
In my opinion, you see this so often because it is a very good practice that is often applied in the wrong situations.
There are many advantages to interfaces relative to abstract classes:
You can switch implementations w/o re-building code that depends on the interface. This is useful for: proxy classes, dependency injection, AOP, etc.
You can separate the API from the implementation in your code. This can be nice because it makes it obvious when you're changing code that will affect other modules.
It allows developers writing code that is dependent on your code to easily mock your API for testing purposes.
You gain the most advantage from interfaces when dealing with modules of code. However, there is no easy rule to determine where module boundaries should be. So this best practice is easy to over-use, especially when first designing some software.
I would assume (with #eed3s9n) that it's to promote loose coupling. Also, without interfaces unit testing becomes much more difficult, as you can't mock up your objects.
Why extends is evil. This article is pretty much a direct answer to the question asked. I can think of almost no case where you would actually need an abstract class, and plenty of situations where it is a bad idea. This does not mean that implementations using abstract classes are bad, but you will have to take care so you do not make the interface contract dependent on artifacts of some specific implementation (case in point: the Stack class in Java).
One more thing: it is not necessary, or good practice, to have interfaces everywhere. Typically, you should identify when you need an interface and when you do not. In an ideal world, the second case should be implemented as a final class most of the time.
There are some excellent answers here, but if you're looking for a concrete reason, look no further than Unit Testing.
Consider that you want to test a method in the business logic that retrieves the current tax rate for the region where a transaction occurrs. To do this, the business logic class has to talk to the database via a Repository:
interface IRepository<T> { T Get(string key); }
class TaxRateRepository : IRepository<TaxRate> {
protected internal TaxRateRepository() {}
public TaxRate Get(string key) {
// retrieve an TaxRate (obj) from database
return obj; }
}
Throughout the code, use the type IRepository instead of TaxRateRepository.
The repository has a non-public constructor to encourage users (developers) to use the factory to instantiate the repository:
public static class RepositoryFactory {
public RepositoryFactory() {
TaxRateRepository = new TaxRateRepository(); }
public static IRepository TaxRateRepository { get; protected set; }
public static void SetTaxRateRepository(IRepository rep) {
TaxRateRepository = rep; }
}
The factory is the only place where the TaxRateRepository class is referenced directly.
So you need some supporting classes for this example:
class TaxRate {
public string Region { get; protected set; }
decimal Rate { get; protected set; }
}
static class Business {
static decimal GetRate(string region) {
var taxRate = RepositoryFactory.TaxRateRepository.Get(region);
return taxRate.Rate; }
}
And there is also another other implementation of IRepository - the mock up:
class MockTaxRateRepository : IRepository<TaxRate> {
public TaxRate ReturnValue { get; set; }
public bool GetWasCalled { get; protected set; }
public string KeyParamValue { get; protected set; }
public TaxRate Get(string key) {
GetWasCalled = true;
KeyParamValue = key;
return ReturnValue; }
}
Because the live code (Business Class) uses a Factory to get the Repository, in the unit test you plug in the MockRepository for the TaxRateRepository. Once the substitution is made, you can hard code the return value and make the database unneccessary.
class MyUnitTestFixture {
var rep = new MockTaxRateRepository();
[FixtureSetup]
void ConfigureFixture() {
RepositoryFactory.SetTaxRateRepository(rep); }
[Test]
void Test() {
var region = "NY.NY.Manhattan";
var rate = 8.5m;
rep.ReturnValue = new TaxRate { Rate = rate };
var r = Business.GetRate(region);
Assert.IsNotNull(r);
Assert.IsTrue(rep.GetWasCalled);
Assert.AreEqual(region, rep.KeyParamValue);
Assert.AreEqual(r.Rate, rate); }
}
Remember, you want to test the business logic method only, not the repository, database, connection string, etc... There are different tests for each of those. By doing it this way, you can completely isolate the code that you are testing.
A side benefit is that you can also run the unit test without a database connection, which makes it faster, more portable (think multi-developer team in remote locations).
Another side benefit is that you can use the Test-Driven Development (TDD) process for the implementation phase of development. I don't strictly use TDD but a mix of TDD and old-school coding.
In one sense, I think your question boils down to simply, "why use interfaces and not abstract classes?" Technically, you can achieve loose coupling with both -- the underlying implementation is still not exposed to the calling code, and you can use Abstract Factory pattern to return an underlying implementation (interface implementation vs. abstract class extension) to increase the flexibility of your design. In fact, you could argue that abstract classes give you slightly more, since they allow you to both require implementations to satisfy your code ("you MUST implement start()") and provide default implementations ("I have a standard paint() you can override if you want to") -- with interfaces, implementations must be provided, which over time can lead to brittle inheritance problems through interface changes.
Fundamentally, though, I use interfaces mainly due to Java's single inheritance restriction. If my implementation MUST inherit from an abstract class to be used by calling code, that means I lose the flexibility to inherit from something else even though that may make more sense (e.g. for code reuse or object hierarchy).
One reason is that interfaces allow for growth and extensibility. Say, for example, that you have a method that takes an object as a parameter,
public void drink(coffee someDrink)
{
}
Now let's say you want to use the exact same method, but pass a hotTea object. Well, you can't. You just hard-coded that above method to only use coffee objects. Maybe that's good, maybe that's bad. The downside of the above is that it strictly locks you in with one type of object when you'd like to pass all sorts of related objects.
By using an interface, say IHotDrink,
interface IHotDrink { }
and rewrting your above method to use the interface instead of the object,
public void drink(IHotDrink someDrink)
{
}
Now you can pass all objects that implement the IHotDrink interface. Sure, you can write the exact same method that does the exact same thing with a different object parameter, but why? You're suddenly maintaining bloated code.
Its all about designing before coding.
If you dont know all the relationships between two objects after you have specified the interface then you have done a poor job of defining the interface -- which is relatively easy to fix.
If you had dived straight into coding and realised half way through you are missing something its a lot harder to fix.
You could see this from a perl/python/ruby perspective :
when you pass an object as a parameter to a method you don't pass it's type , you just know that it must respond to some methods
I think considering java interfaces as an analogy to that would best explain this . You don't really pass a type , you just pass something that responds to a method ( a trait , if you will ).
I think the main reason to use interfaces in Java is the limitation to single inheritance. In many cases this lead to unnecessary complication and code duplication. Take a look at Traits in Scala: http://www.scala-lang.org/node/126 Traits are a special kind of abstract classes, but a class can extend many of them.