UP | HOME
2015-10-15 | ../../ |

Object Oriented Design Principles: SOLID, …

Table of Contents

1 Data Encapsulation v Abstraction v OOD

1.1 Encapsulation

  1. A "data structure" is declared.
  2. Certain operations are declared to be "public".
  3. The "data structure" is accessed/manipulated only via the above.

1.2 Abstraction

  1. A "data type" is declared
  2. Certain operations are available
  3. The "data type" is an abstraction
  4. Concrete representation to Abstraction mapping
  5. E.g., an array of items ==> set of items
  6. Information Hiding Principle
  7. Abstract Data Types v Classes
  8. Data Encapsulation v Data Abstraction
  9. See ../Abstraction

1.3 Class Invariants

  1. Class invariants are assertions.
  2. Must be true before and after every public methods.
  3. Must be true after every constructor.
  4. See ../Assertions

1.4 C++/Java/… Classes

  1. Provide data encapsulation
  2. Do not do Data Abstraction
  3. Language Design
  4. public v protected v private
  5. interface v class

2 SOLID Principles of Class Design

  1. (SRP) The Single Responsibility Principle
  2. (OCP) The Open Closed Principle: Classes and methods should be open for extension (of functionality) and closed for modification.
  3. (LSP) The Liskov Substitution Principle. Loosely stated: Subtypes must be substitutable for super type. A sub class must enhance functionality, but not reduce.
  4. (ISP) The Interface Segregation Principle
  5. (DIP) The Dependency Inversion Principle
  6. Note that some argue that LSP is not an OOD principle.
  7. In this course: We replace the above with Design by Contract This is often confused with LSP.
  8. All the above in greater detail at ./SOLID-principles.html

3 Principles of Package Cohesion

  1. (REP) The Reuse Release Equivalence Principle
  2. (CCP) The Common Closure Principle
  3. (CRP) The Common Reuse Principle

4 Principles of Package Coupling

  1. (ADP) The Acyclic Dependencies Principle
  2. (SDP) The Stable Dependencies Principle
  3. (SAP) The Stable Abstractions Principle

5 Design By Contract (DoC)

./design-by-contract.html

6 Liskov Substitution Principle (LSP)

./liskov-subst-principle.html

7 AntiPatterns

  1. "An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive."
  2. ./antipatterns.html

7.1 Examples from non-CS

  1. Bicycle shed: Giving disproportionate weight to trivial issues
  2. Escalation of commitment: Failing to revoke a decision when it proves wrong
  3. Peter Principle: Continually promoting otherwise well-performing employees up to their level of incompetence, where they remain indefinitely
  4. Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization
  5. Ninety-ninety rule: Tendency to underestimate the amount of time to complete a project when it is "nearly done"

7.2 Examples from Software engineering

  1. Abstraction inversion: Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls
  2. Big ball of mud: A system with no recognizable structure.
  3. Input kludge: Failing to specify and implement the handling of possibly invalid input
  4. Call super: Requiring subclasses to call a superclass's overridden method
  5. God object: Concentrating too many functions in a single part of the design (class)
  6. Sequential coupling: A class that requires its methods to be called in a particular order. (?)
  7. Poltergeists: Objects whose sole purpose is to pass information to another object
  8. Boat anchor: Retaining a part of a system that no longer has any use
  9. Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
  10. Lasagna code: Programs whose structure consists of too many layers.

8 References

  1. Web site, http://www.oodesign.com Includes pretty good descriptions of the principles mentioned on this page. Recommended Visit
  2. https://en.wikipedia.org/wiki/Anti-pattern A few selected items are given above. Software Engineering section: Required Reading.
  3. https://sourcemaking.com/ has most of the above materials presented well.
  4. http://antipatterns.com/ Recommended Visit.
  5. Robert Bruce Findler, Mario Latendresse, and Matthias Felleisen. Behavioral Contracts and Behavioral Subtyping. In Proceedings of ESEC/FSE-9, 229-236. http://www.ccs.neu.edu/scheme/pubs/fse01-flf.pdf 2001 Recommended Reading.
  6. Bertrand Meyer. Applying "Design by Contract". IEEE Computer, 25(10):40–51, October 1992. http://se.ethz.ch/~meyer/publications/computer/contract.pdf Also in his book "Object-Oriented Software Construction". Bertrand Meyer's article marked-up by pmateti Required Reading.

9 End

Copyright © 2015 www.wright.edu/~pmateti 2015-10-15