I never really got the point of interfaces in Java. That is because I assumed that you start with the object and then see the interfaces as a way of presenting views on the object. I often saw interfaces and objects that fall into the antipattern of
object fooImpl Implements foo
Joe pointed out that for a shop object, there should not be a shop interface, Rather, a delivery van object would use a destination interface, a bank object would use an account holder interface and a customer object would use a product supplier interface. Each of these three interfaces would be implemented using a shop object. An interface is a role that an object plays.
In terms of designing a system, the interfaces should be identified by the objects that use them. An object should then implement the interfaces. As a result I see that Mock Objects neatly support this design approach. It also supports the design process that JBehave encourages. I now realise what Joe and Nat have been talking about when they talk about Mock Roles
There is an analagy to lean manufacturing. Objects should "pull" functionality out of other objects using interfaces rather than objects pushing interfaces out based upon the functionality in the object that implements them. The interface comes first, the implementation object comes second. Thus the anti pattern
object fooImpl Implements foo
identifies where the interface is being pushed out the implementation object rather than pulled out of an object that needs it.
Posted by chrismatts at December 6, 2004 2:14 PM