Application of Delphi Protection class members

type
　TStringGridEx = class(TStringGrid);

procedure TForm1.Button1Click(Sender: TObject);
begin
　if TStringGridEx(StringGrid1).RowCount > 5 then
　　TStringGridEx(StringGrid1).DeleteRow(5);
end;

This is the code to delete a row in the Stringgrid. This problem I did not finish 2 hours, and then on the search post, found that the high man's code, simply admire the love such as the Yellow River water endless, running also passed. But why Tstringgridex = Class (Tstringgrid), this thing can have DeleteRow () method? It is clearly also inherited Tstringgrid, and Tstringgrid is the same ah? I've got a big head! I hope you will advise!

The above is the landlord to ask the content, the question is really strange, after the main masters of the discussion reached a Delphi unique protection-level members of the application features, this should also be a unique feature of Delphi object-oriented support, summed up as follows:

The protected members of the Tstringgridex can be accessed within 1.TForm because they are defined in the same unit

2.TForm cannot access Tstringgrid members of the protected because they are not defined in the same unit

3. Because of Tstringgridex = Class (Tstringgrid), the protected members who visit Tstringgridex here are equivalent to the Tstringgrid members accessing protected

4.TStringGridEx is just an intermediary, the function does not extend but the scope of the Tstringgrid is introduced into this unit, so tform can access the protected members of Tstringgrid.

The view of the Masters is that Delphi's protected and private members are visible to various classes and objects within the same unit, and protected members can be seen in the unit of the friend subclass, so Tstringgridex Even if the Tstringgrid has not been modified, it also makes the protected members of Tstringgrid visible in the Tstringgridex unit (another reason is that Tstringgrid is not defined in this unit, So only by inheriting the unit to become a friend, so that Tstringgrid protected members open), the problem solved. We can also get a glimpse of the object-oriented features of Delphi.

The comments of Masters II: Two classes defined in the same unit can even access each other's private members

It's easy to develop, but it's very confusing for beginners.

It's not even rigorous.

But anyway, Delphi is no longer the scenery, the use of it

The three comments: there is no perfect thing ah! Only the right thing Oh!

Four's comments: Protected method is generally hidden, so directly generated instances of the class can not reference the method, but in Delphi will be located in the same unit of the class automatically considered a friend, you can access its protected method, So in the corresponding unit to write a subclass of the implementation of the protected can see the way up

Personally feel that Delphi to protected and private in this unit is visible to the programmer and confuse the programmer, so that many of the above examples are strange, of course, this also allows programmers to add a lot of creative skills to play the opportunity, the above example is a clever application of the classic example of skills, But personally feel that these opportunities are still a little bit better. In any case, readability should be the code realm the programmer really pursues, and these strange, tricky code, if I use another language to come back to see it for a while, it's impossible to think of a solution to the problem. But since the choice of Delphi also chose its shortcomings, which is a bit like a pair of lovers, choose the other side is equal to choose his advantages and disadvantages, the world is not perfect things, we can only adapt to imperfect, the pursuit of perfection.