This content originally appeared on DEV Community and was authored by Vıɔk A Hıƃnıʇɐ C.
How many times have you come across terms like: inversion of control (IoC), dependency inversion (DI - DIv), dependency injection (DI - DIj) and abstraction, a lot of times, right?
And I am sure that many times you have been practicing them without understanding in depth what is all that, so today is our day and I promise you that we are going to learn these terms in an easy way in a non-technical language for you to appropriate these concepts.
Well but to address these issues we must start at the origin of everything, the software architecture.
At the beginning when software development started everything was darkness, as something new it is normal that as the techniques and complexity of programming and algorithms advanced, problems of construction, scalability, maintenance began to be found, and back in the 60s concepts such as modularity, inheritance, encapsulation began to be touched, but it was finally in the 90s where the term architecture was used in contrast to the word design, evoking notions of abstraction and standards, then the light at the end of the tunnel began to be created.
What is software architecture?
We can define it in one word, decisions, and if they are the design decisions that are made to meet the quality attributes when we have a problem to be solved through software solutions, and these decisions, good or bad model the macro-level structure of the parts of that system and that modeling is done through software architecture patterns.
What is the patterns?
There are two types of patterns in the software world, software architecture patterns and software design patterns.
What are software architecture patterns?
They are archetypes (structures) that tell us how the parts of a software system relate/interact at the macro level, and some of there are:
Client - server, Microkernel, Dashboard, Peer to peer (P2P), Events broker pattern (Agent), Events bus pattern, Model view controller (MVC), N-Tire, Multilayer, Microservice, and others.
I leave you the task to read about them.
What are software design patterns?
They are base templates or archetypes that have already been tested to solve common problems encountered in the software development process. They are classified into three groups (creative, structural, behavioral) and there are many, but here are just a few.
The creative group models the creation of concrete and abstract objects.
In the structural group, objects are modeled to form larger structures and complement their functionality.
And the behavioral group models how to interact and responsibilities in groups of objects.
Factory, Abstract factory, Strategy, Façade, Composite, Builder, Singleton, Data transfer object (DTO) and many others.
I leave you the task to read about them.
To learn about patterns, you ca go to:
Patterns
Now, what is abstraction?
In simple words abstraction can be defined as the separation of what and how, that is, separating what something does from how it does it.
So, the what is the action (Interface, Abstract class), this action receives or not input parameters and gives us a result.
The how is what is done (behavior) with those parameters and its internal objects to return the result, that is the concrete Class or implementation.
// Artifact in Application Layer
// This is the what, the compromise or contract
export interface ILogProvider {
logEvent(event: EventLog): Promise<void>;
logError(error: ErrorLog): Promise<void>;
}
// Artifact in Adapters Layer
// And this is the how, the concrete Class or implementation
export class LogProvider implements ILogProvider {
constructor(private readonly logger: Logger) {}
async logEvent(event: EventLog): Promise<void> {
return this.logger.info(event);
}
async logError(error: ErrorLog): Promise<void> {
return this.logger.error(error);
}
}
So, having understood what abstraction is, we can then review the following concepts.
What is the inversion of control (IoC)?
Basically it is to delegate, to delegate control of certain aspects of an application to a third party.
This third party is usually a framework or service, and can control from the lifecycle of objects (DIj) to that of the application itself, it can also control events and invoke application actions to those events (UI), it can also control data persistence and service providers.
What is dependency inversion (DIv)?
DIv basically is abstraction and since we already know that it is abstraction, then it is time to talk about its main function, and this function is to decouple the layers of your software solution.
This is one of the SOLID (DIvP) principles and landing its compendiums to a non-technical language we can say that:
- Important classes should not depend on less important classes, both should depend on abstractions.
- The what should not depend on the how, the how should depend on the what.
What is dependency injection (DIj)?
It is about separating the construction/creation (instances) from the execution context where the object interacts.
It is to delegate the creation of objects to a third party, in this case to a dependency injection container (DIjC) with the intention of decoupling the core of our application from the outside world, that of "trivial" things.
Question?
Is posible to use Dependency Injection without using Dependency Inversion?
The short answer is a partial Yes, but it is not recommended because in strongly typed languages it will generate a coupling between objects of different layers and performing end to end tests in certain cases will be very complex, however, in languages like JavaScript this is very common and it is considered good practice because this language has no interfaces or abstract classes (Specifications before ES6), and not having defined types, it is better to use an injected module through a method to import it directly into the dependent module, therefore the mock of that injected artifact will be easily emulated.
What is Clean Architecture?
It can be defined as a framework or set of best practices aimed at facilitating the construction, testability and maintenance of a software product.
The term was coined by Robert C. Martin and in this compendium he took part of other architectural concepts "Tiers and Layers, Onion, Hexagonal (Ports and Adapters)" that have as main objective the abstraction, structuring the code through layers and isolating the inner world (application and business logic) from "trivial" things like the outside world.
The entities are the domain or business logic, the use cases are the application logic that orchestrates the domain artifacts, the adapters are the entry and exit points of your application, and the external world are the connections, services and frameworks that enable the entry and exit points to enter and send the data being processed.
In a software solution these layers look more or less like the directories in the previous image.
Well, this is all I have to share in this article and I hope I have contributed to your knowledge by explaining these concepts in simpler terms because handling them in such technical terms can be a bit complicated to understand these concepts.
If you find any inaccuracies I appreciate the feedback. :)
This content originally appeared on DEV Community and was authored by Vıɔk A Hıƃnıʇɐ C.
Vıɔk A Hıƃnıʇɐ C. | Sciencx (2022-04-23T23:21:12+00:00) Software architecture and Abstraction for newbie. Retrieved from https://www.scien.cx/2022/04/23/software-architecture-and-abstraction-for-newbie/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.