|
 |
|
| |
Guidelines for object development
These stages suggest some guidelines when thinking about developing your classes:
- Let a specific problem generate a class, then let the class grow and mature
during the solution of other problems.
- Remember, discovering the classes you need (and their interfaces) is the
majority of the system design. If you already had those classes, this would be
an easy project.
- Don’t force yourself to know everything at the beginning. Learn as you
go. This will happen anyway.
- Start programming. Get something working so you can prove or disprove your
design. Don’t fear that you’ll end up with procedural-style
spaghetti code—classes partition the problem and help control anarchy and
entropy. Bad classes do not break good classes.
- Always keep it simple. Little clean objects with obvious utility are better
than big complicated interfaces. When decision points come up, use an
Ockham’s Razor[111]
approach: Consider the choices and select the one that is simplest, because
simple classes are almost always best. Start small and simple, and you can
expand the class interface when you understand it better. It’s easy to add
methods, but as time goes on, it’s difficult to remove methods from a
class.
Phase 3: Build the core
This is the initial conversion from the rough design into a compiling and executing body of code that can be tested, and especially that will prove or disprove your architecture. This is not a one-pass process, but rather the beginning of a series of steps that will iteratively build the system, as you’ll see in Phase 4.
Your goal is to find the core of your system architecture that needs to be implemented in order to generate a running system, no matter how incomplete that system is in this initial pass. You’re creating a framework that you can build on with further iterations. You’re also performing the first of many system integrations and tests, and giving the stakeholders feedback about what their system will look like and how it is progressing. Ideally, you are exposing some of the critical risks. You’ll probably discover changes and improvements that can be made to your original architecture—things you would not have learned without implementing the system.
Part of building the system is the reality check that you get from testing against your requirements analysis and system specification (in whatever form they exist). Make sure that your tests verify the requirements and use cases. When the core of the system is stable, you’re ready to move on and add more functionality.
|
|
|
