2 Synthesis‎ > ‎Computing‎ > ‎Programming‎ > ‎

Dependency Injection

Why dependency injection and why inversion of control?

Does the tail wag the dog?


Now Robert Cecil Martin who wrote some papers all this is based on, should know better but he seems to have made a good living out of all kinds of silly programming paradigms that reflect some aspects of proper general engineering practice.

Here they are;
The first paper starts with the sentence "What is it about OO that makes designs more robust, more maintainable, and more reusable?" Sorry but has this guy ever managed a C++ project of any size? False, false, true, is my response and I am still doubtful about the last of these even.

OK he than clears himself with "This paper presents the case that simply using objects to model an application is insufficient to gain robust, maintainable and reusable designs. That these attributes are based upon a pattern of interdependencies between the sub-systems of the design that support communications within the design, isolate reusable elements from non-reusable elements, and block the propagation of change due to maintenance." OK I'm interested.

He goes on to say that "What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design." Surely there should be a strict dependency hierarchy so that sub-systems only depend on sub-sub-systems. The kind of problems he talks about are surely the result of spaghetti programming.

He gives an example of a copy class that sits on a keyboard and printer class, which is then replaced by a copy class sitting on a reader class and writer class from which the keyboard and printer classes are derived. What he then claims to have done is isolated the things that are depended on. i.e. the reader and writer class which are very simple and so should not need to be changed and would have a big impact if they were. Thus programmers are left to mess with the other classes provided they don't break these interfaces. Common sense for anybody in the game for long enough but in fact the programmers shouldn't have been messing about with the interfaces in the the first place.

In the second paper besides repeating some of the first he argues that in a hierarchy of classes those classes at the top of the hierarchy will be forced to change by classes lower in the hierarchy and that it should be the other way around. Well yes if there were less low level classes than high level classes this would make sense but its usually not the case.

So in conclusion I thing inversion of control as a general rule is no substitute for proper programming.

Call me old fashioned.

Now don't get me wrong I am not against well defined largely fixed interfaces. Its just that if a programmer is changing his interfaces all the time than they probably aren't very good right.


© Tom de Havas 2011. The information under this section is my own work it may be reproduced without modification but must include this notice.







Comments