Thoughts on the nature of business objects (1)

ArticleDirectory

• 2.1.1 inherent information
• 2.1.2 Dynamic Information
• 2.1.3 attribute Encapsulation
• 2.2.1 anemia vs congestion
• 2.2.2 single responsibilities
• 2.2.3 who owns data and who holds Behavior
• 2.2.4 Methods belong to customers
• 2.2.5 behavior Encapsulation

Thoughts on the nature of business objects

[Abstract]: based on the previous research achievements in the fields of OO and DDD, this paper summarizes and refines the nature of business objects based on personal work experience and insights, in addition, the three factors of Bo and the issue of obtaining and verifying Bo are elaborated, aiming to deepen the correct understanding of Bo by OOA/D personnel, analyze and design better software products.

1 Introduction

For computers that adopt the OO idea and have a n-layer architectureProgramBusiness Object is generally located in the business logic layer (also called domain layer [1]), as part of the domain model element, describes a person, thing, thing, or concept from the Business Domain [2], mainly used to solve the business logic (that is, business operations) problem, is to achieve the current software (or system) of a specific (or some) function. Therefore, it is only an abstraction of the real world from the perspective of the current business domain.

Business Objects, business entities, entities, and domain objects are interchangeable terms to some extent [This is simply a "to some extent", with the aim of analyzing the essence of the three elements of Bo, for different theories, there are indeed differences between these terms, but this article will not go into detail].

2 three elements of Object

According to Wikipedia's definition of object [2], an object has the following three elements:

■ Identity is the unique identifier for distinguishing other objects;

■ State describes the information contained in an object;

■ Behavior: the behavior that an object holds and describes how an object is used.

Bo are state and behavior together. The following describes only the status and behavior, and the Bo logo will not be described in detail.

Status 2.1

Compared with fields, variables, attributes, and other words, it is most appropriate to use the word "state" to describe the "character characteristics" of an object. Fields, variables, and attributes are nothing more than different representations of object states. As for my personal understanding of Bo status, Bo status information has two types: inherent information and dynamic information. The inherent information is the inherent information of the object from its birth (just like the birth of a new life, the information such as the date of birth, skin color, and gender is inherent ); dynamic information, that is, as Bo grows, it will enter a person-created scenario and assume a role. In this scenario, it will be given some additional information, such: james is a student (the basic information of the students is granted when he enters school). One day he went to the city library to borrow books. At this time, he played the role of the borrower in the book borrowing scenario, this provides dynamic information such as the Borrowing Certificate and borrowing information.

2.1.1 inherent information

I personally think that after a business object is built (initialized), it should reach a relatively stable state with a certain meaning of business, that is, the properties of the business object should have been initialized and set accordingly. Such a building is reasonable and complete. Similar to the human world, a person has constructed the baby's nose, eyes, hands, and other content at birth, although at this time he has no information such as clothes, mother tongue, ID card, etc, however, when he was born, he was a relatively stable and meaningful individual who could complete the core operations of the baby, such as crying, breathing, and waving. Imagine that after an object is built, it still needs to use frequent setter () Methods to complete core business operations. Is this a good encapsulation? For callers, the core goal is to use the methods published by Bo. It is obviously annoying to use setter and setter, at least setter () this and that are not the caller's intention, not the caller's responsibility.

Constructing the constructed information in advance (Note: not all information must be fully structured) is the first step to ensure that Bo is not abused. In this case, it is easy to ask. If a bo involves a large amount of initial information during construction, will it be completely injected as parameters from the constructor? My answer to these concerns: first, constructing an instance is to initialize the Bo instance, it makes no sense to create an empty or incomplete Bo instance (or even disrupt audio and video). Second, if there are many parameters, the object will be constructed completely, to bring more stability, we can try to classify and encapsulate parameters to reduce the tangle (but I personally think it is unnecessary). Finally, we recommend that you understand spring dependency injection, bean configuration, and so on.

2.1.2 Dynamic Information

