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

The theory of SOLID principles was introduced by Robert C. Martin (Uncle Bob) in his 2000 paper Design Principles and Design Patterns. The SOLID acronym was introduced later by Michael Feathers.

• Single-responsibility principle 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 "Software entities ... should be open for extension, but closed for modification."
• Liskov substitution principle "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 "Many client-specific interfaces are better than one general-purpose interface."
• Dependency inversion principle One should "depend upon abstractions, [not] concretions.

Barbara Liskov (Picture) is an American computer scientist who has made pioneering contributions to programming languages and distributed computing.

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch.

It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. The authors are often referred to as the Gang of Four «GoF».

Creational patterns are ones that create objects, rather than having to instantiate objects directly. This gives the program more flexibility in deciding which objects need to be created for a given case.

• 1. Abstract factory O groups object factories that have a common theme.
• 2. Builder O constructs complex objects by separating construction and representation.
• 3. Factory method C creates objects without specifying the exact class to create.
• 4. Prototype O creates objects by cloning an existing object.
• 5. Singleton O restricts object creation for a class to only one instance.

These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.

• 6. Adapter C,O allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
• 7. Bridge O decouples an abstraction from its implementation so that the two can vary independently.
• 8. Composite O composes zero-or-more similar objects so that they can be manipulated as one object.
• 9. Decorator O dynamically adds/overrides behaviour in an existing method of an object.
• 10. Facade O provides a simplified interface to a large body of code.
• 11. Flyweight O reduces the cost of creating and manipulating a large number of similar objects.
• 12. Proxy O provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Most of these design patterns are specifically concerned with communication between objects.

• 13. Chain of responsibility O delegates commands to a chain of processing objects.
• 14. Command O creates objects which encapsulate actions and parameters.
• 15. Interpreter C implements a specialized language.
• 16. Iterator O accesses the elements of an object sequentially without exposing its underlying representation.
• 17. Mediator O allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
• 18. Memento O provides the ability to restore an object to its previous state (undo).
• 19. Observer O is a publish/subscribe pattern which allows a number of observer objects to see an event.
• 20. State O allows an object to alter its behavior when its internal state changes.
• 21. Strategy O allows one of a family of algorithms to be selected on-the-fly at runtime.
• 22. Template method C defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
• 23. Visitor O separates an algorithm from an object structure by moving the hierarchy of methods into one object.

• Learn every day for 100 day.
• Code at least one hour per day.
• Teach someting online.
• Blog about code every day.
• Youtube something usefull for other to learn while doing their #100dayof code challenge.
• Reach to other doing the chalenge.
• Report my daily experience in a log on my github repository.
• Support other doing the chalenge

Scientia est lux principium✨™