Why I taught my son Design Pattern even before Data Structure...

Learning beyond information suggests a shift from merely acquiring facts or data to deeper engagement with understanding, wisdom, or insights. It encourages individuals to move past surface-level knowledge and embrace more profound reflection, critical thinking, and personal meaning-making. This approach can involve synthesizing information to develop new perspectives, fostering creativity, or applying knowledge to real-world contexts. It emphasizes an active, interpretive process of learning, where information is just the starting point, leading to transformative thinking and decision-making.

Software is beyond memorizing the syntax of a specific programming language - we must get a clear image of the big picture. Studying design patterns helps a software developer get the big picture - from a designer's perspective. Knowing the common design patterns enables us to understand how different parts of the software are related to each other. Not only this, but knowledge of design patterns helps to communicate with other developers in a more object-oriented way.

Let me give you an example.

You know callback mechanism, observer pattern, and event listener pattern - all do kind of the same work - notify some objects when a specific event occurs. However, without the knowledge of design patterns, we will simply try to understand this phenomenon from just a programmer's point of view - and definitely, we will miss the big picture behind writing such kinds of object-oriented code.

I remember, when I studied the command routing architecture of Visual C++/MFC source code, I tried to map it with the Gang of Four design patterns and found out that this architecture uses two common design patterns at the same time - Command pattern and Chain of responsibility pattern.

Studying design patterns helps to decipher object-oriented code more like a professional - and not like a novice programmer. 

It helps to figure out the source code not only from what and how's point of view, but also from Why's point of view. We can explain why a piece of code has been or should be written in a particular way.

Understanding the Why's is very essential for a software developer.

Let me tell you about my journey in NOKIA India in 2007 using Symbian S60 C++ framework.

There is a concept in Symbian called a two-phase constructor. I asked people about the Why's point of view. Nobody gave me the answer - everybody said this is the norm in Symbian. While breaking my head about this "why", I went to Japan and then realized the reason for such a two-phase constructor - to avoid the exception during constructor in case of low memory. Because in the earlier days of mobile phones, there was limited memory and moreover there were no template concepts in C++. Hence there was no smart pointer. This led me to study Boost pointer in Japan in 2008 and voila, in 2009 Boost library became a part of the standard C++ library.

In concisely, to get the big picture of any object-oriented code structure, it's important to know Design Patterns. It clarifies many questions - particularly why a piece of code should be written in a specific manner.

Here's the evolutionary journey of Ridit, my son and a young Computer Scientist of Bharat - vis-a-vis Design Pattern...

My bragging right - as a Guru of my son...

State Pattern in Java : 8 yrs old

State pattern in C++ : 11 yrs old

State pattern in Python : 12 yrs old

Let me clarify it with another example.

I told my son that most of the modern GUI toolkit take a cue from Composite Design Pattern to design their UI components hierarchy. 

So when we are planning to delve into the source code of FreeCAD, i will show him this piece of code to bolster my claim.

The following python code is an example how FreeCAD component hierarchy is made through the design principles of Composite Design Pattern.

import FreeCAD as App

# Create a new document
doc = App.newDocument()

# Create a composite container (e.g., Part::Compound or App::Part)
composite = doc.addObject("App::Part", "CompositePart")

# Create child objects
box = doc.addObject("Part::Box", "Box")
sphere = doc.addObject("Part::Sphere", "Sphere")

# Set positions for better visualization
box.Placement.Base = App.Vector(0, 0, 0)
sphere.Placement.Base = App.Vector(5, 0, 0)

# Add child objects to the composite container
composite.addObject(box)
composite.addObject(sphere)

# Recompute the document to reflect changes
doc.recompute()

print("Composite Part created with Box and Sphere as children.")

App::Part as Composite Container: 

The App::Part object is a container that can hold other FreeCAD objects. This makes it suitable for creating composite structures.

Adding Objects to Composite: 

The addObject method of App::Part allows associating child objects with the container.

Recompute: The doc.recompute() call updates the FreeCAD model to reflect changes in the document.

I must admit that parenting is one of the best phases of my life. I got a purpose behind my struggles in the software industry.

Jai Hind...