When to use OOP, and when - OP?
Roughly speaking, the OP and OOP have similar capabilities in expressing complex structures and encapsulating programs into small pieces that can be combined with each other.
The biggest difference between these two “philosophies” is how the data correlates with the operations on the data.
The basic doctrine of OOP is that data and operations on them are strongly connected: the object contains data and the implementation of operations on data. It hides all this from other objects through the interface — a set of methods or messages to which it responds. Thus, the central model of abstraction is the data itself, hidden behind a small API in the form of an interface.
')
With the OOP approach, the programmer creates new objects and extends the existing ones by adding methods to them.
The basic doctrine of FP is that the data are weakly related to functions. Different actions can be performed on the same data set, and the central model of abstraction is a function, not a data structure. Functions hide their implementation, and language abstractions communicate with functions.
With the OP approach, the programmer writes new functions.
In a duel between a bear and a crocodile, the terrain is the decisive factor.
So when is one preferred over the other? Since the blog is dedicated to practical implementations, I dismiss theoretical constructions such as the possibility of mechanically talking about code and thinking about all sorts of pragmatic things, writing business code in a situation where you need to do too much with a lack of resources and time.
Can one of the two models win in a business environment? Think carefully while I make myself an espresso cup ...
Of course, the functional model dominates in business programming. Surprise? Surprise if you only consider languages ​​such as Java, C ++, C # and Ruby.
If you think about it, then all this OOP is a thin layer for accessing databases and SQL, which is actually a functional language. Although it is possible to manage the database through the PL / SQL built-in procedures, this creates a bottleneck, and is usually not worth it.
The main advantage of relational databases is the ability to work with the requirements that will arise in the future. When you need new reports, you just write them. Different applications can access the database in the same way. Restrictions can be imposed programmatically so that they work in all applications.
Moving back, you will see that the database is a large data structure, and applications are sets of operations with them. At the heart of any business application is a large functional database.
And yet, we grab hold of objects in applications. Simple fashion following? Or is there some fundamental difference between what we need to do in applications and what we need to do when working with a database?
The answer is what is simple to do through OOP, and what is simple to do in databases.
A good OOP architecture makes it easy to change how things are related to each other. Encapsulation makes it easy to change the interaction of parts. True, it is not very easy to add new actions to OOP.
But if you have a business process of placing an order, which will be refactored to support new business rules - here the PLO rises in all its glory. Those parts of the code that do not need to know about the changes taking place are isolated from those who need to know about them.
On the other hand, a well-designed database makes it easy to add new queries and operations. It is possible to look at the data from a different point of view or add new data updates. Client applications are isolated from things like indexing and speed.
It's hard to change connections. If you change the management structure, and move from one manager to a report to the many-to-many system, this will break many applications.
Therefore, if we write down everything that should be in a business application, on cards, those that represent long-term and rarely changing relationships go to the database, and those that represent evolving and changing operations go to the application.
A set of "cards" (application elements) is usually four times higher than the set of database elements. Everything changes, business must learn, grow and develop.
So what about the OP code written in a functional style? What about the simple organization of OOP programs in the form of a set of operations acting on relatively constant data sets?
Both are admissible, but you should always think about priorities - over the duration of the connections. If something is unlikely to change, at the same time various changing things will work on it - it is better to design it in the OP style. If something changes often, it is better to issue in the form of the PLO.
If each manager can have several reports, and each report has only one manager, such operations can hardly be hidden behind the API, where manager objects implicitly delegate operations. Such a thing is easier to create in the form of data on which operations are performed. But the rule about the cost of delivery is likely to change, and it should be encapsulated stronger to isolate the rest of the program from it.
Good programs are written using both styles, because good programs must perform several different tasks.
The biggest difference between these two “philosophies” is how the data correlates with the operations on the data.
The basic doctrine of OOP is that data and operations on them are strongly connected: the object contains data and the implementation of operations on data. It hides all this from other objects through the interface — a set of methods or messages to which it responds. Thus, the central model of abstraction is the data itself, hidden behind a small API in the form of an interface.
')
With the OOP approach, the programmer creates new objects and extends the existing ones by adding methods to them.
The basic doctrine of FP is that the data are weakly related to functions. Different actions can be performed on the same data set, and the central model of abstraction is a function, not a data structure. Functions hide their implementation, and language abstractions communicate with functions.
With the OP approach, the programmer writes new functions.
In a duel between a bear and a crocodile, the terrain is the decisive factor.
So when is one preferred over the other? Since the blog is dedicated to practical implementations, I dismiss theoretical constructions such as the possibility of mechanically talking about code and thinking about all sorts of pragmatic things, writing business code in a situation where you need to do too much with a lack of resources and time.
Can one of the two models win in a business environment? Think carefully while I make myself an espresso cup ...
Of course, the functional model dominates in business programming. Surprise? Surprise if you only consider languages ​​such as Java, C ++, C # and Ruby.
If you think about it, then all this OOP is a thin layer for accessing databases and SQL, which is actually a functional language. Although it is possible to manage the database through the PL / SQL built-in procedures, this creates a bottleneck, and is usually not worth it.
The main advantage of relational databases is the ability to work with the requirements that will arise in the future. When you need new reports, you just write them. Different applications can access the database in the same way. Restrictions can be imposed programmatically so that they work in all applications.
Moving back, you will see that the database is a large data structure, and applications are sets of operations with them. At the heart of any business application is a large functional database.
And yet, we grab hold of objects in applications. Simple fashion following? Or is there some fundamental difference between what we need to do in applications and what we need to do when working with a database?
The answer is what is simple to do through OOP, and what is simple to do in databases.
A good OOP architecture makes it easy to change how things are related to each other. Encapsulation makes it easy to change the interaction of parts. True, it is not very easy to add new actions to OOP.
But if you have a business process of placing an order, which will be refactored to support new business rules - here the PLO rises in all its glory. Those parts of the code that do not need to know about the changes taking place are isolated from those who need to know about them.
On the other hand, a well-designed database makes it easy to add new queries and operations. It is possible to look at the data from a different point of view or add new data updates. Client applications are isolated from things like indexing and speed.
It's hard to change connections. If you change the management structure, and move from one manager to a report to the many-to-many system, this will break many applications.
Therefore, if we write down everything that should be in a business application, on cards, those that represent long-term and rarely changing relationships go to the database, and those that represent evolving and changing operations go to the application.
A set of "cards" (application elements) is usually four times higher than the set of database elements. Everything changes, business must learn, grow and develop.
So what about the OP code written in a functional style? What about the simple organization of OOP programs in the form of a set of operations acting on relatively constant data sets?
Both are admissible, but you should always think about priorities - over the duration of the connections. If something is unlikely to change, at the same time various changing things will work on it - it is better to design it in the OP style. If something changes often, it is better to issue in the form of the PLO.
If each manager can have several reports, and each report has only one manager, such operations can hardly be hidden behind the API, where manager objects implicitly delegate operations. Such a thing is easier to create in the form of data on which operations are performed. But the rule about the cost of delivery is likely to change, and it should be encapsulated stronger to isolate the rest of the program from it.
Good programs are written using both styles, because good programs must perform several different tasks.
Source: https://habr.com/ru/post/247285/
All Articles