In a specific scenario, assuming a role (I prefer to use the "wear a hat" Statement) will have additional dynamic attributes. Similar to the Construction of "inherent attributes", when a business object enters a specific scenario and plays another role, these dynamic attributes should also be set. In a word, the object should try its best to complete its own State settings in the process of building itself.

Student trace = new student ("trace", 1900.10.10, man ....);

Trace. Drink ();

Iborrower borrower = trace. actas <iborrower> ();

Borrower. borrowbooks ();

2.1.3 attribute Encapsulation

In the OO world, the concept of encapsulation is the simplest, but it is the most critical and difficult to grasp. Encapsulation of internal information is the most basic principle that must be followed by qualified OOA/D personnel.

[Question]: If the business object information is exposed without encapsulating properties, the program is implemented normally. It seems that there is no major problem ?!

[Answer]: Congratulations, you have implemented business functions (not to mention programs for the moment) through so many handy information.CodeStructure, whether or not cohesion/low coupling), it seems no problem. But how can we cope with changes in demand or even high-level policies?

The absence of information encapsulation (or incomplete encapsulation) has left too many programmers with painstaking efforts. It is often the result of their own efforts, and always comes with "if you come back again, I certainly won't design it like this. "regret and helplessness. Side effects of unencapsulated information (or incomplete encapsulation:

1. Cohesion, difficult. The information of business objects is exposed too much, which is easy to breed the logic of robbers. It is difficult to squeeze it back to form a group! All information is exposed to the outside world. What else does the caller need Bo? The reason is simple: I can reach out to get your information, implement what I want, and do what I want. If you still have the guts to expose some permissions to change the Bo attribute, I don't want to change it. Can you control it? What else do you want to get together? Dream!

2. Decoupling, difficult. An idiom is called "It's hard to get rid of water". The leaked information will be freely used by callers and will show a rapid spread. A complicated coupling network will inevitably emerge. When we start refactoring and decoupling, we will find that the accumulation of code and coupled network-like structures have left you nowhere to start. A moment, it will cause a total pain. Common practices: (1) partition a small block, change the variable name and method name, move some code, and use the interface to wrap it (isolate it), and modify it cyclically, finally, it was found that the progress was still very slow and almost never reached the core of the business. (2) Try the method first (1). After a while, MD was bored and pushed down and re-initiated. These practices also need to consider the following question: the released interfaces and information have been widely used by callers. What should I do?

 

In view of the above pain points, we recommend the following practices:

1. When constructing an object, assign values to the status information that can be set as much as possible and encapsulate them in advance;

2. Do not publish internal information as much as possible. Private. Unless you have to, do not release setter () as far as possible and only make it read only. [Personal feelings]: I used to write code and never considered private/protect/public. All of them were public. The negative consequences have caused me to eat a few pots.

2.2 actions

Business behavior is the real concern of software. Object behavior is an important embodiment of object value and an important symbol that distinguishes it from other objects. Therefore, we say "Bo exists because of its responsibilities !".

2.2.1 anemia vs congestion

The debate on the anemia model and the congestion model has never been discussed, but this article only discusses the differences between the two from the perspective of Bo (only personal opinion ).

■ Anemia objects

A domain model formed by business objects that do not have any behavior is called the "anemia model" [2]. For the getter/setter method with only attributes and Bo with no business behavior, it can be considered as an "anemia object ". The anemia object that loses business logic behaviors. Similar to value oject, it plays the role of data iner, and will lose the ability (or be abandoned or marginalized) in the logical operations in the business domain ).

■ Congestion object-according to the master's statement, the behavioral responsibilities directly related to Bo will be assigned to Bo to play an important role in the domain model.

