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.
- Dont 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. Dont fear that youll end up with procedural-style
spaghetti codeclasses 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
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. Its easy to add
methods, but as time goes on, its difficult to remove methods from a
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 youll 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. Youre creating a framework that you can build on with further iterations. Youre 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. Youll probably discover changes and improvements that can be made to your original architecturethings 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, youre ready to move on and add more functionality.