Related
Theoretical question: The best practice is not to do any work in constructor, not new, nothing besides setting members.
In the simple example (dependency injection) with the need to load a file from disk to a member in order for the class to work properly, where should I do the "work"? In some initialize function I need to remember to invoke?
For example:
XDocument.Load(someFilePath) ;
The best practice is to not do any work in injection constructors as Mark Seemann clearly explains here. So in case you need to load a file from disk, you should either do it during startup (if possible), or postpone the creation and do it after the object graph is built. This is usually not a nasty workaround, and Lazy is a great mechanism to postpone the creation of things. Example:
class ApplicationConfiguration
{
private readonly Lazy<XDocument> configFile;
public ApplicationConfiguration(Lazy<XDocument> configFile) {
this.configFile = configFile;
}
public T GetValue<T>(string key) {
return (T)this.configFile.Value.Root.Find(key).Value;
}
}
But one warning about Lazy<T>. Although it can (and should) be used to postpone the creation of things, make sure that you don't abuse it as a leaky abstraction. For instance, don't inject the same Lazy<T> dependency in many classes. For instance, say that you have an ILogger abstraction and you get an implementation that is time expensive to create. You might be tempted to start injecting Lazy<ILogger> all over the place, but now you're leaking implementation details, since the fact that this logger is expensive to create is an implementation details, but now all consumers of ILogger know about this, and you just have to accidentally inject ILogger directly once to break this optimization.
So instead, create a proxy class that implements ILogger and depends on Lazy<ILogger> and inject this proxy into all consumers. This way all consumers can keep depending on ILogger, without the need to know that the creation of the logger is delayed.
I'm looking for some good examples of code that violates the Single Responsibility Principle. Don't show me any examples from Uncle Bob's books or web sites since those are plastered all over the internet, like this one:
interface Modem
{
public void dial(String pno);
public void hangup();
public void send(char c);
public char recv();
}
The granularity of your OO design is a matter of taste and might be inapropriate for others. Thus, I wouldn't look for examples of breaking the single responsibility principle in some business-logic-class, discussing whether it has too much or too little to do.
In my opinion, the best examples (with worst side-effects) come from breaking the layering of your application. F.ex.:
Performing business logic in the data access layer (whose only responsibility should be providing persistence access to the application)
Accessing business services from (through) the domain model (whose only responsibility should be to store most of the application's state)
Performing complex business logic in the view layer (responsible for data presentation & user input)
Here's some code from a PHP project I had to take on:
class Session
{
function startSession()
{
// send HTTP session cookies
}
function activateUserAccount()
{
// query the DB and toggle some flag in a column
}
function generateRandomId()
{}
function editAccount()
{
// issue some SQL UPDATE query to update an user account
}
function login()
{
// perform authentication logic
}
function checkAccessRights()
{
// read cookies, perform authorization
}
}
I believe this class does waaay to much.
The clue about SRP is to define the responsibilities so that your implementation does just that thing. It's like you're making a rule (by giving a class a name and a responsibility) and then trying to follow it.
So if you're not following it you're either not defining the rule properly or you're being inconsistent while implementing it (or both, which might actually be the most common case).
I generally find the classes that do not give a half-decent try at defining a single main responsibility or good name to be the best violations. Then you'll just have to read the whole class to try to determine if there's any well defined responsibilities at all.
Actually, in most OO languages that I have used, the top-level Object class is a good example. In Ruby, for example, the Object class (or more precisely the Kernel mixin, which gets mixed into Object) has 45 public instance methods. Now, some of those are aliases, but there's still got to be at least 20, and they are from all over the place. I can easily identify at least 5 responsibilities.
Now, I don't mean to pick on Ruby. It is my favorite programming language. That's why I used it as an example: because it's the language I'm most familiar with. And I am reasonably sure that what I wrote about Ruby applies 100% also to at least Java and .NET.
It's a qualitative question to ascertain the 'responsibilities' of a class.
Just looking at a given class code, can in no measure give us an idea of how well it handles it's repsonsibility.
It is very necessary, atleast as per my experience, to take into account how the requirement changes to the class will propagate to other modules ( or how will the changes from other classes get propagated to this class).
As #schmeedy gives a nice explanation of 'breaking the layering of the system' , which I think is just one of the ways to analyse 'responsibility domain'.
I have attempted to take the discussion little further. My attempts are to define 'responsibility' in a quantitative way.
Some discussions at my blog: http://design-principle-pattern.blogspot.in/2013/12/single-responsibility-principle.html
#import <Foundation/Foundation.h>
#import <CoreGraphics/CoreGraphics.h>
#interface Spreadsheet : NSObject
- (void)loadFromURL:(NSURL *)url;
- (void)saveToURL:(NSURL *)url;
- (void)drawTo:(CGRect*)targetArea withContext:(CGContextRef *)context;
#end
I would argue that the above example violates the SRP.
On the face of it, it is clear that the class is responsible for one thing: Spreadsheets. It is distinguished from other entities in the Document Management problem domain such as Word Processing.
However, consider the reasons why the Spreadsheet object could change.
There may be a change to the model underlying the Spreadsheet. This affects load and save code but would not affect how the Spreadsheet is drawn. So the load/save responsibilities are separate from the drawing responsibilities. Our class has two responsibilities.
So if we think about all the reasonably foreseeable reasons to change a class, and see that only particular methods on the class would be affected, we see an opportunity to factor out a responsibility to get a more focussed class.
A revised class would be:
#interface SpreadsheetEncoder
- (NSData *)encodedSpreadsheet:(Spreadsheet *)spreadsheet;
- (Spreadsheet *)spreadsheetFromEncodedData:(NSData *)data;
#end
#interface Spreadsheet2 : NSObject
- (NSData *)data;
- (instancetype)initSpreadsheetFromData:(NSData *)data;
- (void)drawTo:(CGRect*)targetArea withContext:(CGContextRef *)context;
#end
As product development advances, we can ask ourselves again 'what could change' and then refactor the classes to keep them responsible for only one concern. SRP is only relative to the problem domain and our understanding of it at a given time.
SRP in my view boils down to asking 'what can change?' and 'what would be affected'. When 'what can change' maps onto only one thing that is affected, you have classes that implement the SRP principle.
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.
I'm a big fan of TDD and use it for the vast majority of my development these days. One situation I run into somewhat frequently, though, and have never found what I thought was a "good" answer for, is something like the following (contrived) example.
Suppose I have an interface, like this (writing in Java, but really, this applies to any OO language):
public interface PathFinder {
GraphNode[] getShortestPath(GraphNode start, GraphNode goal);
int getShortestPathLength(GraphNode start, GraphNode goal);
}
Now, suppose I want to create three implementations of this interface. Let's call them DijkstraPathFinder, DepthFirstPathFinder, and AStarPathFinder.
The question is, how do I develop these three implementations using TDD? Their public interface is going to be the same, and, presumably, I would write the same tests for each, since the results of getShortestPath() and getShortestPathLength() should be consistent among all three implementations.
My choices seem to be:
Write one set of tests against PathFinder as I code the first implementation. Then write the other two implementations "blind" and make sure they pass the PathFinder tests. This doesn't seem right because I'm not using TDD to develop the second two implementation classes.
Develop each implementation class in a test-first manner. This doesn't seem right because I would be writing the same tests for each class.
Combine the two techniques above; now I have a set of tests against the interface and a set of tests against each implementation class, which is nice, but the tests are all the same, which isn't nice.
This seems like a fairly common situation, especially when implementing a Strategy pattern, and of course the differences between implementations might be more than just time complexity. How do others handle this situation? Is there a pattern for test-first development against an interface that I'm not aware of?
You write interface tests to exercise the interface, and you write more detailed tests for the actual implementations. Interface-based design talks a bit about the fact that your unit tests should form a kind of "contract" specification for that interface. Maybe when Spec# comes out, there'll be a langugage supported way to do this.
In this particular case, which is a strict strategy implementation, the interface tests are enough. In other cases, where an interface is a subset of the implementation's functionality, you would have tests for both the interface and the implementation. Think of a class which implements 3 interfaces, for example.
EDIT: This is useful so that when you add another implementation of the interface down the road, you already have tests for verifying that the class implements the contract of the interface correctly. This can work for something as specific as ISortingStrategy to something as wide-ranging as IDisposable.
there is nothing wrong with writing tests against the interface, and reusing them for each implementation, for example -
public class TestPathFinder : TestClass
{
public IPathFinder _pathFinder;
public IGraphNode _startNode;
public IGraphNode _goalNode;
public TestPathFinder() : this(null,null,null) { }
public TestPathFinder(IPathFinder ipf,
IGraphNode start, IGraphNode goal) : base()
{
_pathFinder = ipf;
_startNode = start;
_goalNode = goal;
}
}
TestPathFinder tpfDijkstra = new TestPathFinder(
new DijkstraPathFinder(), n1, nN);
tpfDijkstra.RunTests();
//etc. - factory optional
I would argue that this is the least effort solution, which is very much in line with Agile/TDD principles.
I would have no problem going with option 1, and keep in mind that refactoring is part of TDD and it's usually during a refactoring phase that you move to a design pattern such as strategy, so I wouldn't feel bad about doing that w/o writing new tests.
If you wanted to test the implementation-specific details of each PathFinder impl, you might consider passing mock GraphNodes which are somehow capable of helping to assert the Dijkstra-ness or DepthFirst-ness, etc, of the implementation. (Perhaps these mock GraphNodes could record how they are traversed, or somehow measure performance.) Maybe this is testing overkill, but then again if you know your system needs these three distinct strategies for some reason, it'd probably be good to have tests to demonstrate why - otherwise why not just pick one implementation and throw the others away?
I don't mind reusing test code as a template for new tests that have similar functionality. Depending on the particular class under test, you may have to rework them with different mock objects and expectations. At the least you'll have to refactor them to use the new implementation. I would follow the TDD method, though, of taking one test, reworking it for the new class, then writing just the code to pass that test. This may take even more discipline, though, since you already have one implementation under your belt and will undoubtedly be influenced by code you have already written.
This doesn't seem right because I'm
not using TDD to develop the second
two implementation classes.
Sure you are.
Start by commenting out all the tests but one. As you make a test pass either refactor or uncomment another test.
Jtf