Reflections on a problem in OO, an old code (1)
Reflections on a problem of an old code in OO
First of all, I will mention this paper first, as the prescription discussed below: a dead object can't have any behavior.
That is to say, when an object has been released, we think it is unreasonable. Despite objective, in practice, the program can run normally. This problem is currently only similar to C , Delphi is not a survival self-managed environment, in the syntax environment like Java, C #, will not encounter this.
The situation is like this, such as such a code. From the perspective of the machine code, he can run normally.
/// c
#include
Class car {
PUBLIC:
Void beep () {
Std :: cout << "beep !!" << std :: endl;
}
}
Int main () {
CAR * car = new car ();
Car-> beep ();
Delete Car;
Car-> beep ();
Return 0;
}
// Delphi
PROGRAM DEMO;
{$ Apptype console}
Type
TCAR = Class (TOBJECT)
public
Procedure beep ();
END;
Procedure tcar.beep;
Begin
Writeln ('beep !!');
END;
VAR
Ocar: TCAR;
Begin
Ocar: = TCAR.CREATE ();
Ocar.beep ();
Ocar.free;
Ocar.beep ();
End.
/
/// Operating results, it is
BEEP !!
BEEP !!
The reason is that car-> beep (); actually is interpreted as a compiler as a Car :: beep (car); this form.
That is to say, in fact, the compiler will not decide whether the CAR is a correct value. Even if he has been released, the program will make it normally.
However, when Beep used to use the data in the Car, this data is objective, this is an internal memory access error.
For example, a car has been destroyed, we can't expect the soul of the car to make some things, this is not very good, although the car soul can still do something.
However, this is actually there is hidden dangers. If someone is accidentally, call some of the actions that need to be used to use to use it, a memory access error occurs.
//
//
Reflections on a problem in OO, an old code (2)
However, in the actual life, it is not always perfect, sometimes people still have to encounter some problems. When you accidentally, the car is dead, people continue to operate the soul of the car, and there is a hazard.
As a result, we need to consider a new problem, a social problem, suicide phenomenon, in the process of writing procedures, the same problem.
An example is that the Free function in Delphi can be seen in the System.Pas unit. He is just a normal function. He is doing a job is to call DESTROY to release himself, it is ending yourself. Since the existence of Free, Free this name has become a special function. Experienced programmers can always be consciously avoiding the use of the object after Free.
Similarly, we can also make a function of the same function, maybe what is DIE, then we will easily make such an error in the object of the object. In this case, we can avoid it. However, this is hard to say, it is difficult to say that there will be some special situations in the actual life.
For example, a calls B, B call C, and C found that the work has been completed, and the object itself ends yourself, you can do this by other methods or itself. However, more unfortunately, A and B call stacks, or need to end. That is to say, if A and B, like we say in (1), there is no data on the target soul, we said that this hidden danger is lucky. However, usually, A and B will have some operations, which inevitably access some data, so that the program is wrong.
There is a remedy, and it is also, usually using a more way, and the return value is used to determine, so that the following operations are treated. In this way, we said that we played the role we expected.
However, what I want to say is, this is not good, our code will have to become ugly and confused, a lot of conditional statements, keep judging whether or not to continue processing, after multiple continuous judgment, our code The branch of the execution path is quickly rising. This is a result we don't want to see, and his by-products are somewhat uncomfortable.
Moreover, we have to mention an additional problem, our procedures are not just a route, and there is Windows's message mechanism, and the impact of us bringing more complexity, and the problem is more concealed. We know that both of the message mechanisms of Windows, both of their actual essence is, call registration process, regardless of how VCL encapsulates, and finally, we will call our own functions.
At this time, we can see that our system stack has been influenced by two factors, the call inside, is a sequential call, from beginning to end; there is an event type. These two mechanisms have formed our Windows programming, and the system stack also in these two calls, stack, and quench. Very perfect, it is also very smooth, expressed admiration for my seniors.
However, this simple and clear mechanism is not all. We said that rules are used to destroy, there will always be such a reason, covering it in some mechanisms.
This is another problem, for example, the computer has developed from compilation to C. From the machine code, transition to the oriented process. I don't know which boss, the proposed structured programming. In a revolutionary way, the productivity, the productivity, rose a large truncation, but the price is that some assembly language must be given, and some can be called God's pen, but it is definitely from the structured programming, it is destroyer. The way, some examples, JMP instructions. To know, our map spirit requires that a long tape, a pointer, a status table, this is a full calculator. The JMP instruction is to control this pointer. So, a lot of metamorphosis has appeared, it is a long story. Interested, we can discuss it again. Familiar with C language may remember that there is a bizarre function, setjmp, or setlongjmp, his role is to give a way to destroy the stack.
