app dev mid

Rigidity

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

Fragility

When applying changes, unexpected parts of the software breaks.

Immobility

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

Design Principles

A set of guidelines to be followed that helps developers arrange methods and data structures into classes, and how those classes should be interconnected, which can adapt to the changes in requirements without major code rewrites.

Single Responsibility Principle (SRP)

This suggests that each software module, class, or interface should have only one (1) reason to change.

Open-Closed Principle (OCP)

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.

Liskov Substitution Principle (LSP)

This states that the derived classes should be substitutable for their base classes to build a software from interchangeable modules or classes.

Interface Segregation Principle (ISP)

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

Dependency Inversion Principle (DIP)

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

Design Patterns

Reusable solutions to commonly occurring problems in software design.

Pattern Name

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

Problem

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

Solution

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

Consequences

These are the results and interchanges of applying the pattern to the problem, including time and space tradeoffs, flexibility, extensibility, and portability.

Creational Patterns

These patterns deal with when and how objects are created, providing object creation mechanisms that increase flexibility and reuse of existing codes.

Structural Patterns

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.

Behavioral Patterns

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

Singleton Pattern

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

Factory Method Pattern

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

Prototype Pattern

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

Abstract Factory Pattern

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

Builder Pattern

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

Director

A separate class that defines the order of executing the building steps in the Builder pattern, completely hiding the details of product construction from the client code.

Adapter Pattern

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

Bridge Pattern

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

Composite Pattern

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

Decorator Pattern

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

Facade Pattern

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

Flyweight Pattern

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

Proxy Pattern

This design pattern allows developers to provide a substitute or placeholder for another object to control access to the original object.

Iterator Pattern

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

Observer Pattern

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.

Strategy Pattern

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