Some experiences in Object-Oriented Analysis and Design

Some experiences in Object-Oriented Analysis and Design

Analysis, Design and Implementation

 

What I understand is the true object that exists or does not exist in real life. An obvious feature of this object is that it has many state features and behavior characteristics. For example, if a person is an object, he will experience countless interaction scenarios throughout his life. In this process, the behavior characteristics of each person will increase, and most of the behaviors are learned by the day after tomorrow, only a few behaviors are inherent; on the other hand, status features are also changing from time to time, such as your height, weight, and so on. Finally, people will participate in different interaction scenarios, which will lead to an increasing number of associated information. For example, when you go to college, the teacher will give you a debit card, now you have a debit card, which can be understood as an additional associated information. On which day did you go to take the CET4 test, you scored 70 points, and then you have a certificate for CET4, the score above is 70 points. At this time, you also have an additional associated information, that is, a certificate for CET4.

Objects in real life:

1. All States and behavior characteristics in various scenarios;
2. The inherent state may change from time to time, and some associated information will be added through participation in the interaction scenario;
3. Behavior increases, generally through learning. Therefore, we can know that objects in real life are definitely not the objects in our software design because they are so complex, contains or is associated with many state features and behavioral features;

Objects in the object-oriented analysis stage

Since it is an analysis stage, we should not think too much about the ideas of any design stage. I think in the analysis stage, we mainly consider two aspects when analyzing objects:

1. State feature variation of objects;
2. Behavior Characteristics of objects;