However, they cannot say who is good or who is not good. They should be divided into two parts. They have their own characteristics and are applied in different scenarios. In particular, it is difficult to fully understand and clarify the needs, and the anemia model may be used to better control the situation than the congestion model. "User requirements-business-domain" is a process of increasing knowledge. The establishment of domain models should be based on a thorough understanding of objective business domains, it cannot be left-right (isn't it a game? There are no excellent things, but there are more suitable things under consideration of many factors ).

2.2.2 single responsibilities

Before talking about "single responsibilities", let's talk about business core. Bizcore is the embodiment of the core values of the system (Business skeleton and soul. My understanding of bizcore: it should be the most refined, pure, simple, direct, and lightweight Business Core. Therefore, the roles and actions that do not fall within the scope of core business logic (such as persistent operations) should be throttled to the objects that process them. [When writing this text, I would like to add some concepts of DDD, but it is really inappropriate to use a new concept to explain a concept that is not obscure.]

With this boundary (or principle), let's talk about SRP (single responsibility principle ). It is often seen that God class (God class, you can think of it as a congested object), it can do almost all the work involved in it, in this way, the Code contains hundreds or even thousands of lines of ox X class (the most ox X class I have ever seen, close to 5 k lines of code ). Excuse me: with such a category of ox X, won't other classes become a float cloud or a chicken rib? This may cause many problems:

1. difficult to understand. There are thousands of lines of code. Few people have the patience to read, and almost no one can fully understand the meaning of the business they express. I can guarantee that such a class will have a huge impact on the ideographic nature of the other method, such as getflowdatafromtaliformaftersave .... (), Wow! This method is well-known, and the incredible method name will let the persistent programmer head off.

2. Difficult to modify. I have no good understanding. How can I modify it? How to refactor?

3. Difficult to expand. If it is lost, it will lead to a bunch of troubles. For a implementation class of thousands of rows (unless most of them are public static methods), don't talk about resources, interface isolation is also difficult to cope with expansion.

2.2.3 who owns data and who holds Behavior

The essence of Bo behavior is to change the status of the Bo itself to achieve business goals, and such changes may require the participation of other collaborators (associations ). Therefore, we can say that "whoever owns the data will have the behavior to change the data (Status ".

In reality, there may be a lot of behaviors related to Bo. If they are all included in the Bo, it will lead to bloat and pollution of Bo and violate SRP. Therefore, the attribution of behaviors must follow the following principles:

■ Methods with high reusability or inherent objects that are closely related to the Bo state are placed in Bo.

■ Methods with low availability or inherent (but dependent on specific scenarios) of objects that are not closely related to the Bo status are placed on the Bo manager or service layer.

The above principle is similar to the domain model behavior in DDD. I even think that the object in the domain model is the purest Bo.

2.2.4 Methods belong to customers

Bo is a black box that contains logic and data. The object user does not know what data is in it or the actual running logic. What the user can do is to interact with the object to achieve the current business goal. Therefore, the behavior of an object is determined by the customer.

As we have mentioned above, Action (method, responsibility) is the root of Bo's existence, and action is for interaction and is used by callers. The caller will send an operation application to the Bo who determines the behavior should be provided by the caller based on his/her own needs. Everything serves the customer (caller) as the center.

2.2.5 behavior Encapsulation

The encapsulation of object behavior has two layers:

1. Never think that you have so much data, so you can freely publish any method. Actually, there are few methods actually used by callers. As with people in reality, too many external exposure behaviors will spread your information around others. At that time, it is difficult for you to change your image! Therefore, only stable and reasonable APIs that have just met customer needs are sufficient.

2. The behavior should be encapsulated in different levels. If you only use the behavior internally, private will be OK. If you need to hold the subclass, protect will be OK. In short, when defining Bo's behavior, hold the ruler in your hand and exercise caution as much as possible. Do not dig holes or debts for yourself too early.

-------- The following content covers -------- in the next article --------

3. Object acquisition

1. Obtain nouns in original documents;

2. Abstract

3. Abstraction Level

4. Business Domain vs field vs technical domain

4 good Bo verification 5 Summary and prospects

1. Analysis and Design Based on database tables;

2. encapsulation changes

3. Oo needs to be split into two parts

4. About "Business architect"

6 References

[1] Eric Evans. field-driven design [m] Tsinghua University Press

[2] elephant: Thinking in UML

[3] http://en.wikipedia.org/wiki/Business_object

[4] http://stackoverflow.com

[5] Martin C Robert. Agile Software development principles, models and practices (C #) [m] p107

[6] Steve Freeman, Nat Pryce. Growing object-oriented software, guided by tests.