The object-oriented programming (OOP) method is an improvement based on the process-oriented programming method, and the aspect-oriented programming (AOP) method is an innovative software development method based on the object-oriented programming (OOP) method.
1. Difference:
field-oriented differences
AOP and OOP are two kinds of design ideas for different fields.
OOP (Object-oriented programming) abstracts and encapsulates the entities and their attributes and operations that exist in the problem domain and in the business process, and the core concept of object-oriented is the vertical structure, which aims to obtain clearer and more efficient logical unit division;
AOP is to extract the facets of the business process, for example, the various non-functional requirements (Operation log, permission control, performance monitoring, etc.) that are often faced in enterprise development, and use object-oriented thinking to separate the core function of the business Operation object from its other service function code. That is, an operation is involved in each module, this operation can be seen as "crosscutting" exists in the system. In many cases, these operations are not relevant to the business logic or are not part of the logical operation, and the object-oriented approach is difficult to handle.
AOP separates these operations from business logic, allowing programmers to focus on the processing of business logic while writing programs, and using AOP to automatically decouple cross-cutting concerns across modules. AOP is faced with a process of processing a step or stage, to separate the different stages of the domain, has been the logical process of the low-coupling between the isolation effect, and aspect-oriented programming in the target has an essential difference. The core idea of AOP is to separate the business logic processing parts of the application from the generic services that support them, the so-called "crosscutting concerns" that run through the requirements of multiple vertical modules in the program.
2. Relationship:
AOP is the continuation and complement of OOP.
AOP and OOP are not two competing technologies, and people are not proposing AOP for the sake of OOP, in fact, AOP and OOP are a good complement and perfect for each other.
OOP object-oriented programming focuses on dividing the requirements function "vertically" into different and relatively independent, well-encapsulated classes, and letting them have their own behavior. The relationship between objects is defined by inheritance and polymorphism, that is, OOP introduces concepts such as encapsulation, inheritance, and polymorphism to create an object hierarchy that simulates a collection of public behavior. When we need to introduce public behavior to scattered objects, oop seems powerless. In other words, OOP allows you to define relationships from top to bottom, but it is not appropriate to define left-to-right relationships. such as logging capabilities. Log code is often spread horizontally across all object hierarchies, and has nothing to do with the core functionality of the objects it spreads to. This is true for other types of code, such as security, exception handling, and transparent persistence. This irrelevant code scattered around is called crosscutting (cross-cutting) code, and in OOP design, it leads to a lot of duplication of code, rather than the reuse of individual modules.
AOP, on the contrary, uses a technique called "crosscutting" to further "horizontal" cutting of the massive class architecture built by OOP and encapsulates public behavior that affects multiple classes into a reusable module encapsulated as "Aspect", or aspect. The so-called "aspect", in a nutshell, is to encapsulate the logic or responsibility that is not related to the business, but for the common invocation of the business module, to reduce the duplication of code in the system, to reduce the coupling between modules, and to facilitate future operability and maintainability. AOP represents a horizontal relationship, if the "object" is a hollow cylinder, which encapsulates the properties and behavior of the object, then the aspect-oriented programming approach is like a razor that cuts through the hollow cylinders to get inside the message. The cut-off aspect is the so-called "facet". Then it hands the cut-off slices with a clever capture of the heavens, leaving no traces.
Aspect-oriented programming is intended to allow for further "horizontal" cutting of the vast class architecture built by OOP, separating the common requirements functionality from the unrelated classes and encapsulating them into aspects.