In the analysis phase, we often start from a specific scenario and analyze the "objects" in this scenario. The reason why the "object" is added with double quotation marks is that it is not a real object, but a certain aspect of a real object. In a specific scenario, we only care about a certain aspect of the object. I think the objects in the analysis stage should be consistent with those in real life, or at least logically consistent. That is to say, in the object-oriented analysis stage, we should clearly describe all the features of the objects we understand in real life. For example, a person can participate in different interaction activities in different scenarios (a scenario represents a boundary for consideration. The meaning of this sentence is:

1. The same object will participate in different scenarios and travel various interactive behaviors;
2. For the same object, we will consider it as a different type or role based on our different perspectives;

For example, a person may be a father at home, a employee at the company, or an athlete at the competition. However, no matter what kind of title we give to this person, this person is always the same object. In the object-oriented analysis stage, objects give us the feeling that they are constantly changing their types or roles. As mentioned above, when talking about what is an object in real life, after an object participates in an interactive activity, there will be more associated information. Who does this information belong? The answer is: The information belongs to the object playing a role. The reason why the information emphasizes playing a role, this is because we want to make it clear that the object must have the associated information after assuming a role to participate in a scenario interaction activity. Conclusion: In the object-oriented analysis stage, the main points of our analysis are:

1. Understanding the changing laws of object state characteristics and behavior characteristics from the perspective of real objects in real life;
2. Understand a certain aspect of a real object and an object (that is, the object we care about ");
3. Understanding that the same object will assume different roles to participate in different interaction scenarios;
4. Understand how the association information of an object is generated and who the association information belongs;

Objects in the object-oriented design phase

First, let's talk about the methods used to create objects when the current programming language implements objects.

C # Is a type-Based Static language. The type specifies the state features and behavior features that an object can possess. All States and actions of an object are determined by the type of the object; when this is another obvious benefit, we all know the object type or interface at any time, so that we can clearly know its data structure and the object state, in this way, the object state can be easily persisted or the object can be rebuilt; however, this design concept brings state and behavior characteristics to the image also has a drawback that the object type or its displayed interfaces cannot be changed. This is against the characteristics of "real objects" or "objects in the analysis phase.

A weak type of dynamic language, such as JavaScript, that is, the object has no type. The State and behavior of the object do not need to be obtained from the type as a template. The State and behavior can be appended to an object at any time. This idea is actually very good, because it is very consistent with the change rules of the real object state features and behavior features mentioned above. However, this language also has some fatal disadvantages:

1. Because there is no type, it is impossible to clearly know the states and actions in use, which increases the possibility of programming errors, only when the operation stage detects a nonexistent access status or behavior;
2. Objects cannot be persisted because they do not know the States to be persisted. Likewise, let alone re-build objects. Therefore, based on these two shortcomings, I think dynamic language is not suitable for a lot of use on the server side to implement business logic for engineering purposes, but in some client environments that do not require Persistent Object states, it is suitable to use this language only when processing logic in the memory;

When designing software, how should we design objects in static languages such as C # And languages based on classes and interfaces? In the design phase, I think the goal is to convert the objects obtained in the analysis phase to the design in a smooth way as possible. The main points to be grasped are: 1) create an object from a basic class; 2) use a smooth design idea as much as possible to support the characteristics of an object with different types or roles. For example:

1	var gonn = new Person();

2	gonn.Eat(); // Eat

3	var teacher = gonn.ActAs<ITeacher>();// Assume the instructor role

4	teacher.Teach(); // Teaching

The gonn object is a person first, so the basic state features and behavior features (such as eating) are obtained from the basic type of person. Then when gonn goes to teach, he will assume the role of the teacher. After playing the role, he will become a teacher, and then he will have the behavior (teaching) assigned by the role of the teacher. The above code looks similar to the Change Pattern of a real object in real life and is not smooth. There are several advantages to doing so:

1. Strong type;
2. The object interaction model is exactly the same as the interaction model in real life, so the code is easy to understand and readable;
3. Objects will not become bloated and complex as they participate in more interaction scenarios. Because of the introduction of the role concept, we design the interaction model as a way for an object to assume a role to participate in interaction activities, it enables the object to be dynamically assigned an identity, so as to have state characteristics and behavior characteristics related to the identity;
4. After an object participates in an interaction scenario, some associated information is not directly stored on the object, but on the "object that assumes a role". In the preceding example, the teacher object is used;

Objects in the object-oriented implementation phase

So how to implement this design? VaR Teacher = gonn. actas <iteacher> ();

In fact, it is very simple. It can be implemented using the decoration mode. We all know that the decoration mode in the design mode can dynamically ADD states or actions to an object. Therefore, in the implementation phase, we can design a teacher class, which is roughly designed as follows:

01	public class Teacher : ITeacher

02

{

03	private Person actor;

04

05	public Teacher(Person actor)

06

{

07	this.actor = actor;

08

}

09

10	public void Teach()

11

{

12	//do the teach operation.

13

}

14

}

The teacher class is the object in the implementation phase, while the teacher class is the object type in the implementation phase. We can see that the teacher Class is associated with a person object and the iteacher role interface is implemented. Therefore, actas, VAR Teacher = xuehua. actas <iteacher> ();

This function is used to create a teacher class instance internally. This instance has a reference to the current person object and then returns it. You may say that the returned teacher object is not an xuehua object, but a new object and encapsulates the xuehua object, therefore, this is an implementation problem. When paying attention to business affairs, we care not about the real type of the current object, but about the state characteristics and behavior characteristics of the object. Or technically, we care about the interaction model of the object, it is concerned with the interaction of roles played by objects.

Summary

1. Find the most critical business scenarios. Generally, you can search for them by verb. For example, in the recruitment system, when a candidate posts a job, he or she applies for a job. When a student takes an exam in a certain course, the examination is a business scenario. If a student goes to the library to borrow books, the borrowing is a business scenario;
2. Analyze the scenario participants for each business scenario, which participants participate in the form of objects, and which participants participate in the form of services.. Why do we need to differentiate between objects and services? Sometimes we don't care about which participant is, but what the participant is. Generally, in the system, we only care about what service it is, and there is usually only one instance of the Service in the system. The objects are different and we care about who the objects are;
3. Analyze the basic state features of the participant objects in each scenario. The so-called basic State feature refers to the inherent state feature of an object that is created from the very beginning. The most vivid example is the height and weight of a person, when a person is born, he or she has two states: height and weight. For another blog post, he or she has the state feature of content since he or she was written, however, we can modify the content of a blog. However, some status features cannot be modified. For example, the creation time of a blog post cannot be modified once it is created; it should be noted that we should not regard the association information associated with the object as the basic State feature of the object. For example, if a person has a certificate for cet6, the relationship between the person and the certificate is related. The certificate is not an inherent basic State feature of the person, people participate in this test. I will discuss how to think and understand this Association later!
4. Analyze the roles played by the participants in each scenario, the complete interaction process of the entire scenario, and the interactions performed by the participants in the scenario.. I believe everyone understands that this is very important because it involves how objects interact and how to analyze which object should have what interaction responsibilities; this ultimately determines which method the class should have at the code level. I will introduce the example of thinking in this regard below. Let's talk about the theory first. I think the key point is to understand each interaction behavior in the entire business scenario through a four-color prototype analysis method. The four-color prototype in one sentence is: What kind of person, organization, or item participates in an activity with a role at a certain time or within a certain period of time. Another trick is that we can often ask ourselves, "who notifies who to do what? "Who are the drivers of behavior? Who is the performer of the behavior? Generally, the behavior is driven by the notification party, the behavior executor is the notified party, and the notified party has the "Action requested by the notification party" action. In addition, I think it should be noted that objects in real life do not mean that they assume a role before they have the behavior defined by the role, but they do, this behavior is only shown after the role is assumed. For objects in real life, the behavior defined by the role is executed and the behavior assumed by the role occurs simultaneously; but the objects in software are different, because the objects in software are only some aspects of objects in real life that we care about, so their capabilities are limited. In addition, from the perspective of a single responsibility for design implementation, we will not make the image design in the software very complex, including a lot of responsibilities, because this will make the object difficult to maintain, this does not violate the analytical principles, but the design principles. Objects in software are often designed to dynamically inject interaction behaviors defined by roles to objects when they assume a role, so as to give objects the ability to participate in scenario interaction. Therefore, simply put, an object in the software usually only has basic state features and basic non-interactive rows. When it assumes a role, it dynamically has interactive behavior;
5. After the interaction process is analyzed, the basic state features of the participants in each scenario are changed.. This is easy to understand. When an object participates in an interactive activity, some basic state features will change. For example, after a person participates in a 100-meter running competition, the heartbeat speed will increase; the heartbeat speed is the basic sign of a person. It should be easy to understand.
6. Analyze how to record and track this interaction behavior, and analyze what additional information will be generated for this interaction behavior. It is estimated that we seldom think about this point, and this is also the most distinctive part of my Object-Oriented Analysis ideas! You must know that an object interaction activity will generate some interaction information related to the interaction activity. For example, a candidate activity will generate information related to the activity, such as admission, written test scores, and interview scores. For example, an exam will generate the exam score information; A single borrow will produce a borrow information (including: the borrower, the borrowed book, And the borrow time. We may also design a return time). In many cases, the interaction information will be updated in other subsequent interaction scenarios. For example, the initial status of a job application may be "new delivery", indicating that the candidate has just submitted his resume and selected a position. Later, she went to the test or interview, then the application status changes to "tested" or "interviewed". For example, if a student takes an exam, he or she has no score at the beginning, however, after the instructor approved the paper, he got the test score. For another example, if the book has not been returned, the time for returning the book is blank. Once the book has been returned, there will be a time for returning the book. Therefore, from these rules, we can find that interaction is actually a process, and once this process starts, it will generate some relevant information, such as the application status, test scores, the return time of borrowing information, and so on. We usually consider all the information involved in the interaction process and all the additional information generated in the interaction process as a whole. Therefore, I think it is necessary for us to design an object to express the result of an interaction. This result contains all the information involved in the interaction process and all the additional information generated during the interaction process; think about the word "Apply". Sometimes you think of it as a verb and think of it as a noun after its advantage. When we think it is a verb, we focus on interaction, activity, and behavior. When we think it is a noun, we focus on all information generated by the application. Therefore, here, I think there should be a number in your mind, that is, after the interaction ends, we often need to design an object to indicate the relevant information of an interactive activity; on the one hand, this information reflects the participants of the Interactive Activity (interaction time, InterAction location, if we care about this), and on the other hand, it reflects the additional information generated by the interactive activity, such as the score, the application status, the time for Returning books, and so on. Finally, it should be emphasized that this information is designed as an object because it is neither historical nor unchangeable. On the contrary, this information will be updated in other subsequent interactions; so, as we can see, I think we don't need to worry about how to store the information associated with an object after it participates in an interactive activity.

Some experiences in Object-Oriented Analysis and Design