Software Design Simplified

I was remotely reviewing a new team member’s code:

It wasn’t that bad, but I wrote him a document suggesting some general design principles. I’m repeating some of them here, because they seemed to be the sort of thing that I would like to refer to often.

  1. For the typical application, start with the 3 basic layers: Front-end (GUI), Back-end (Database) and Business Logic. Give them their own classes within separate projects in the solution.
  • Ensure there are no cyclic dependencies
  1. Establish well-defined interfaces between the layers.
  • Internal implementation within a layer should be modifiable, with minimal (ideally zero) impact on other layers
  • Control should flow cleanly between layers, not back & forth
  1. Don’t duplicate code (or data structures) amongst layers (DRY Principle)

  2. At the highest level, each class should map to a real-world object that you intend to manipulate.

  • Then start breaking down the functionalities and add more classes at the lower levels
  • Try as much as possible to adhere to Object Oriented Principles, and at the very least to the one-class-one-responsibility principle (SOLID) (Annotation: I know it sounds obvious, but you’d be surprised what passes for “object oriented programming” these days)
  1. Don’t try to cover all the possible use cases up-front, instead aim for a design that has a solid foundation, on top which features can be added iteratively (YAGNI Principle)

  2. The earlier you put in place a flexible logging mechanism (whether your own or reused), the happier you’ll be. No application is too small to benefit from logs. Besides debug info, they can also serve a source of useful information that the user need not be burdened with under normal circumstances.

  3. Prioritization: Normally I would proceed in the order:

  • Functionality, Reliability
  • Usability
  • Robustness, Security
  • Efficiency
  • Maintainability, Portability
  1. Tools:
  • Mindmaps for capturing Requirements & Design (Reference)
  • Dia for flowcharts  (Annotation: Yeah, I’m old skool)
  • StarUML for UML Diagrams

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: