Golang Design Patterns – Composite. Not an inheritance

After the series of initial design patterns, we come to the second set of design patterns, structural design patterns, a design pattern that shows how objects or classes are linked together to create. a larger structure to be able to meet more requirements but no less flexibility. We come to the first design pattern: Composite Design Pattern

I. Composite – Structural Pattern

When faced with problems that require the design of a hierarchical or tree structure, where an object contains many objects within it, as well as properties and methods for each object, we often immediately think of Composite. This design pattern helps us to solve a lot of inheritance and multiple inheritance problems.

Composite applies a has-a relationship, instead of is-a like inheritance. Talking a little more about these two types of relationships, is-a relationship is inheritance, meaning that inherited objects are considered sub or child from the parent object. has-a , on the other hand, creates an object with a reference to another object. You can say Apple is-a Fruit , but can only say School has-a Student , composite is used when you want to reuse code for two objects that are not of the same type, and vice versa with inheritance.

II. What does Composite bring to developers?

Composite helps us to work with tree data structures more easily when taking advantage of polymorphism and recursion to handle its problems. Furthermore, with the open/closed principle, you can add new types of objects to this tree structure without affecting the existing structure.

III. Practical examples

We will come to the simplest problem of organizing the directory tree for the operating system, which requires the following problem:

• The folder structure includes Folder and File collectively called component
• A folder can contain many folders and other files
• Folder and File include field name and methods getName, setName and print (print directory structure from current component location)
• Folder has an add method (can add other folders and files)

Sample testcase

With the above problem requirements, we need to meet the following requirements with the Composite design pattern:

• The folder contains the field name and the methods getName, setName, print and add.
• File includes field name and methods getName, setName, print
• Folder and File have no inheritance relationship with each other, even though they have the same fields and methods

IV. Implementation

First we start defining the struct File and Folder, as follows:

That’s it, after completing the struct definition for File and Folder, here we see the Add method of Folder taking as an argument a Component list. As required, we use Component as a common object for File and Folder, because these two objects have no inheritance relationship with each other.

Component struct defines the following:

At the step of running the program, we declare the files and folders according to the test case above (the test case is a bit long, so the code is the same)

Run the program and get the results:

V. Conclusion

Use Composite when we realize that we are using the functionality of objects in the same way, and their source code is almost the same. However, once the differences between objects are too much, the application of this design pattern becomes more complicated, more difficult to understand. It all depends on our choices

Thank you for viewing the article.