SOLID

In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. It is not related to the GRASP software design principles. The principles are a subset of many principles promoted by American software engineer and instructor Robert C. Martin.[1][2][3] Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.[3] The theory of SOLID principles was introduced by Martin in his 2000 paper Design Principles and Design Patterns,[2][4] although the SOLID acronym was introduced later by Michael Feathers.[5]

This article is about the SOLID principles of object-oriented programming. For the fundamental state of matter, see Solid. For other uses, see Solid (disambiguation).
SOLID
Principles

Concepts
Single-responsibility principle[6]
A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.
Open–closed principle[7]
"Software entities ... should be open for extension, but closed for modification."
Liskov substitution principle[8]
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Interface segregation principle[9]
"Many client-specific interfaces are better than one general-purpose interface."[4]
Dependency inversion principle[10]
One should "depend upon abstractions, [not] concretions."[4]
gollark: This is why we should replace inconsistent and hard to render maths notation with glorious S-expressions.
gollark: ... what even
gollark: There was some nice elegant explanation I forgot. IIRC it's something to do with the derivative of e^x being equal to itself.
gollark: I assume you're doing binomial distributions if whatever A-level spec you do is similar to mine, which it probably is, in which case I don't think they cover anything more advanced than trial and error/look at a table for that. Although it's probably <=/>= instead of = 0.02, as there's no guarantee that there is any x satisfying the = version.
gollark: It *also* matters how it's distributed.

See also

References
  1. Robert C. Martin. "Principles Of OOD". butunclebob.com. Retrieved 2014-07-17.. (Note the reference to “the first five principles”, though the acronym is not used in this article.) Dates back to at least 2003.
  2. Robert C. Martin. "Getting a SOLID start". objectmentor.com. Retrieved 2013-08-19.
  3. Sandi Metz (May 2009). "SOLID Object-Oriented Design". Retrieved 2019-08-13. Talk given at the 2009 Gotham Ruby Conference.
  4. Robert C. Martin. "Design Principles and Design Patterns" (PDF). Archived from the original (PDF) on 6 September 2015.
  5. Fenton, Steve (2017). Pro TypeScript: Application-Scale JavaScript Development. p. 108. ISBN 9781484232491.
  6. "Single Responsibility Principle" (PDF). objectmentor.com. Archived from the original (PDF) on 2 February 2015.
  7. "Open/Closed Principle" (PDF). objectmentor.com. Archived from the original (PDF) on 5 September 2015.
  8. "Liskov Substitution Principle" (PDF). objectmentor.com. Archived from the original (PDF) on 5 September 2015.
  9. "Interface Segregation Principle" (PDF). objectmentor.com. 1996. Archived from the original (PDF) on 5 September 2015.
  10. "Dependency Inversion Principle" (PDF). objectmentor.com. Archived from the original (PDF) on 5 September 2015.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.