Sponsored Link •
|
Advertisement
|
The Guidelines:
The higher up the inheritance hierarchy a type is, the more abstract its contract is. Contracts become more concrete as you go down the hierarchy. Code coupled to types higher up the inheritance hierarchy is more flexible, because the contract is more abstract. The contract can be fulfilled in more ways. So you should make the type as high up as possible, but no higher. If you make it higher than is really required, then clients will have to downcast in their code.
Be suspicious of interpreters. One way to express intent is in a well-formed string of a language. I built a lot of these at one point in my career. You define a language, and the semantics, the meaning of various strings in that language. You then build an interpreter for that language, that sucks in well-formed strings (i.e., programs) and then does something. For example, a Java compiler gives error messages and generates class files. In a Java program, you can actually have objects passing strings to each other that indicate semantics of what the client is asking the object to do.
The thing is that this is object-oriented API design is designing with types, in which you attach semantics to types, whose contracts are expressed in terms of behavior. Designing a context free langauge, or a regular language, an XML schema or XML DTD, or a network protocol, etc, is data model design, in which you define what the data can look like and what the meaning of it is.
One thing you can do with interpreter is make your system "customizable" by defining a scripting language. But another way to do that, which you may wish to consider, is to define a type and use dynamic extension. Allow clients to define and indicate the names of new classes that implement some interface or extend some class you define in your API. Your system can dynamically load and use this customized type.
Sponsored Links
|