OOD Principles | Ross's Page

OOD Principles

Why we need OOD principles?

Object Oriented Programming (OOP) languages brings us abstract data type, encapsulation, inheritance and polymorphyism, which give us tremendous flexibility and also the ability to reuse and extent existed modules in development.

Unfortunately, flexibility is not only a powerful weapon in handling real world problems, but also it may cause our design to go the wrong way, which means our projects may get harder and harder to maintain and add new features when the scale of them grow bigger and bigger. Hence we need some fundamental principles or best practice to help us during OOD (Object Oriented Design).

What are the fundamental principles for OOD?

In 2000, Robert Cecil Martin wrote an article called Design Principles and Design Patterns and introduced so called SOLID principles to help us to do robust and easy-to-extend design. Uncle Bob(Robert’ s nickname well known in developer community) published another book in 2002 named Agile Software Development: Principles, Patterns, and Practices to systematically elaborate these principles. In his official blog, he has gave the short but precious definition of them:

  • SRP (Single responsibility principle) - A class should have one, and only one, reason to change.
    [xiaohui] This principle is to achieve the goal of high cohesion and low coupling. A class should have one and only one responsibility and focus on doing certain things highly related to itself, it should only be affected by only one potential specification change.
  • OCP (The Open Closed Principle) - You should be able to extend a classes behavior, without modifying it.
    [xiaohui] This principle is to achieve scalability more easily by being open to extension and closed to modification. Since in this way we do not need to change the existed and released code, we do not need to be worried about compatibility issue and potential regression.
  • LSP (The Liskov Substitution Principle) - Derived classes must be substitutable for their base classes.
    [xiaohui] This principle is also the basic requirment of polymorphism, we should be able to base class instance wherever derived class instance can be used, that is how we achieve dynamic binding of class behaviors.
  • ISP (The Interface Segregation Principle) - Make fine grained interfaces that are client specific.
    [xiaohui] This principle is also the requirment of high cohesion and low coupling, it helps us to lower down the dependency of different modules and brings us more flexibility.
  • DIP (The Dependency Inversion Principle) - Depend on abstractions, not on concretions.
    [xiaohui] This principle requires us to forget about the layer-ed design. We should not let high-lever modules depend on low-level modules and let abstraction depends on concretions. Because in this way, any change of the high-level modules which indicate the functionalities may require us to change the implementation of low-level modules in waterfall style, this can be the nightmare when we face future scalability and extensions. What we should do is to let both high-level and low-level modules depend on abstraction and let detailed implementation depend on abstraction.

Following the guidance of these principles could truly help us, like this:

There are More

The Gang Of Four(GOF) introduced 23 design patterns in the book Design Patterns: Elements of Reusable Object-Oriented Software , these patterns then have been widely discussed in OOP developer community and practiced ever since. Most of these patterns actually respect SOLID principles, except some of them for certain scenarios like Singleton violating SRP and Facade violating OCP.

Trade off and options

Both SOLID principles and the 23 design patterns are not so-called silver bullets. The real world problems and software specification can be extremly complicated, not to mention that requirments changes almost always happend in most projects. They are guidance, understanding them and getting familiar with when and how to apply them with trading off based on current resources and deadlines is the key. For a project developed by more than one person, The Mythical Man-Month: Essays on Software Engineering has already conviced us besides having the correct design and development skills, there are other things like progress tracking, team management, continuous integration, etc that could critically impact the result of the project. I myself stand by this according to my 7 years development and team management experience.

Uncle Bob introduced Agile development style in the book mentioned above and gave a solution for project quality assurance, progress tracking process and the recommended ways to handle requirment changes. With all of these guidances along with SOLID principles he concluded and other principles about module package also introduced by him, we have a whole roadmap to try our best to achieve our goal.

-- EOF --

声明: 本文采用 BY-NC-SA 协议进行授权. 转载请注明转自: OOD Principles

comments powered by Disqus