Architectural style -> Adoptable system -> Reflection.

Background -

We have discussed very less about reflection, especially if you are C, C++, mainframe, LSI developer and working on server side implementation or in low level hardware-interaction development team. 

But it is very popular among high level languages like JAVA, Scala, C#, Python etc, many languages have implemented reflection in it. It gives you flexibility to do things dynamically (at run-time).

After working closely with different clients, you will get a clear understanding that no one is as confusing as a software client, not even your girlfriend! So we should have a flexible architecture in place who can absorb shocks of client’s last moment changes.

Not only that, sometimes we have N number of different behaviors and structure in place, and we want our application to behave differently depending upon run-time situations.

Let’s build understanding step by step through an example. Think you have got an assignment where you have to build an application called “online bicycle rental app”. From this app people can rent bicycle of their choice. A very simple class diagram would be like mentioned below –



Congratulations! your app has became very popular and now client is telling you to enhance it, he want to facilitate bike as well. So now, that app will show self-drive bike on rent as booking option. You have made changes and now you have added a level of abstraction, design looks like mentioned below –



As you are guessing right, client want to increase services and looking forward to give auto and cars for rent through mobile app.

If you are following open close OOPs principle, you will not like to modify existing code each and every time when new requirement comes (because of many reasons like – it is already tested code, huge effort in testing many be required for already tested functionalities all over again, or it many break your existing functionality).
   
As you don't want to touch existing code, you start thinking about whole requirement again, and looking for a very mature design, so that you don’t have to think so much every time, when client come up with new requirements like that.

We are now moving towards to reflection, where we design an interface who can accept any new type/class and through which we can query its properties , can create object of new type/class, can set the value/properties etc. That interface is called meta-object protocol (MOP).  


Here what is the meaning of Meta? It means that it knows all the Meta level (all major and minor) details of newly added class/type, including its structure, properties, and behavior. 

But as C++ developer, all above mentioned information we are knowing at compile time (or development time) as we cannot add new class/type at run time. We cannot create a generic class type and modify it in run time, C++ is strongly compile time language. 

It could be possible with other high level programming language but implementing MOP is not very straightforward in CPP. So to implement reflection we have to implement MOP (or say user defined MOP) in C++.

Soon I will add a simple user defined MOP CPP code to demonstrate reflection in C++.....

Why we are using reflection?

We can create instance of any class dynamically through reflection. We can bind the class to existing object and we can call it's method and access it's property. Also your current object will change and get converted to different type at run time through reflection.



Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Popular posts from this blog

Non-virtual interface idiom (NVI)

Factory method design pattern for beginners.

Architectural patterns => Mud to structure => layers.