What is the role of architecture standards in object orientation?

Question

This question seems to have an obvious answer, but I confess that I still don’t get the idea myself. I am working with object orientation since 2011, mainly focused on web development. As soon as I started I heard about MVC. When I took a MVC book to read it quoted many other architecture patterns, among them the MVVM and the MVP.

But what is the real role of these architectural patterns? Whenever we do an object-oriented project, do we choose a pattern to base it on? Of course it is possible to create a new project and go programming without any pattern, but in practice always choose a pattern to base the project?

Moreover, it seems to me that the decision of the standards is ultimately based not on the domain model but on the user interface. I say this because I saw the following: the motivation for MVC on the web is that HTTP does not maintain status, the fact that the user interface is on the web. The MVVM appears in scenarios where there is state, ie the fact that the user interface allows it, and so on. How is made this choice of default?

Answer 1

The most important thing when it comes to software architecture is to understand the mechanisms used in each of the layers, their benefits and impacts.

The standardized models serve as a reference to facilitate learning, communication between architects and developers and also as a reference of good practices.

For example, instead of someone saying, "Look, my system is made so that the types, the screens and the logic are in separate layers," suffice it to say that the system is based on the MVC model, although in many cases this is still somewhat vague.

When the developer is aware of the most common models and the weaknesses and strengths of each he will be able to compare with the requirements of a system and select the best option to serve them.

When starting the implementation, the developer can also filter the most suitable frameworks and tools according to the model that each supports. This greatly facilitates technological choice.

Having a starting point for architecture in the form of reference models is much better than trying to do everything "from scratch". In fact, this is one of the differences between more experienced professionals and more beginners. The experienced, already knowing the standards and good practices, tend to go more directly into the best solutions already known for each situation, while the less experienced tend to want to reinvent the wheel.

Answer 2

I will add another approach to what has already been said.

What is a design standard and the [not] relationship with OOP.

Architectural patterns or design patterns, the famous Patterns design, in a very objective way, it has a role enabler to perform repetitive tasks that already have known solutions that are considered suitable for certain situations.

Object orientation

You don’t need to have a direct relationship with object orientation. Design patterns are in everything you do in programming in any paradigm.

In some design patterns this is more necessary in object-oriented languages. The patterns serve to solve problems that language itself has created or problems that language cannot handle well. Usually this is done by creating rules, templates, code recipes that used in that way achieve an objective.

Patterns are all over the place

But you have to understand that there are design standards that are not like this. There are standards in libraries. Which is even better because you don’t need to know how to implement this project standard, you just have to know how to use the tools available in the library. Roughly you just have to know how to call and how to use the result of one or more functions or methods.

Unfortunately the term Patterns design became famous only for the first case. And to make matters worse, people think that these famous patterns found in books and websites are the solution to everything. They think everything can be solved with an existing pattern. Programmers and project managers abuse something enshrined because they don’t really understand what they’re doing. Asking about specific cases on the subject can go helping to better understand in specific cases.

There is yet another form of design pattern very common and existing for decades. Are the language constructions.

Language constructions

So for example, variable It’s a design pattern that no one thinks it’s because it’s been there so long. It is rarely taught how it works concretely and people fail to see it as a pattern, mainly because language disguises it well. And it becomes more complicated to sell books, lectures and consultancies of something so important, but also so ready to be used.

Function sane Patterns design, as well as methods that is already a standard upon another standard that is implemented upon several other standards. Operators are also.

Statements as if, for, while, for each, etc. are other examples.

Values, references, expressions, and of course, classes are all project standards. No one thinks much about using them as a project standard.

It has languages that teach how to implement the standard Observer, has languages that have this standard implemented as events.

When the pattern is so ingrained in your mind you think you’re not using a design pattern. I know programmer who no longer thinks about using the MVC. This is so normal for him that it doesn’t seem to be a pattern (others because they don’t understand what he’s doing, just "taught me that way"). But we can say that we always choose a pattern in everything.

Most patterns are very good when used at the right time, whether they are part of the language, library or cake recipe.

How to choose a pattern

Some patterns are determined or influenced by the technologies you have chosen. Although you do not always need to follow them. It is common to follow what has been determined for a technology. Very good professionals with deep knowledge in that technology chose what would be most suitable in each case. But they can make mistakes. They may propose something great for most cases but not ideal for you in a given situation.

You can create a new pattern

It is possible but it is unlikely to be better than the existing ones. Of course this depends on what you are doing. On specific domains you may create a pattern that at least has not been published as a known and proven case.

Egg or chicken?

There are cases where you can determine the best standard for a task and go hunting for the technology that best meets your need. It should, but it’s not so common.

Experience, always she

You should take advantage of what other experienced people have done before or your previous experience. You should learn from these experiences. Only should not go blind and consider that every project pattern that appears is good for everything.

His examples

MVC

I, for one, have never actively worked with web, I basically do desktop applications. Whenever I can, at least more recently (in the past I used patterns that were good for the need of the time and that didn’t even have a name, but today are considered archaic) I try to use MVC (or something similar) and my applications are stateful. So there is no direct relationship that has been cited as a possibility for its use. The reason for using MVC is highlighted below.

Today almost everyone agrees that they need to wear one user interaction standard that the data model needs to be separate from the behavior that manipulates user interaction. There are some standards that do this. I use MVC because it adapts well to what I need and is already well used with the technologies I have adopted.

MVC is closely associated with UI. Although nothing prevents it from doing otherwise, virtually any UI API is exposed using OOP techniques. Probably UI is the most suitable application for OOP. Therefore the standard MVC and OOP end up having a close relationship in common cases.

Some patterns fit better in some paradigms, being almost unviable using another paradigm. On the other hand some patterns are so suited to a paradigm that you often think you are not using any pattern. The paradigm imposes certain patterns intrinsically, as opposed to recommending a cake recipe.

MVVM

If I’m going to use WPF, for example, I’ll see better how MVVM works. But it’s not because Microsoft says it’s good that I’m going to use it. It goes very well to use WPF without MVVM. I know that the project gets simpler if you don’t use it, and this is a great advantage. But I still don’t know everything I lose from this. Surely there is some loss, I know at least one. I will have to make a choice. I will rely on my experience. There is no other way. That’s why you see on the internet a lot of people loving and hating this technology (just to stay in this example). Each has a different experience.

Completion

Learn the patterns, but mainly learn their advantages and disadvantages in detail. Learn when to use them and when to avoid them.

I put in the Github for future reference.

Answer 3

Definition

Starting from the beginning of what they are "Design Standards" (Design Patterns)

Design standards are generic solutions to common problems. In fact when you try to define how a problem will be solved, before you have it you are anticipating.

"Design Patterns do not require any unusual language features, nor surprising programming tricks to impress your friends and managers." (Gof, 1995, preface vii)

That is, when using a pattern MVW (Model-View-Whatever - Sendo Whatever what works best for you) you are solving a common problem that was the mixing of the business rule with the screen rule and the maintenance gets terrible.

Going to the client/server applications this is very common to see yet, and remains a code maintenance problem.

There is no magic recipe, but there are several patterns that can be used (Singleton, Builder, Façade, Adapter) and that help solve problems in building Object-Oriented applications.

Therefore

The role of design standards is to unify experiences in common problem solutions so that others can benefit from a good solution found. Simplifying development and maintenance, and facilitating communication as fellow @utLuiz said, where developers can say:

I solved the problem using an Adapter to produce the same report with that other database

Then the other developers will know which solution was addressed.