Post-reading: Agent Oriented programmig and AOP)

I have never had a deep understanding of the concept of AOP until I have finished reading Agent Oriented programmig (AOP) [1. I may have the opportunity to have a better understanding in the future, but I want to record my thoughts after reading this blog today, although such thinking may be naive. I don't have much knowledge about these concepts. If you have any mistakes, please correct them. (I think it is more efficient to get the knowledge through communication ).

First, we will explain that in AOP, A is agent rather than aspect. Although I do not know the specific differences between the agent and aspect, there are certainly differences. I think aspect-op should emphasize the one-to-one ing between concepts and implementations. A single concept is similar to a single responsibility principle, and I cannot find a similar concept for a single implementation. For a single implementation, we all know the MVC pattern or some other pattern. These patterns are actually just an idea or a concept. The final form of code is implementation, but there may be a lot of places that will use MVC, so there will be various implementations for MVC. (See the first article in the "Agent Oriented programmig, AOP" series, the article the TED neward Challenge (AOP without the buzzwords) [2], the link in the original article is invalid. This is from Google .) The author cited [2] mentioned in his article that the most exaggerated case in his research is that there is a design concept in a software that actually has 0.1 million implementations (times. (In one system I 've studied, the concept: implementation ratio for that single requirement is well in excess of 1:100, 000.) It may be hard to understand, so let's talk about record exceptions (To log failures), We may easily write in the software:
MessageBox. Show (Ex );
Or
Logfile. writeline (ex. Message );
It may also be
Mylogger. logobjecttypea (ex, objecta );
Mylogger. logobjecttypeb (ex, objectb );
...

In fact, recording errors should be a problem or a design concept, but there are many different implementation schemes in the software. This situation may be quite troublesome for maintenance, because they are all in the same concept. If we need to update and maintain the concept, it may be annoying to maintain different implementations.

What I mentioned above is my understanding of Aspect-op. What about Agent-op? I think the "Agent Oriented programmig, AOP" series is easy to understand, we need a model that is closer to the real world. There are many different ways of thinking in the agent-op, such as "mental" or "sense of purpose". I think this is a very important concept. Speaking of OOP, We can naturally think of "objects". One of the functions of an object is to define the knowledge boundaries-what falls within this object (such as members of an object ), anything other than this object. This concept is a milestone in the software field and should be very meaningful. However, we should also be able to understand that OOP itself has not discussed the "Driving Force". In fact, the "sense of purpose" in the current software is more driven by the following two forces: users and the design behind the software.

There is no problem with user-driven systems. After all, software is used by people. However, through the design behind the software to drive the "sense of purpose", I always feel that it is not very smooth-because this design is relatively static, basically, it will not be adjusted based on environment changes. For example, if we refer to the example mentioned in [1] that "the chicken is cooked and then fished up", we may design a chickenclass and a chefclass, A chickenclass event cooked tells chefobject that a checkenobject is familiar, and then we will have the following code (C #2k5 ):

Checkenobject. Cooked + = chefobject. checken_cooked;

The consequence of this design is that no matter how busy the chef is, the chef will kick the chef's foot after it feels familiar. At this time, the chef will have to fish the CHEs whether he is willing or not. In fact, the "chefs" in the vast majority of software are not willing to think about them, but they are just slaves and tools. Some people may say that the "Chef" in some software is mental, but I think it is different from the agent-op. the difference may be in two aspects:

1. It is possible that this is only the accidental result of the unconscious;
2. If you are consciously designing such a "cook", it is likely that it is not an agent-op tool. (Possible production methods are not standardized and there may be some problems .)

Maybe the agent-op is very cutting-edge, and I cannot tell myself clearly. Let's change to process-oriented and object-oriented. First, let us go back for 20 years. Suppose we are using C language. Can we limit some knowledge to a certain range? I want to use struct. We can design a V-table, just like what C ++ does. So we can also write something like obj-> member (obj2); for example: (obj. v_table [id_member]) (obj2 );

But this is still not Oop, and there are still many problems that need to be solved by dedicated OOP tools. The same is true for Agent-op. If we want to create an agent-op software, tools are still quite lacking, and even human thoughts are quite lacking. Don't forget that only OOP tools are available. If the user is still thinking and designing in a process-oriented manner, the final things will not come out of OO. I think the same is true for the agent-op. For example, let me use the agent-op tool.

Why do I need the agent-op? Because the agent-op should be able to provide certain adaptive capabilities (for example, when the chicken nuggets are familiar, when I have time to process, and in what way ), self-adaptability makes it possible to provide self-organizing capabilities. The entire design of a system without self-organizing capability is still hard-wired. We can compare this with the development of the manufacturing industry: there is a new concept in the current manufacturing industry called "Flexible Manufacturing", which is opposite to "rigid Manufacturing ". For "rigid Manufacturing", the movement direction of each production line can only be front and back or left, and at most one mold or tool can be changed. Therefore, the task and goal are fixed. When the task or target is changed, for example, if the vehicle door was originally built and now the aircraft room door is to be created, the entire production line will be scrapped and the software needs to be re-designed. However, "Flexible Manufacturing" is different. The working organization on the production line has a lot of degrees of freedom. What to create depends entirely on the control of the industrial control program. Therefore, in the face of changing tasks and objectives, you only need to change the industrial control program. For software, we also hope to be able to change tasks and objectives within a certain range by simply replacing a small "smart part, because we all know that changes to the needs of software (that is, tasks and goals) are often costly. To achieve this goal, "intelligent components" must be able to adapt themselves to the external system status, or be self-organized with other parts of the system. To do all this, it seems quite difficult with the current technical conditions.

Speaking of this, I may have seen some discrepancies between my understanding of the agent-op and that described in the citation [1. It is precisely because of these discrepancies that I disagree with some of the original views, and let me explain in detail:

Itch 1: OO does not differentiate entities in the real world.

The authors of the citation [1] believe that "invoices" and "employees" need to be distinguished, because "invoices" are no dead goods, while "employees" are smart items. Dead objects only passively accept various operations. In addition to taking the initiative to perform operations, they may also take the initiative to make adjustments or even reject operations.
However, I think that the real world does not mean that the virtual world must be the same. Is there an "invoice" with thoughts and feelings in the virtual world as imagined in cartoons or science fiction films? More sharply, is "Machine (person)" a dead thing or a living thing? In turn, is "employee" a living thing? In another example, what do you want to do if you have a robot employee in your house? Of course, such an example is abnormal, but I want to explain whether objects in the virtual world should have a mind doesn't depend on whether objects in the real world have a mind. I agree with the author that "timer or multithreading can be introduced, but it is always uncomfortable with reality, however, in fact, the essence of this problem is not that the ing between virtual objects and real objects cannot correspond to those in mind. I think there will be some details in the subsequent entries.

Itch 2: synchronization and Asynchronization are artificially stripped.

The author of [1] believes that the operator should not care about whether the synchronous or asynchronous mode is used. This problem should be decided by the operated object.
However, I think this idea may have problems.
Question 1: The operated object must be intelligent to determine whether it is synchronous or asynchronous. If the operated object is an invoice, how can this be explained?
Question 2: in fact, the vast majority of the real world is asynchronous. The teacher said, "The students open 78th pages." No matter the students fail to flip the books, the teacher will continue. The boss assigns tasks to his subordinates, and never says a sentence after the subordinates confirm "Understanding. In addition, if synchronization is required in the real world, both parties usually have the right to decide. The teacher said, "The students opened 78th pages." If a student hasn't turned to that page, he must say, "Wait a moment, I have not turned to that page ". (When the College Entrance Examination review provides key review content, do you rarely encounter this situation ?) If the boss is afraid that the subordinates do not want to understand a sentence, he will also ask the subordinates "Do they understand ?" Or "Is there any problem ?", After the subordinates say "understand" or "no problem", they will continue.
Question 3: In fact, synchronization in the real world is a concept of waiting for others to "Virtualize", just as Asynchronization in the computer world is a concept "virtualized" by independent threads. However, in the computer world, it is difficult to be called to request the caller to wait (or not to wait. In addition to the lack of such concepts and tools in software methods, this also puts a higher requirement on the caller: as long as you know that "synchronization" (or "Asynchronous ") you can call the processing method of the other party to complete the work, but now you still need to know what to do if the other party requires "Asynchronous" (or "synchronous. The simpler method is that the caller continues to pretend that everything is done in synchronous mode, but what is the significance of this? In turn, there are similar problems. Of course, the problem can always be solved, but is there any benefit between the price paid by the solution and the returned result. Obviously, it is impossible for us to make profits in the face of all the current technical conditions. (If it is a workflow engine, the possibility is relatively high. After all, the workflow is close to reality, and there are actually many asynchronous operations .)

Tip 3: it is impossible to simulate sensebility in the real world)
Citation [1] The author believes that the current software problem lies in the lack of awareness capabilities. For example, "If the color of chicken nuggets is changed from flesh color to gold color, you must make the appropriate operation/processing: Pull the chicken nuggets out of the pot ." However, the current software design is more of a "familiar" event caused by chicken nuggets, then, because "I" subscribed to the "cooked" Incident of chicken nuggets, it was kicked by the chicken nuggets. "I" immediately fished out the chicken nuggets according to the program. From this description, "I" does not passObservationCheck whether the color of the chicken nuggets turns yellow to determine whether it is "cooked ".
I think this idea is also very problematic (maybe it is not appropriate for the author's example ).

　　FirstNot to observe, but to observe the amount of observations that do not exist in the real world. If I use another method to subscribe to the color value change event (backcolorchanged) of the "chicken nuggets", the chicken nuggets will trigger the event when the color value changes. If "I" finds that the color of "chicken nuggets" is yellow to a certain extent (backcolor. R + backcolor. g)/backcolor. b> threashold), "I" will pick up the "chicken nuggets ". How about it? Now I want to check whether the chicken nuggets are yellow to decide whether it should be fished? But you must still think it is wrong, because the root cause is not to observe anything, but because "I" was kicked by chicken nuggets ".
In the real world, if you get kicked by chicken nuggets, you may feel uncomfortable, but not necessarily in the computer world. If you develop a machine for KFC to automatically fish chicken nuggets, the customer will expect it to kick the machine when it is ready, so that it can immediately fish the chicken nuggets. In addition, why do we have to block this method when direct, active, and active communication is possible, what about indirect, passive, and passive methods of communication? The reason why the chicken nuggets in the real world won't be familiar with you is that the chicken nuggets in the real world are really dead, not that you don't expect it to kick you. If the chicken is fried, you will feel worse. For another example, why does the boiling water bottle in the real world contain a "Whistle? It is because people expect that water will kick you when it is open, so that you can quickly turn off the fire. Although water is dead, we want it to survive, isn't it?
Therefore, I think this is an inverse: many times we want to be close to reality, just because we expect it to be as convenient as it is in reality; however, if the actual situation does not meet our expectations, we should not follow the actual situation.

　　SecondThe reason for this example is that we need to judge the color of chicken nuggets, but the computer doesn't need it. In reality, everyone is familiar with the color of chicken nuggets, and there is no consistent answer. The root cause is that there are many "quantities" in the real world, which can be divided into two types: "considerable measurement" and "unmeasurable measurement ". The color of the front panel of the chicken nuggets is a considerable measurement. As a result, we are faced with questions about Estimation Based on the observed measurement, but each person has a different answer, because a lot of knowledge and experience are required in the process of speculation. Each person has different knowledge, so the accuracy of the guess cannot be the same. In this example, our fundamental task is to use the unmeasurable changes as a basis for further operations, that is to say, "If the chicken is ripe, it will be fished out ". However, the "cooked" Quantity cannot be directly measured, so we have to guess the value of the unmeasurable Measurement Based on the observed measurement. However, if you are given a magic device, can you tell the chicken nuggets that they are "cooked"? Will you determine the color of the chicken nuggets with one click? You may take a look, in case the device is broken and you don't know, but if the device is not broken, I think you will not bother to determine whether the chicken is cooked based on the color of the chicken.
In short, if the chicken nuggets in the software can provide "cooked" information, it should not be blocked and then "surface color" should be provided for the chefs to guess, this move is close to the distance, waste of brain cells-unless you're designing a quiz game, players play the "Chef" role ......
Of course, from another point of view, we can see that the common commercial software methods do not have the concept of "unmeasurable measurement" (but they are often seen in scientific computing, but it does not exist as a software design concept), let alone any solutions. If the part we are designing is part of interacting with the real world, this concept cannot be ignored. This is the case for the workflow engine-when it is "finished" or "out of the situation", sometimes there is no direct and considerable indicator to indicate this situation. If the software is smart enough, you should consider the ability to speculate on a non-measurable measurement based on a measurable measurement.

　　LastThe author is close to the last statement in this article. I want to raise a strong objection. The author said:
"In the existing delegate solution, we can only register instances rather than types ....... If you can provide a type-specific registration mechanism, you only need to register your subsequent operations on the chicken nuggets once. All the chicken nuggets within the sensing scope can be 10 or 20, they can all be perceived by the color changes and perform the correct follow-up operations. This will be simpler and more natural."
First, at least. net, such as appdomain. unhandledexceptions is an event of the type. net is completely possible, and it is not hard to see. Therefore, this is not an OO problem. It is mostly a problem within a language. Second, it is unwise to register a category to observe all the fried chicken nuggets. This is because it does not belong to the category of knowledge above the type, but should belong to the category of chicken nuggets within a pot. If there are three cookers that are burning chicken nuggets, [1] The author's ideas will be overwhelmed.

However, once again, I quite agree with the author's point: it should not be decided by chicken nuggets when it will be fished, but by the cook, in particular, we need to decide based on other circumstances in which he is located-what else can we do when the tsunami comes? Hurry and escape! This is what the current model lacks. No matter what the chef is doing, it will lead to the corresponding actions of the chef. Of course, you can write as follows:

Priorityqueue needtobefishedout = new priorityqueue ();

Private void chef_chickencooked (Object sender, eventarg E)
{
Needtobefishedout. enqueue (sender );
Needtobefishedout. bringuppriority ();
}

Then get another thread or timer for corresponding processing. However, as the author said, it is quite uncomfortable. For example, you can use C to write real OO programs, use ASM to write web pages, or use a knife to engrave hard disks. The tool is not correct. Therefore, the agent-op must be developed.

Finally, I would like to add that OOP and agent-op belong to different levels, so the relationship between agent-op and OOP is more like the relationship between class and method, the former cannot replace the latter, and should be developed on the basis of the latter. (I even think that the agent-op is no longer in the language category. It may not necessarily appear after the appearance of OO, all languages in the world are developing in the direction of OO .)