Posted by Ron Kersic in the late evening: February 7th, 2007
The origins of lean thinking lie in production and there’s quite a bit of interest in finding parallels between current software development practices and those of manufacturing. The Poppendiecks for instance, frequently quote examples from classic manufacturing companies (Ford, GM, Dell, Toyota) to help understand why agile methods are a very effective approach to software development. Oddly enough they (and many, many others) are hesitant to buy fully into the concept that manufacturing industries and software development have indeed much in common.
Posted by Serge Beaumont in the wee hours: August 4th, 2006
We’ve put up a new article on the Articles page. Summary follows:
The article Factories are about abstraction, not creation told what factories are for, and when they should be used. This article will show different ways to implement factories. The complexity that is needed for a factory implementation depends on the required flexibility and how much effort is needed to construct a complete instance:
- when should it be possible to configure the factory repository: can it be coded and remain fixed for a release or should it be configurable at runtime?
- does the client of a factory need to influence the subclass choice in some way?
- how complex is the algorithm to determine the correct subclass?
- how difficult is it to construct a valid instance of the required class?
Posted by Serge Beaumont around lunchtime: July 19th, 2006
We’ve put up a new article. Summary follows:
Polymorphism is the main mechanism to create maintainable object-oriented code. Client code uses other code through an abstract interface, and as long as we don’t break the behavioral contract, we can change the implementation behind that interface at will.
You will only achieve real maintainability if client code has dependencies to other code through an abstract interface and nothing else.
Unfortunately creational logic will – by its very nature – break this rule. When you create an instance, at some point you will
need call the constructor on the actual implementing class. This creates a dependency that prevents you from changing the implementation transparently, effectively cancelling the advantages of polymorphism.
The solution to the creational problem is to protect the abstraction by hiding the creational logic from the client code. Dependency injection is the ideal solution, in this case the client does not use creational logic at all. But in its turn the injecting code needs to create real instances.
This article is the first of a series of three: this article will illustrate how the creational problem manifests itself, the second will deal with some advanced implementations of creational code, and the third will deal with dependency injection.