Scribd
Upload
37 views9 pages

Patterns - Principles

The document discusses several software design principles and patterns including: - SOLID principles like the single responsibility principle and open-closed principle. - Common design patterns like factory method, singleton, observer, and facade. - Uses of patterns like factory method for report generation and singleton for logging. - Other patterns, principles, and architectural approaches like repository pattern, anticorruption layer, and strangler pattern.

Uploaded by

Juan Medina
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
37 views9 pages

Patterns - Principles

The document discusses several software design principles and patterns including: - SOLID principles like the single responsibility principle and open-closed principle. - Common design patterns like factory method, singleton, observer, and facade. - Uses of patterns like factory method for report generation and singleton for logging. - Other patterns, principles, and architectural approaches like repository pattern, anticorruption layer, and strangler pattern.

Uploaded by

Juan Medina
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 9

SOLID PRINCIPLES

They are guidelines that, when followed, can enhance the maintainability of software.

Single Responsibility Principle


A class should have only one reason to change, meaning that a class should have only one
job.

Open-Closed Principle
Objects or entities should be open for extension, but closed for modification.
This simply means that a class should be easily extendible without modifying the class itself.

Liskov Substitution Principle


Every subclass or derived class should be substitutable for their base or parent class.

Interface Segregation Principle


A client should never be forced to implement an interface that it doesn’t use, or clients
shouldn’t be forced to depend on methods they do not use.

Dependency Inversion Principle


Entities must depend on abstractions not on concretions.
The high level module must not depend on the low level module, but they should depend on
abstractions.

Inversion of Control
it is a pattern used for decoupling components and layers in the system. The pattern is
implemented through injecting dependencies into a component when it is constructed. These
dependencies are usually provided as interfaces for further decoupling and to support
testability.
DESIGN PATTERNS
A design patterns are well-proved solution or strategy for solving a specific problem.
By using the design patterns you can make your code more flexible, reusable and
maintainable.

Advantages
They are reusable in multiple projects.
They provide the solutions that help to define the system architecture.
They provide transparency to the design of an application.
They provide clarity to the system architecture and the possibility of building a better system.
CREATIONAL PATTERNS
They are concerned with way of creating objects.

Abstract Factory
Creates an instance of several families of classes.

Builder
Separates object construction from its representation.

Factory Method
Creates an instance of several derived classes.

Prototype
A fully initialized instance to be copied or cloned.

Singleton
A class of which only a single instance can exist.
STRUCTURAL PATTERNS
They are concerned with how classes and objects to be composed, to form larger structures.

Adapter
Match interfaces of different classes.

Bridge
Separates an object’s from its implementation.

Composite
A tree structure of simple and composite objects.

Decorator
Add responsibilities to objects dynamically.

Facade
A single class that represents an entire subsystem.

Flyweight
A fine-grained instance used for efficient sharing.

Proxy
An object representing another object.
BEHAVIORAL PATTERNS
They are concerned with the interaction and responsibility of objects

Chain of Responsibility
A way of passing a request between a chain of objects.

Command
Encapsulate a command request as an object.

Interpreter
A way to include language elements in a program.

Iterator
Sequentially access the elements of a collection.

Mediator
Defines simplified communication between classes.

Memento
Capture and restore an object’s internal state.

Observer
A way of notifying change to a number of classes.

State
Alter an object’s behavior when its state changes.

Strategy
Encapsulates an algorithm inside a class.

Template method
Defer the exact steps of an algorithm to a subclass.

Visitor
Defines a new operation to a class without change.
MOST USED

Factory method
I used this pattern when I required to build a report in different file format with the same
information.

Singleton
I used this pattern when I required to write in a log file.

Observer
I used this pattern when I required to notify to the subscribers about the state of their
vehicles. Those states are: fuel, battery, and abrupt change of speed in short period of time.

Chain of responsibility
I used this pattern when I required to implement a system to approve quotes.
The process was three approvers: salesman, account manager and business director.

Facade
I used this pattern when I required to group different implementations or methods from other
classes or from external services, for building an entire subsystem.
I built a facade with different notification mechanisms from external services. That facade
contained push notifications, sms and email.

Strategy
I used this pattern when I required to calculate the fuel level of different vehicles. Depending
on the type of vehicle the fuel level was calculated differently.
REPOSITORY PATTERN
The Repository pattern adds a separation layer between the data and domain layers of an
application.
It also makes the data access parts of an application better testable.

Repository Pattern separates the data access logic and maps it to the entities in the
business logic.
It works with the domain entities and performs data access logic.
In the Repository pattern, the domain entities, the data access logic and the business logic
talk to each other using interfaces.
It hides the details of data access from the business logic.
In other words, business logic can access the data object without having knowledge of the
underlying data access architecture.

There are various advantages of the Repository Pattern including:


-Business logic can be tested without need for an external source
-Database access logic can be tested separately
-No duplication of code
-Caching strategy for the datasource can be centralized
-Domain driven development is easier
-Centralizing the data access logic, so code maintainability is easier

The repository pattern is an abstraction. Its purpose is to reduce complexity and make the
rest of the code persistent.
ANTICORRUPTION LAYER
An anticorruption layer is a means of linking two bounded contexts. This pattern implements
a facade or adapter layer between a modern application and a legacy system that it depends
on. This layer translates requests between the modern application and the legacy system.

Issues and considerations


-The anti-corruption layer may add latency to calls made between the two systems.
-The anti-corruption layer adds an additional service that must be managed and maintained.
-Consider how your anti-corruption layer will scale.
-Consider whether you need more than one anti-corruption layer. You may want to
decompose functionality into multiple services using different technologies or languages, or
there may be other reasons to partition the anti-corruption layer.
-Consider how the anti-corruption layer will be managed in relation with your other
applications or services. How will it be integrated into your monitoring, release, and
configuration processes?
-Make sure transaction and data consistency are maintained and can be monitored.
-Consider whether the anti-corruption layer needs to handle all communication between
legacy and modern systems, or just a subset of features.
-Consider whether the anti-corruption layer is meant to be permanent, or eventually retired
once all legacy functionality has been migrated.

When to use this pattern


Use this pattern when:
-A migration is planned to happen over multiple stages, but integration between new and
legacy systems needs to be maintained.
-New and legacy system have different semantics, but still need to communicate.
-This pattern may not be suitable if there are no significant semantic differences between
new and legacy systems.
STRANGLER PATTERN
Incrementally migrate a legacy system by gradually replacing specific pieces of functionality
with new applications and services. As features from the legacy system are replaced, the
new system eventually replaces all of the old system's features, strangling the old system.

Issues and considerations


-Consider how to handle services and data stores that are potentially used by both new and
legacy systems. Make sure both can access these resources side-by-side.
-Structure new applications and services in a way that they can easily be intercepted and
replaced in future strangler migrations.
-At some point, when the migration is complete, the strangler façade will either go away or
evolve into an adaptor for legacy clients.
-Make sure the façade keeps up with the migration.
-Make sure the façade doesn't become a single point of failure or a performance bottleneck.

When to use this pattern


-Use this pattern when gradually migrating a back-end application to a new architecture.
This pattern may not be suitable:
-When requests to the back-end system cannot be intercepted.
-For smaller systems where the complexity of wholesale replacement is low.

You might also like