Architectural pattern - Naked object.

-

Background –

This model is very close to MVC (model-view-controller) architectural pattern. I would recommend you to read MVC first if you have no idea about it. MVC is very nice for any complex application, but when you are dealing with a real time system where user is interested to monitor some specific objects, then implementing it through necked object will be easy. Please look at below mentioned diagram.
(This diagram of MVC is taken from free internet sources)

(This diagram of naked object is taken from free internet source)
                 

I am sure that above mentioned diagrams would have given you a good insight of what naked object is and how it is different from MVC, but let us talk some example so that it gets clear.

Example 1, think about an ATC (air traffic controller) who manage air traffic of airport, through switching on and off the lights on runway, so that flight shall land and reach to its destination safely. Without giving proper light indications to pilot, it will be nearly impossible to control air traffic, and how pilot will know in which runway he supposed to land and other important information to have a safe landing? Now what controller sees in his screen is status of lights (On, Off, faulty) and take actions according to situation. So no need to apply any complex architectures or MVC model to build such application, as the very bottom layer is physical entity which is an object itself, one light is nothing but one object and user (controller) is interested to look the status of that object and want to change the status of that object directly, there should not be any extra cross component is required to execute any business logic.

Example 2, When you ride your car or bike, you will see many indications at your front panel, they shows warnings and notifications about your vehicle’s current condition, status about fuel, battery, seat belt, oil etc..

Most of the controlling systems are like that, their business logic is straight forward, each small entity is one object and we are monitoring the status of those objects. So it is single-entity-direct-user-interaction case and this kind of situation is best for naked object implementation or in other words this will implement object oriented user interface (OOUI). It is like you are seeing fish in aquarium, crystal clear and direct, no extra layer, just transparent glass and clean water, just like naked object.

About naked design pattern –

In this architecture, UI is directly representing underlying objects. All business logic has to be encapsulated within your object. As name suggest user sees each single object direct or naked, it should have all necessary login in it, as that object itself is responsible to processing its own data. 
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

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more

Architectural style -> Adoptable system -> Reflection.

-
Image
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
Read more