]
]Most hard-core project courses place much emphasis on the design of the system. Here are some things to keep in mind when designing your system.
For example, parsing (and things related to the "parsing" concern) should be done by the parser component, and everything that has to do with sorting should be done by the sorter component.
Keep unrelated things independent of each other. For example, if the parser component can function without any knowledge of the sorter component, then the sorter is a stranger to the parser. That means the parser should not have any reference to the sorter (E.g., can you compile the parser without compiling the sorter?)
A classic example where this principle applies is when choosing between a central controller model and chain of controllers model. The former lets you keep strangers as strangers, while the latter forces strangers to talk to each other.
TODO: elaborate on the above, with an example
Fred Brooks contends that (in
The Mythical Man-Month, page 42)
... the conceptual integrity is the most important consideration in system design. It is better for a system to omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.A student team is a team of peers, which usually does not have a designated architect to dictate a design for others to follow. Everyone may want to have their say in the design. However, after discussing all alternative designs proposed, you should still choose one of them to follow, rather than devise a design that combines everyone's designs (sometimes combining ideas into one design has merits, but do not do it just for the sake of achieving a compromise between competing ideas). If in doubt, get your supervisor's opinion as well.
Similar problems should be solved in a similar fashion. Sometimes it pays to solve even slightly different (yet largely similar) problems in exactly the same way. It makes programs easier to understand. Read in a different way, do not go out of your way to customize a solution to fit a problem precisely; It may be better to preserve the similarity of the solution instead.
This is also related to the idea of conceptual integrity.
Patterns (design patterns, as well as other types of patterns such as analysis patterns, testing patterns, etc.) embody tried-and-tested solutions to common problems. Learn patterns, and use them where applicable.
Most patterns come with extra baggage. Do not use patterns for the sake of using them. For example, there is no need to apply the Singleton pattern to every class that will have only one instance in the system; use it when there is a danger of someone creating multiple instances of such a class.
Simple yet elegant designs are much better than complex (and hence ugly) solutions; The former is much harder to achieve however, but that's what you should aim for. Given any design, try to see whether you can simplify it. Resist any change that makes it more complex.
Try to make the design as simple as possible (but no simpler!).
Hoare wasn't kidding. Opt for a simple design. If it is fast enough, stick with it. If it is not, find the bottlenecks (using profiling tools) and optimize accordingly.
Caveat: this does not mean that you should start with a stupid design. Some designs are obviously inefficient and should be discarded immediately. Start with a design that is as simple as possible, but no simpler.
During analysis and design, consider all the known facts, but do not fret about all unknowns. If you are given a concrete and stable specification (e.g., writing a parser for a given language), it would be stupid to start with a design that does not take into account all details of the given specification. Such short-sighted designs will eventually require change, causing rework that should have been avoided. On the other hand, if you are defining a first-of-a-kind exploratory system for an unspecified user base, go for a design with a reasonable degree of flexibility; do not worry about all nitty-gritty things that it might (or might not) have to face later.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.8, 3rd Sept 2008, Copyrights: Damith C. Rajapakse |---