Primary Imperative in Software Development
Managing complexity is the most important technical topic and known as the primary imperative in software development.
- Software can inherently be complex; you need to write code which compensates for human limitations.
- Most project fail because of poor requirements, planning, or management.
- When a project fails for technical reasons it is often due to uncontrolled complexity.
- Software can grow so complex that no one understands it and one change can affect the whole system.
- The solution is to divide a system into subsystems.
- The goal of all software design techniques.
- The more independent subsystems are, the more you can focus on one at a time.
- Keeping routines short make them easier to understand.
- Minimize complexity derived from the problem.
- Limit the complexity that comes from optional/ incidental choices.
- Make Designs which are simple and easy to understand.
- Avoid being ‘clever’.
- Design should let you focus on one part while ignoring the others (abstraction/ compartmentalization).
Ease of Maintenance
- Design so maintenance programmers can do their jobs.
- Anticipate questions they would ask.
- Design a system that is self-explanatory.
Loose coupling/High cohesion
- Connections between the parts of the program are minimized.
- Components do a single, simple, well-defined thing.
- Use abstraction, encapsulation, information hiding.
- Makes it easier to integrate, test and maintain § Changes don’t affect the whole program.
Coupling: A measure of interconnectivity and dependence between different modules within a code base.
- When aspects of a system are highly dependent on each and intertwined they are referred to as highly coupled.
- Alternatively, when the interconnectivity between modules are minimized, they are referred to as loosely coupled.
- When modules have no interconnection among themselves then they are referred to as uncoupled.
Cohesion: A metric used to describe how focused a module is performing a particular task.
- A module with high cohesion is one that has been designed with a well defined purpose and has minimized connections.
- Alternatively, a module with low cohesion has a broader purpose and scope and may perform multiple unrelated tasks.
- Generally high cohesion is associated with loose coupling, and is preferable to low cohesion, which is associated with high coupling.
- There is a certain balance between the two, however, for instance if one where to write a very simple program or performance critical application, highly coupled, low cohesive code may outweigh the overhead required for loosely coupled and highly cohesive code.
- Can add to the system without rewriting large parts of it.
- Components (functions, classes, etc.) can be reused in other parts of the system.
High fan-in: having a high number of classes that use a given class.
- High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system.
Low-to-medium fan-out: having a given class use a low-to-medium number of other classes.
- A class does not use too many other classes.
- High fan-out (more than about seven) indicates that a class uses a large number of other classes and may therefore be overly complex.
- It should be easy to move to another platform.
- Don’t use a lot of system-specific functions.
- System calls are wrapped in a function which abstracts the details.
- Keep layers of the system separate.
- Don’t have high level details appear in low levels of the system.
- Don’t have low level details appear at the topmost level.
- Use common organization and feel so developers will find it easier to work with.
- Don’t start religious wars about formatting, use a standard.
- Each part should not look like it was designed by a different person.
- This would force later developers to constantly try to understand what is going on.