Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

principles of good OO design , preferably simplified

 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Class Design Principles
=======================

  • The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.
  • The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference. [See previous tip about LSP]
  • The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.
  • The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface/
    Package Design Principles

  • =========================
  • The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
  • The Common Closure Principle: Classes that change together, belong together.
  • The Common Reuse Principle: CClasses that aren't reused together should not be grouped together.
  • The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
  • The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
  • The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.

  • How relevant are these principles today ?
    Or, like many a rule, are they meant to be broken .
    For instance , in the Stable Dependencies principle, the dependee must be more stable than the depender.
    Functional decomposition has dependencies down the hierarchy but must one ensure that the calling function is more stable than the called function ? Oh, and how ?
    regards
     
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm for em!
    BTW: Just opening the back cover of Martin's Agile Software Development, you missed his #1: Single Responsibility Priniciple.
    They are all good things to think about when designing or reviewing a design. There was another thread with some pretty solid arguments against the package rules. I'd try to follow these myself, but stay open to the alternatives.
    I also like the XP values - I may have em out of order:
    * Passes all tests and gives correct results
    * No duplication
    * Code expresses its intention
    * Fewest classes and methods to do the above
    Caveats: Like all rules, they can be broken. XP folk say explicitly they will sometimes conflict one another and you have to choose which fits the situation the best. Some of the metrics suggested to measure them are suspect - a package could be perfectly stable with no interfaces and no abstract classes.
    I'm very interested in motivation for change. In my current project when we add a new group of users, certain things change. When we add a new product other things change. Can I reduce the number of classes that change for each event? Can I eliminate overlap between product changes and group changes?
     
    Marshal
    Posts: 16601
    278
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    For instance , in the Stable Dependencies principle, the dependee must be more stable than the depender.
    Functional decomposition has dependencies down the hierarchy but must one ensure that the calling function is more stable than the called function ? Oh, and how ?


    Isn't it the other way around though? That is, the called function (the dependee) should be more stable than the calling function (the depender).
     
    Enjoy the full beauty of the english language. Embedded in this tiny ad:
    Thread Boost feature
    https://coderanch.com/t/674455/Thread-Boost-feature
    reply
      Bookmark Topic Watch Topic
    • New Topic