The software is hard to change because every applied change will affect many parts of the software.

-When applying changes, unexpected parts of the software breaks.

The modules of the software are hard to reuse ins another software because these cannot be extracted from the current software.

-object-oriented design are applied to software development projects to make software easier to change when requirements changes.

- This is one of the basic principles most developers apply to build robust and maintainable software.

- This states that for a software to be easy to change, the software classes must be designed to allow the behavior of those classes to be changed by adding new code rather than changing existing code.

- Barbara Liskov introduced this principle which states that the derived classes should be substitutable for their base classes to build a software from interchangeable modules or classes.

- This principle advises software designers to avoid depending on things that they don't use.

– This principle suggests that flexible software are those with classes that depend on abstract classes or interfaces.

instructs developers to design each module, interface, or class of a software system to have only one (1) responsibility. The software systems are changed to satisfy the needs of the users or actors. Those users are the "reason to change" that the principle is referring to.

states that software modules, interfaces, or classes should be open for extension but closed for modification.

suggests that when creating a new derived class of an existing class, make sure that the derived class can be a substitute for its base class.

suggests avoiding depending on things that are not used. This means that clients should not be forced to implement interfaces they don't use. Instead, on one (1) big interface, several small interfaces are preferred based on groups of methods where each interface serves one (1) submodule.

suggests that the most flexible software systems are those in which source code dependencies refer only to abstractions, not to concretions.

This describes when to use the pattern. It explains the problem and its context.

-This describes the elements that make up the design, their relationships, responsibilities, and collaborations.

- These are the results and interchanges of applying the pattern to the problem.

-This is the name of a pattern that can be used to describe a design problem, its solution, and consequences.

This allows developers to define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

This design pattern allows developers to traverse elements of a collection without exposing its underlying representation, such as list, stack, and tree.

This design pattern allows developers to define a subscription mechanism to notify multiple objects about any events that happen to the object they are observing.

This design pattern allows developers to provide a substitute or placeholder for another object.

-This provides an interface for creating objects in a superclass but allows subclasses to alter the type of object that will be created

This creational design pattern lets a developer copy existing objects without making his code dependent on their classes.

This allows developers to produce families of related objects without specifying their concrete classes.

This creational design pattern allows developers to construct complex objects step by step. The pattern allows developers to produce different types and representations of an object using the same construction code.

- This provides a simplified interface to a library, a framework, or any other complex set of classes.

This allows developers to fit more objects into the available amount of RAM by sharing common parts of state between multiple objects instead of keeping all of the data in each other.

- This design pattern allows developers to compose objects into tree structures and then work with these structures treating them as individual objects.

- This allows developers to attach new behaviors to objects by placing these objects inside specia wrapper objects that contain the behaviors.

-This design pattern lets developers ensure that a class has only one (1) instance while providing a global access point to the instance.

-This structural design pattern allows objects with incompatible interfaces to collaborate. This pattern converts the interface of a class into another interface as expected by the client application.

- This allows the developers to split a large class or a set of closely related classes into two (2) separate hierarchies, which are abstraction and implementation, that can be developed independently of each other.

- These patterns deal with when and how objects are created.

- These describe how objects are composed into larger groups and explain how to assemble objects and classes into larger structures while keeping their structures flexible and efficient.

- These describe how responsibilities are distributed between objects in the design and how communication happens between objects.