Design in Practice
Software design during construction is about making decisions at the class, method, and module level. Good design decisions during construction lead to code that is easier to understand, modify, and extend.
Design Principles for Construction
+---------------------------------------------------------+
| KEY DESIGN PRINCIPLES |
+---------------------------------------------------------+
| |
| Single Responsibility Principle |
| - A class should have only one reason to change |
| |
| Open/Closed Principle |
| - Open for extension, closed for modification |
| |
| Liskov Substitution Principle |
| - Subtypes must be substitutable for base types |
| |
| Interface Segregation Principle |
| - No client should depend on methods it doesn't use |
| |
| Dependency Inversion Principle |
| - Depend on abstractions, not concretions |
| |
+---------------------------------------------------------+
Design by Contract
Design by Contract specifies formal, precise, and verifiable interface specifications for software components. Each function has preconditions (what must be true before), postconditions (what will be true after), and invariants (always true for the class).
// Design by Contract example
/**
* @pre divisor != 0
* @post result * divisor == dividend
*/
public int divide(int dividend, int divisor) {
assert divisor != 0 : "Division by zero";
int result = dividend / divisor;
assert result * divisor == dividend : "Postcondition failed";
return result;
}
Heuristics for Construction Design
- Find real-world objects and model them as classes
- Keep coupling loose — minimize dependencies between modules
- Keep cohesion high — related functionality belongs together
- Design for change — anticipate where the code will evolve
- Use composition over inheritance when possible
Key Takeaways
- Design decisions during construction have lasting impact
- SOLID principles guide good class and module design
- Design by Contract makes interfaces explicit and verifiable
- Good heuristics lead to maintainable, flexible code