Requirement:

Many of you might have seen the movie “The Lion King”. Today we are going to model it using Object-Oriented design techniques! Sounds exciting? Lets start with our requirement.

“Mufasa (father), Sarabi (mother) and Simba (cub) are resting below a tree to escape heat. When Simba moves closer to Sarabi, she cuddles him. When he moves away certain distance, Mufasa gets uncomfortable. He roars and commands him to return.“

Quite simple and straight forward, isn’t it?

Purpose of Object-Oriented Analysis and Design is to model classes, methods and association between them. OOAD is much more than this, but let’s limit ourselves to this simple definition. Let’s break this activity into small steps to make it easy to grasp the concept.

Step 1 – Textual Analysis

In this step, we walk through the requirement and try to identify nouns and verbs. Nouns will help us identify objects while verbs are actions performed by those objects.

Nouns => Mufasa, Sarabi, Simba
Verbs => roar, cuddle, move

Based on the textual analysis, we can identify following objects:

Step 2 – Associate actions to objects

Again, based on textual analysis, it is easy to associate actions to objects.

Step 3 – Abstraction

This is the most important and difficult part of analysis and design process. It can get quite confusing. But if you get it right at this stage, implementation is just a breeze.

Mufasa, Sarabi and Simba, all of them are of type Lion. They are just different instances. In effect, our program is going to have just one class Lion.

But there is a problem. Mufasa roars and Sarabi cuddles. Both methods do not fit in a single class. Also, even though lions have the capability to move, our requirement text associates movement only with the cub. So probably, our class model must look something like this:

Seems like there is some problem with this model too. One day our cub is going to grow up and be the next Lion king. So, what do we do?

We make a fair assumption and an informed design decision that all lions can move. You see, there are many ways to solve a problem. You can approach the problem in different ways as long it does not create unstable structure. So, our new model looks like this:

Mufasa and Simba will be instances of Lion while Sarabi will be instantiated from Lioness. With this model, we don’t have to worry about changing Simba’s type when he grows up.

Step 4 – Object Design

Until now, all our discussion was around application domain concepts. At this stage our focus will shift to computer domain concepts. Again, this is a very crucial step. You must spend enough and quality time in getting the design right. You can of course get it right while coding, but getting it reasonable at this stage can save you from frustration.

Let’s get back to our design:

Wait, Mufasa can roar but what about Simba? He is too young for that. Do you recollect when Simba is surrounded by hyenas and he tries to roar? All he could do was “meow”!

How should we handle this variation in behavior? Should we just create a Cub class? Hmm, that can help. Today Simba can meow, tomorrow he will growl, and one day he will roar. So, should we keep creating class for each variation? No, we shouldn’t. It is very common to get into this situation when performing OOAD. Fortunately, this pattern was identified and documented by GoF (https://en.wikipedia.org/wiki/Design_Patterns). This pattern is called State. Now that you heard about it, take the opportunity to explore it further.

So, what’s our State? It is this:

Simba will be initialised using CubState and Mufasa with AdultState. To achieve this, we must update our application class model:

But how can we make sure program gets Lion object with rightly configured state? This is achieved with a Factory!

Lion factory will encapsulate instantiation of appropriate LionType and configuring it with correct state so that calling program does not have to deal with it. This concept is called “Single Responsibility Principle” or “Separation of concern” or “Responsibility segregation”. I hope you get the point.

Ok Lax, fine! We get you. But tell us one thing, when Simba grows up, should the program restart so that he can now be configured with Adult state? That doesn’t sound like a real program!

You are right! We shouldn’t be required to restart the program for Simba to be an adult lion. We can have an age attribute for the LionType. Program can have a timer that increments age at regular interval. When this attribute crosses certain threshold, CubState can transition to AdultState.

Does all this sound complex? It shouldn’t be. What we discussed are basic building blocks of software engineering. There is a difference between writing a script and building a software. Business problems that we are solving these days, especially in financial domain, are complex and so are the solutions. If you are having problems modelling your software, you can reach out to us. We will be more than happy to brainstorm along with you.