View source for SOLID

{{Short description|Object-oriented programming design principles}}
{{about|software programming principles|the fundamental state of matter|Solid|other uses|Solid (disambiguation)}}
{{Solid principles}}
In [[software programming]], '''SOLID''' is a [[mnemonic]] [[acronym]] for five design principles intended to make [[object-oriented]] designs more understandable, flexible, and [[Software maintenance|maintainable]]. Although the SOLID principles apply to any object-oriented design, they can also form a core philosophy for methodologies such as [[agile software development|agile development]] or [[adaptive software development]].<ref name="metz-presentation-2009" />
== Principles ==
=== Single responsibility principle ===
[[Single-responsibility principle]] ('''SRP''') states that "[t]here should never be more than one reason for a [[Class (computer programming)|class]] to change."<ref>{{cite web|title=Single Responsibility Principle|url=http://www.objectmentor.com/resources/articles/srp.pdf|url-status=usurped|archive-url=https://web.archive.org/web/20150202200348/http://www.objectmentor.com/resources/articles/srp.pdf|archive-date=2 February 2015|website=objectmentor.com}}</ref> In other words, every class should have only one responsibility.<ref name="cleancode">{{cite book|last1=Martin|first1=Robert C.|url=https://books.google.com/books?id=0HYhAQAAIAAJ|title=Agile Software Development, Principles, Patterns, and Practices|publisher=Prentice Hall|year=2003|isbn=978-0135974445|page=95|authorlink=Robert Cecil Martin}}</ref>
==== Importance ====
*Maintainability: When classes have a single, well-defined responsibility, they're easier to understand and modify.
*Testability: It's easier to write unit tests for classes with a single focus.
*Flexibility: Changes to one responsibility don't affect unrelated parts of the system.<ref name="cleancode" />
=== Open–closed principle ===
[[Open–closed principle]] ('''OCP''') states that "[s]oftware entities&nbsp;... should be open for extension, but closed for modification."<ref>{{cite web|title=Open/Closed Principle|url=http://www.objectmentor.com/resources/articles/ocp.pdf|url-status=usurped|archive-url=https://web.archive.org/web/20150905081105/http://www.objectmentor.com/resources/articles/ocp.pdf|archive-date=5 September 2015|website=objectmentor.com}}</ref>
==== Importance ====
* Extensibility: New features can be added without modifying existing code.
* Stability: Reduces the risk of introducing bugs when making changes.
* Flexibility: Adapts to changing requirements more easily.
=== Liskov substitution principle ===
[[Liskov substitution principle]] ('''LSP''') states that "[f]unctions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."<ref name=":0">{{cite web|title=Liskov Substitution Principle|url=http://www.objectmentor.com/resources/articles/lsp.pdf|url-status=usurped|archive-url=https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf|archive-date=5 September 2015|work=objectmentor.com}}</ref> {{Crossreference|See also [[design by contract]].}}<ref name=":0" />
==== Importance ====
* Polymorphism: Enables the use of polymorphic behavior, making code more flexible and reusable.
* Reliability: Ensures that subclasses adhere to the contract defined by the superclass.
* Predictability: Guarantees that replacing a superclass object with a subclass object won't break the program.<ref name=":0" />
=== Interface segregation principle ===
[[Interface segregation principle]] ('''ISP''') states that "[c]lients should not be forced to depend upon interfaces that they do not use."<ref>{{cite web|date=1996|title=Interface Segregation Principle|url=http://www.objectmentor.com/resources/articles/isp.pdf|url-status=usurped|archive-url=https://web.archive.org/web/20150905081110/http://www.objectmentor.com/resources/articles/isp.pdf|archive-date=5 September 2015|website=objectmentor.com}}</ref><ref name="martin-design-principles" />
==== Importance ====
* Decoupling: Reduces dependencies between classes, making the code more modular and maintainable.
* Flexibility: Allows for more targeted implementations of interfaces.
* Avoids unnecessary dependencies: Clients don't have to depend on methods they don't use.
=== Dependency inversion principle ===
[[Dependency inversion principle]] ('''DIP''') states to depend upon abstractions, [not] concretes.<ref name="dip">{{cite web|title=Dependency Inversion Principle|url=http://www.objectmentor.com/resources/articles/dip.pdf|url-status=usurped|archive-url=https://web.archive.org/web/20150905081103/http://www.objectmentor.com/resources/articles/dip.pdf|archive-date=5 September 2015|work=objectmentor.com}}</ref><ref name="martin-design-principles" />
==== Importance ====
* Loose coupling: Reduces dependencies between modules, making the code more flexible and easier to test.
* Flexibility: Enables changes to implementations without affecting clients.
* Maintainability: Makes code easier to understand and modify.<ref name="dip" /><ref name="martin-design-principles" />
== Origin ==
Software engineer and instructor, [[Robert C. Martin]],<ref name="ub-old-web-solid">{{cite web |author=Martin |first=Robert C. |author-link=Robert C. Martin |title=Principles Of OOD |url=http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod |url-status=live |archive-url=https://web.archive.org/web/20140910201842/http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod |archive-date=Sep 10, 2014 |access-date=2014-07-17 |website=ButUncleBob.com}}. (Note the reference to "the first five principles", although the acronym is not used in this article.) Dates back to at least 2003.</ref><ref name="ub-solid">{{cite web |author=Martin |first=Robert C. |date=13 Feb 2009 |title=Getting a SOLID start |url=https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start |url-status=live |archive-url=https://web.archive.org/web/20130917122741/https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start |archive-date=Sep 17, 2013 |access-date=2013-08-19 |website=Uncle Bob Consulting LLC (Google Sites)}}</ref><ref name="metz-presentation-2009">{{cite web |author=Metz |first=Sandi |author-link=Sandi Metz |date=May 2009 |title=SOLID Object-Oriented Design |url=https://www.youtube.com/watch?v=v-2yFMzxqwU |url-status=live |archive-url=https://ghostarchive.org/varchive/youtube/20211221/v-2yFMzxqwU |archive-date=2021-12-21 |access-date=2019-08-13 |website=[[YouTube]]}}{{cbignore}} Talk given at the 2009 Gotham [[Ruby (programming language)|Ruby]] Conference.</ref> introduced the collection of principles in his 2000 paper ''Design Principles and Design Patterns'' about [[software rot]].<ref name="ub-solid" /><ref name="martin-design-principles">{{Cite web |author=Martin, Robert C. |year=2000 |title=Design Principles and Design Patterns |url=http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf |url-status=usurped |archive-url=https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf |archive-date=2015-09-06 |website=objectmentor.com}}</ref>{{Rp|pages=2–3}} The ''SOLID'' acronym was coined around 2004 by Michael Feathers.<ref>{{cite book |last=Martin |first=Robert |url=https://books.google.com/books?id=uGE1DwAAQBAJ&q=2004+or+thereabouts+by+Michael+Feathers |title=Clean Architecture: A Craftsman's Guide to Software Structure and Design |publisher=Pearson |year=2018 |isbn=978-0-13-449416-6 |page=58}}</ref>
== See also ==
* [[Code reuse]]
* [[GRASP (object-oriented design)]]
* [[Inheritance (object-oriented programming)]]
* [[List of software development philosophies]]
== References ==
{{Reflist}}
[[Category:Software design]]
[[Category:Object-oriented programming]]
[[Category:Programming principles]]
[[Category:Computing acronyms]]
[[Category:Mnemonic acronyms]]
[[de:Prinzipien objektorientierten Designs#SOLID-Prinzipien]]