Design Pattern series discussion-combination pattern

Story
In May October 20, a group of people from our company participated in the project bidding for Shaoxing customers. Unexpectedly, on the same day, the company held a tender for three projects at the same time (zhenniu !), So more than a dozen units are waiting. We arrived at the scene at a.m., and our bidding project was arranged in the afternoon. After sitting for a while, we proposed to go to the former residence of Lu Xun. As a matter of fact, I 've been in a hurry on a business trip to Shaoxing several times. Today I finally got my wish.

I have been exercising too little recently. After a few hours, my feet have been sore and tired. However, I was deeply impressed by the two images. One is the 3D ancient city map of Shaoxing, which tells a lot of touching stories. The other is the map of the Zhou family, which is like a towering tree with branches. It can be seen that the Lu Xun family is a big family in huobi County, Shaoxing, Zhejiang Province. Lu Xun, formerly known as Zhou Shuren, has two other brothers (Zhou Jianhe and Zhou Zuoren). His father is Zhou Boyi. He has a son called Zhou Haiying, then we will be dizzy.

I was thinking of a ridiculous question. Who is the best person to have a son in the family of Zhou? Of course, we don't have that much time to start from the beginning to the end. So, let's use a program to solve it.

Composite Solution
The composite mode is also called part-whole ).The object is organized into a tree structure (Zhou's family chart), which can be used to describe the relationship between the whole and the part, so that the client can view the elements and composite elements in the same way, this traverses all elements of the tree structure (all Zhou's people ).In composite mode, three objects need to be defined:
Abstract interface (ielement ):This is an abstract class/interface that defines interfaces for all objects and provides operation behaviors. For example, the statsons method counts the number of sons.
Composite object: A combination of child elements.
Element Object: represents a child element object. A child element has no sub-objects.

The abstract interface is as follows:

Namespace lufamily
{
Public interface ielement
{
String name {Get; set ;}
Void add (ielement t );
Void remove (ielement t );
Void statsons ();
}
}

The combination object is as follows:

Namespace lufamily
{
Public class composite: ielement
{
Private list <ielement> elementlist = new list <ielement> ();

Private string _ name;
Public string name
{
Get {return _ name ;}
Set {_ name = value ;}
}
Public void add (ielement T)
{
Elementlist. Add (t );
}
Void remove (ielement T)
{
Elementlist. Remove (t );
}
Void statsons ()
{
Console. writeline (elementlist. Count );

Foreach (ielement element in elementlist)
Element. statsons ();
}
}
}

The element object is as follows:

Namespace lufamily
{
Public class element: ielement
{
Private string _ name;
Public string name
{
Get {return _ name ;}
Set {_ name = value ;}
}
Public void add (ielement T)
{
;
}
Void remove (ielement T)
{
;
}
Void statsons ()
{
Console. writeline (0 );
}
}
}

The client call is as follows:

Composite root = new composite ();
Root. Name = "Zhou Boyi ";

Element e1 = new element ();
E1.name = "Zhou Jianren ";
Root. Add (E1 );

Element e2 = new element ();
E2.name = "Zhou Zuoren ";
Root. Add (E1 );

Composite C1 = new composite ();
C1.name = "Zhou Shuren ";
Root. Add (C1 );

Element E3 = new element ();
E3.name = "Zhou Haiying ";
C1.add (E3 );

Root. statsons ();

Maybe you will ask, since the element object does not have sub-objects, why do we need to implement the add and remove methods? In fact, the main purpose is to achieve a unified treatment of element objects and composite objects on the client, without having to distinguish which is an element object and which is a composite object. This is one of the two forms of composite mode, that is, the transparent compound mode. The disadvantage of using this method is that it is not safe, because in actual applications, element objects and composite objects are essentially different.

Another form of compound mode is naturally the security compound mode. The security compound mode separates element objects from composite objects in essence. That is, you do not need to provide management methods for element sets such as add and remove for element objects. Let's take a look at the implementation of the security compound mode.

The abstract interface is as follows:

Namespace lufamily
{
Public interface ielement
{
String name {Get; set ;}
Void statsons ();
}
}

The combination object is as follows:

Namespace lufamily
{
Public class composite: ielement
{
Private list <ielement> elementlist = new list <ielement> ();

Private string _ name;
Public string name
{
Get {return _ name ;}
Set {_ name = value ;}
}
Public void add (ielement T)
{
Elementlist. Add (t );
}
Void remove (ielement T)
{
Elementlist. Remove (t );
}
Void statsons ()
{
Console. writeline (elementlist. Count );

Foreach (ielement element in elementlist)
Element. statsons ();
}
}
}

The element object is as follows:

Namespace lufamily
{
Public class element: ielement
{
Private string _ name;
Public string name
{
Get {return _ name ;}
Set {_ name = value ;}
}
Void statsons ()
{
Console. writeline (0 );
}
}
}

The client call is as follows:

Composite root = new composite ();
Root. Name = "Zhou Boyi ";

Element e1 = new element ();
E1.name = "Zhou Jianren ";
If (root is composite)
Root. Add (E1 );

Element e2 = new element ();
E2.name = "Zhou Zuoren ";
If (root is composite)
Root. Add (E1 );

Composite C1 = new composite ();
C1.name = "Zhou Shuren ";
If (root is composite)
Root. Add (C1 );

Element CE1 = new element ();
Ce1.name = "Zhou Haiying ";
If (C1 is composite)
C1.add (CE1 );

Root. statsons ();

For the sake of security, when executing the add method, it is best to determine whether the object is a composite object.