DEV Community: Ahmed Osama Bedawy

Dependency Inversion Principle (DIP)

Ahmed Osama Bedawy — Sun, 21 Jan 2024 16:13:26 +0000

What is the Dependency Inversion Principle?

The Dependency Inversion Principle (DIP) is one of the five SOLID principles that states:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Let’s break this down by examples.

In this example:

High-level Module(or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action.
Abstraction: Represents an interface that connects the two Classes.
Details: How the tool works.

Another example Vehicle and Engine:

Without DIP:

The Vehicle class directly instantiates a specific Engine class (e.g., PetrolEngine).
The Vehicle depends on concrete details of PetrolEngine.

With DIP:

Introduce an abstraction:
- Create an interface Engine with methods like start() and stop().
Refactor Vehicle:
- Vehicle depend on the Engine interface instead of a concrete Engine class.
- Inject a concrete Engine implementation (e.g., PetrolEngine or ElectricEngine) at runtime.

Benefits:

Enhanced flexibility: Change engine types without modifying Vehicle code.
Easier testing: Mock Engine for testing Vehicle in isolation.

This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.

It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specifications of the interface.

100+ Questions for Angular Interviews 💫

Ahmed Osama Bedawy — Tue, 28 Nov 2023 22:32:56 +0000

100+ Questions for Frontend Interviews 💫

Angular Interview Questions:
- GitHub Repo: https://t.ly/gXvx8
- Simplilearn: https://rb.gy/1kci32
- DZone: https://rb.gy/hqqyjt
- Codecademy: https://rb.gy/00o7yj
- Flexiple: https://rb.gy/tqeopw
- Educative: https://rb.gy/jtg2hw
Rxjs Interview Questions:
- javatpoint: https://t.ly/ZDyJa
- Indeed: https://t.ly/ZfwVC
- SkillCombo: https://t.ly/LjE49
- TechGeekNext: https://t.ly/YCr4h
- Fullstack.cafe: https://cutt.ly/dwOgdRhL
TypeScript Interview Questions:
- InterviewBit: https://cutt.ly/BwOggef1
- Edureka: https://cutt.ly/pwOggmdx
- Hackr: https://lnkd.in/dTQ3skJS
- Simplilearn: https://lnkd.in/drW3Tuz8
- Educative: https://lnkd.in/dStJPhPV
Javascript Interview Questions:
- GitHub Repo: https://lnkd.in/dWiBhWxp
- InterviewBit: https://lnkd.in/dJyDWsu9
- Guru99: https://lnkd.in/dEAKXrkP
- Hackr: https://lnkd.in/dsceyNye
- javatpoint: https://lnkd.in/dnbdi23F

Forms in Angular

Ahmed Osama Bedawy — Sat, 05 Feb 2022 14:38:53 +0000

> Angular provides to different approaches to handling user input through forms: reactive forms & template-driven forms.

Reactive forms and template driven forms each of them has different advantages when mange form data.

Reactive forms ⇒ Provide direct, explicit access to underlying forms object model, they’re more scalable, reusable, and testable. If you work in large project and the form are a key part of your application, use reactive forms.
Template-driven forms ⇒ depend on directive in the template to create and manipulate the underlying object model. If you have very basic form requirements and logic, template-driven form could be a good fit.

This table show the key difference between reactive and template-driven forms.

Scalability:

If the forms is essential part of your project, scalability is very important.

Reactive forms ⇒ It’s are more scalable than template-driven forms. They provide direct access to the underlying from API, and use synchronous data flow between the view and data model, which makes creating large-scale forms easier.
Template-driven forms ⇒ It’s are less scalable than reactive forms. They abstract away the underlying from API, and use async data flow between the view and the data model.

Setup and data flow in reactive forms:

In reactive forms, you define the form model directly in the component class. The formControl directive links the explicitly created formControl instance to a specific form element in the view.

> In this figure, you will see the formcontrol directive links directly to form element in the view.

> Data Flow:
In reactive forms the updates from the view to the model and from the model to the view are synchronous and do not depend on how the UI is rendered.

> Data flow form the view to the model

In this figure show how data flow changed from the view to model through the following steps:

A value is typed by the user into the input element. In this example the value is blue.
The form input element emits an “input” event with the latest value.
The control value accessor listening for events on the form input element immediately relays the new value to the formControl instance.
The formControl instance emits the new value through the valueChanges observable.
The new value is received by any subscribers to the valueChanges observable.

> Data flow form the model to the view

In this figure show how data flow changed from the model to view through the following steps:

The user calls the favoriteColorControl.setValue() method, which updates the FormControl value.
The FormControl instance emits the new value through the valueChanges observable.
Any subscribers to the valueChanges observable receive the new value.
The control value accessor on the form input element updates the element with the new value.

Setup and data flow in template-driven forms:

In template-driven forms, the form model is implicit. The directive NgModel creates and manages a FormControl instance for a given form element.

> In a template-driven form the source of truth is the template. You do not have direct programmatic access to the FormControl instance.

Data Flow:

In template-driven forms, each form element is linked to a directive that manages the form model internally.

> Data Flow from View to Model

In this figure show how data flow changed from the view to model through the following steps:

A value(Blue) is typed by the user into the input element.
An “input” event having the new value is emitted by the input element.
The setValue() method on the FormControl instance is triggered by the control value accessor attached to the input.
The FormControl instance emits the new value through the valueChanges observable.
Any subscribers to the valueChanges observable receive the new value.
The NgModel.viewToModelUpdate() method is also called by the control value accessor. It emits an ngModelChange event.
For the defined property, the component template uses two-way data binding. The value emitted by the ngModelChange event is used to update the defined property in the component.

> Data Flow from Model to View

In this figure show how data flow changed from the model to view through the following steps:

The defined property is updated to a new value in the component.
The Change detection then starts.
The ngOnChanges lifecycle hook is called on the NgModel directive instance during the change detection. The reason being that the value of one of its inputs has changed.
An async task is queued by the ngOnChanges() method to set the value for the internal FormControl instance.
The Change detection is now completed.
To set the FormControl instance value, the required task is executed.
The latest value is emitted by the FormControl instance through the valueChanges observable.
Any subscribers to the valueChanges observable receive the new value.
The control value accessor updates the form input element in the view with the latest value.