Quote:Original post by dingojohn
Quote:Original post by GoF
Program to an interface, not an implementation.
Right. I will.
Now, if it was to code to an interface, i'd do something like
You're misinterpreting the GoF book. When they explain that you should program to an interface, they do not mean that you should create an "
interface type in the UML sense" and then derive your class from it. That would be pretty pointless in cases where abstraction isn't needed or even welcome.
They mean that you should first decide on the "
interface in the class/function signature sense" of your class, which describes how it will be
used, and only then concern itself with how it will
work. That is, first write a few quick prototypes of how the class is going to be used: typical construction pattern, typical use cases with usage patterns, interaction with standard library constructs or other constructs from within your code, and so on. Once you've settled on a clean set of public members for your object, you can decide what its private members are (both data and methods) and implement the public methods (which until then were merely throwing stubs) in terms of those private members.