When we speak of the Domain-Oriented Programming and Problem as you see fit, usually passes through a superficial understanding of the subject.
So I decided to write in a more practical about it and implement some solutions based on Domain-Oriented Programming.
To start, let’s define what we will have a new layer in our application. And this layer is called the Domain.
Let the diagram would look like layers of our programming.
UML Diagram
Often programmed in real time, without planning. We leave the logic flow, sometimes we’re lucky and end up doing the right thing, sometimes not.
Do not mean to say that the Inversion Control, is right or wrong way. And yes demonstrate different ways to do an implementation.
So basic, inversion of control, when the control is, for instance, method calls takes place in reverse. I left the software flow control to make such an instance, and leaves it up to a third party. Then comes the confusion. Why behave like dependency injection, many say the same thing, others say no.
The simplest form of understanding Inversion of control is to think as follows.
I once heard two questions in sequence … “For this amount of functions? Why not do everything right in the page code or want to organize not only does one function? ”
So! Complicated to explain, since you have no idea about means Object Orientation Programming. It was the most delicate I could formulate my response.
In response, The Division of Responsibility.
When we create a class, we must bear in mind that the class is responsible to do something within the context of its existence.
We can not have a class FuelInjection() and we use it to turning lamps, for example:
One of the fundamentals of Object Orientation is no exposure of the implementation details of an object. I’ve talked a few times this in another articles.
So we use the encapsulation of the implementation, so do not put our objects and we have a better maintainability of our classes and since this encapsulation ensures the integrity of our objects can also ensure that the user will only be able to access our objects defined through a contract with a public interface.
But often we begin to implement these rules defining our attributes as private and only allowing access to these through getters and setters:
When we read the name of the pattern Decorator would imagine that silly name, meaningless. Good is not as meaningless as well.
The Decorator works exactly as the name describes.
Decorator is a design pattern software that allows you to add a behavior to an existing object at runtime, or dynamically adds additional responsibilities to an object.
This pattern adds responsibilities dynamically to a class, generating more flexible alternative for certain classes use subclasses through inheritance or composition.
Using Decorator, we have more momentum in the inheritance, we can use inheritance without the problem of transforming our class’s into God class’s.
To help us understand the pattern, let’s create a scenario and a code example.
When we develop a software, we know that this software is to fulfill a need for someone. This need for those who requested the software can be characterized as a problem. Thus we conclude that a software used to solve a problem. All around the needs of the problem may be called the Domain.
Thus, the name Domain-Drive Design could be translated to: Lead the Design Application by Domain or maybe: Oriented Domain Programming (Problems).
This concept involves much more information that’s code is a pattern more conceptual than practical.
What we see in our work-days, is software development guided to anything, less then domain.
Is it common for you to develop an entire software and at the time the client approved, he asks a lot of changes?
When the changes are things that do not exist… It’s ok, but when the changes are like: “This field had to be plain text but comboBox.” You realize that the process failed. Or when the client says: “This financial processing module is wrong, the values do not match.” Well, now you have a problem again.
This type of situation can be avoided if we orient the development of our software for Domain.