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 maintainable. Although the SOLID principles apply to any object-oriented design, they can also form a core philosophy for methodologies such as agile development or adaptive software development.

Software engineer and instructor Robert C. Martin{{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.{{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)}}{{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 Conference. introduced the basic principles of SOLID design in his 2000 paper Design Principles and Design Patterns about software rot.{{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}}{{Rp|pages=2–3}} The SOLID acronym was coined around 2004 by Michael Feathers.{{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}}

Principles

= Single responsibility principle =

The single-responsibility principle (SRP) states that "there should never be more than one reason for a class to change."{{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}} In other words, every class should have only one responsibility.{{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}}

== 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.

= Open–closed principle =

The open–closed principle (OCP) states that "software entities ... should be open for extension, but closed for modification."{{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}}

== 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 =

The Liskov substitution principle (LSP) states that "functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."{{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}} {{Crossreference|See also design by contract.}}

== 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.

= Interface segregation principle =

The interface segregation principle (ISP) states that "clients should not be forced to depend upon interfaces that they do not use."{{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}}

== 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 ===

The dependency inversion principle (DIP) states to depend upon abstractions, [not] concretes.{{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}}

== 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.

See also

References