Today I was wandering around the CSDN forum and found such a post "I just saw a few lines of exquisite code from a martial arts master, and I couldn't figure it out, I hope you can give me some advice". With the attitude of learning from all the martial arts masters, I see After finishing the entire post, I found that the content is very classic. I recorded it here to summarize:
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 remove a line of code in StringGrid. I worked on this problem for 2 hours but couldn't solve it. Then I searched the post and found that the master's code was so admirable that he was like the endless water of the Yellow River and it was running through. But why does TStringGridEx = class(TSTRingGrid); have the DeleteRow() method? It is obviously also an inherited TStringGrid, which is the same as TStringGrid? My head is too big! Hope you give me some advice!
The above is the content of the poster’s question. The question is indeed strange. After discussion by major leaders, we have drawn the application characteristics of a DELPHI-specific protection-level member. This should also be a unique object-oriented support feature of DELPHI. The summary is as follows:
1. The protected members of TStringGridEx can be accessed in TForm because they are defined in the same unit.
2. The protected members of TStringGrid cannot be accessed in TForm because they are not defined in the same unit.
3. Since TStringGridEx = class(TStringGrid), accessing the protected member of TStringGridEx here is equivalent to accessing the protected member of TStringGrid
4. TStringGridEx is just an intermediary, and its function does not extend, but it introduces the scope of TStringGrid into this unit, so TForm can access the protected members of TStringGrid.
The view of Zhangmenyi is that the PROTECTED and PRIVATE members of DELPHI are visible to various classes and objects in the same UNIT, and the PROTECTED members can be visible in the UNIT of the member subclass, so TStringGridEx only inherits TStringGrid and does not do it. Any modification can also make the PROTECTED members in TStringGrid visible in the UNIT of TStringGridEx (another reason is that TStringGrid is not defined in this UNIT, so you can only make this UNIT a friend through inheritance, so that the PROTECTED members of TStringGrid can be opened. ), the problem was solved. We can also get a glimpse of the object-oriented characteristics of DELPHI from this.
Although it is convenient for development, it can confuse beginners
Not even rigorous enough
But anyway, delphi is no longer in the glory, let's just use it
Zhang Men San’s comment: There is no perfect thing! There are only things that are suitable!
Zhangmen 4's comment: The protected method is generally hidden, so it is impossible to directly generate an instance of the class, but in delphi, the class located in the same unit is automatically considered as a friend class, and it can access its protected Method, so you can see the protected method by writing a subclass implementation in the corresponding unit.