Object-oriented Design

Updated at 2013-03-31 08:58

This note is about object-oriented design.

Finished software design should always be clean and well organized. The path to this state rarely is.

Before constructing a problem solution, there should always be some form of planning. But many problems are wicked so they cannot be planned property without at least partially solving the problem.

Managing complexity is most important technical topic in software development. When projects fail or slow down because of a technical reason, it is almost always because complexity got out of hand.

With design, you should aim for healthy mix of:

Minimal complexity, aim for simple and easy to understand solutions.
Ease of maintenance, after launch this is most of what you do.
Loose coupling, minimal connections to other modules.
Extensibility, easy to enhance without breaking the underlying code.
High fan-in, one high level class should be used by many.
Low fan-out, one lower level class should use minimum higher level classes.
Portability, easy to move software to new environment.
Leanness, it is not ready when you cannot add anything, it is ready when you cannot remove anything.
Consistent style, give whole system a familiar feeling.

Object oriented levels of design:

Software System
Module / Package
Class
Class public methods and data aka. Interface
Class private methods and data

Usual good packages are:

Business rules
User interface
Database access
System dependencies

Encapsulate and simplify classes and data as much as you can. Always ask "what is private" before writing any code. This reduces complexity.

Never design for performance. Write your programs modular so each part and function can be timed. You can later benchmark which takes the most time and improve only those bottlenecks.