These days I’ve been asked to teach these junior software developers several advanced features of Object Oriented Programming and I’ve started this class of Design Patterns. This is a drought, a skeleton, to develop the course.

What are Design Patterns? I don’t know, ;). Can be thought as grounded best practices to solve a class of problems, to have the most general and flexible solution for them. To define what patterns are we have to think about advanced application design. The advanced practice in software developing is to separate the thinks that change from the ones that stay the same. We introduce this abstraction layer into our applications to isolate changes and keep them to propagate other changes throughout the code (of course, the difficult part is to identify what change). Once you have isolated the changes in your code you have some kind of a pattern. Is it a Design Pattern? Nope, you will achieve it when you go with the most general solution.

Four problem solving techniques:

  • language specific – when use language features to get the problem solved;
  • specific design – when use the described technique to solve specific problem;
  • standard design – to solve some kind of problems (repetitive reusable pieces of codes);
  • design patterns – the most general and flexible solution for a class of problems.

Do not let them fool you with words – generalizing is not a goal, is a means. Do not waste your time looking for patterns, start thinking about your problem and in time they will be revealed.

Classifying patterns:

  • Creational – how objects are created; used to isolate the details of object creation;
  • Structural – the way objects are connected with other objects so changes in the system do not affect these connections;
  • Behavioral – objects that handle particular actions.

The laws of application design:

  • the simplest solution is the best; of course you have to consider full application life-cycle, but simplicity is the base;
  • avoid duplication;
  • isomorphism – one abstraction per class, one class per abstraction;
  • consistency – keep your ideas in place;
  • low coupling, high cohesion – coupling refers to the degree to which the objects depend on each other, cohesion refers to the degree to which the objects belong together;
  • keep your code readable (my first choice);
  • keep surprises out;
  • make common things easy and rare things possible;
  • use YAGNI – the design is finished when anything cannot be removed;
  • keep your unit testing updated.

G