Pr#1 Encapsulate What Varies

Looks like, this comes from the commonsense! After all, that's what the OO-paradigm (OOPS!) is all about! Then why look at it as a Design Principle?

Hmm, well, what OOP tells us is to think in terms of objects (did I not say 'Abstractions'?). So, if you are designing a game similar to the 'Age of Conquerors' in Linux (say, for instance, you are Linxemble Studios!), the first thing you might do is to identify all the objects. To name a few, Warrior{Cavalier, Knight, Archer, RifleMan etc..}, Weapon{Sword, Bow, Rifle}, Building{TownCenter, Barrack, Academy}, Resource{Gold, Stone, Wood, Berry, Sheep, Boar} that will interact. The next would be to see how they will interact. Then, how would you define and update the state of each of the object in the play. So on.

But wait! May I ask, how are you going to implement the algorithm of maintaining the state of any object in the play? You don't know yet! Right? But the design has to proceed, so you need to know exactly how would you maintain the state (think it as a collection of data members, for now).

Ok! Let me be specific. Every Warrior has to have some life! (Yeah, they do ofcourse! I mean, he can fight till he is not dead). Let's have a simple abstraction for the life, say an Integer (** private Integer life **) with a starting value of 10 (MAX_LIFE). Once the value reaches 0, the Warrior dies. Looks simple, huh? You'd ask, who governs the reduction of the life's value? Well, that's what we don't know yet precisely! But we need to device some way to handle it. OR else, can we proceed with the rest of the design (which eventually seems to boil down to similar decisions)? OO-paradigm does not talk about this (well, it's not supposed to!). Using OOP specs, you think, it's the life of a Warrior, so the algorithm to maintain it somehow needs to be encapsulated within the Warrior. And you are stuck because unless you know the algorithm precisely, you can't finish designing the Warrior itself!

Well, the Design Principle "Encapsulate what varies" has the answer! And this is where it differs from the OOP. To understand how, let's try to immitate a novice designer (like us!) who does not know any thing about the Principle. For now he thinks very simple (KISS?!) . He comes up with the following strategy (remember this word, we'll come back to this!).

Well, if the Warrior sits idle, unattacked, his life is no way gonna reduce! But under attack (could be from a wild animal or another Warrior), the reduction of life-value is a function of 'Armour Strength' of the attacked and the 'Attack Power' of the attacker.

So, he atleast for now, proceeds with the design. So it could be a method in Warrior, calculateReduction, that takes the attacker as an argument.

Now comes the real fight, where our Warrior is surrounded by a group of Warriors! The poor designer has to look back into the Warrior-method to accept a Collection (which has its own ramifications). Not a big deal! Some things are meant to change anyways (or we'll lose our jobs!). Later in the evening, the game planner (who does not know any programming) says, dude, I have a fantastic idea - there would be Monk(s) who could heal our Warrior under attack!!

You see the twist in the story, where the Warrior surrounded by attacks, is continually healed by a pack of Monks. And yet another change in the algorithm! You want more? Ok,

let a Warrior A be under attack from a Warrior B who's on a higher ground! Both the Warriors are of same calibre and started with same life, but, I want A to die first (in fact the only Warrior to die, in this situation!) as B is having the advantage of higher land.

And you run wild! This might change not only the warrior but many other!

So, is there any end to this? I don't know! But the principle seems to help us out. It says,

Well, you have discovered that the algorithm to calculate the life-reduction will always vary. Why not encapsulate it!

Well, that's what we try to do! No, not the OOP-way! The principle says, encapsulate the algorithm as an abstraction all together and let the objects under play have access to it. You assume some AbstractLifeCalculaionAlgothithm (which could be implemented later) and go ahead with the rest of the abstractions (Warrior, Nature etc..) . You see, you also have some scope for later optimizations, as now the algorithm is not within the individual objects under play, rather it's a centrally encapsulated entity (LifeCalculaionAlgothithm), which the objects under play have access to. This AbstractLifeCalculaionAlgothithm can change for ever, without forcing the other abstractions to change!

Well, some of you already familiar with Design Patterns, might say "Oh! it's just the Strategy Pattern!". I'd say "I do not care! (BANG!) ". My basis of study is Design Principles, not Designs Patterns (atleast here).

And to be true to you, this Design Principle does not actually differ from the encapsulation in OOP. But to project 'what this principle has so special about it which is not talked in any OOP book', I took the example we discussed.

Now let me talk about Abstractions. All what you saw in grey are examples of abstractions. Abstractions are the heros of our next Design Principle.