Wednesday, September 26, 2012

What is GOD OBJECT and RAVIOLI CODE ?

Hi friends,

The other day , i was going through the basic concepts of OOPS(I am a bit rusty , i fear). It's at that point of time, that i came across two mind boggling terms : GOD object and RAVIOLI code. I will try to emulate here what i have understood .

                                                            THE GOD OBJECT

                                                     

Normally :

The basic idea behind object-oriented programming is that a big problem is broken down into several smaller problems (a divide and conquer strategy) . Then, solutions are created for each of them. Once the small problems have been solved, the big problem as a whole is automatically solved. Therefore, there is only one object about which an object needs to know everything: itself. Likewise, there is only one set of problems an object needs to solve: its own.

The all knowing, all encompassing object : 

In object-oriented programming, a god object is an object that knows too much or does too much. Here, most of a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction.

An Example :

Let us consider a banking scenario. Let us consider, K is customer of the bank ABC . K has a savings account. Subsequently, he has an account number. He can withdraw and deposit and can view his yearly statements. Also, he has a credit card  CC  and a debit card DC. 

So a stray piece of code will look like this :
if(user is customer)
{
acctNumber = getCustmerAccountNumber();
amountWithdrawn = getAmountWithdrawn();
depositMade = getDepositMade();
yearlyStatements = getYearlyStatements();
cerditCardNumber = getCreditCardNumber();
debitCardNumber = getDebitCardNumber();
creditExpense = getCreditExpense();
debitExpense = getDebitExpense();
creditStatement = getCreditStatement();
debitStatement = getDebitStatement();
}

if(customer is highNetWorth)
{
customer.setCustmerAccountNumber(acctNumber);
customer. setAmountWithdrawn ( amountWithdrawn);
customer. setDepositMade ( depositMade);
customer. setYearlyStatements ( yearlyStatements);
customer. setCreditCardNumber ( cerditCardNumber);
customer. setDebitCardNumber ( debitCardNumber);
customer. setCreditExpense ( creditExpense );
customer. setDebitExpense ( debitExpense);
customer. setCreditStatement (  creditStatement);
customer. setDebitStatement (  debitStatement);
}

So here , the object customer becomes a GOD object. Any subsequent change in some part of the existing structure, will require a change here in the customer object as it contains every item related to the user's account .

Advantage of this approach :

In micro controllers, performance efficiency and control are two very important aspects. Here, the use of this technique is very frequently seen.

Disadvantage of this approach :

This object is referenced almost every time within the project hierarchy. Hence, maintainability becomes a problem .

                                                          RAVIOLI CODE 

                                                         

It looks delicious :

Yes, we all know it is delicious. But get a grip on yourself and look at it closely. What do you see ? Can you see what is inside the outer covering ? It's very difficult . isn't it ? Well, that's encapsulation(hiding the contents).

What is this ?

This is the opposite of the GOD object.

Ravioli code consists of very small and  loosely coupled code fragments. The term stems from the analogy of ravioli (small pasta pouches containing cheese, meat, or vegetables) to modules (which ideally are encapsulated(hidden), consisting of both code and data).

Advantage:

Places where we want to have a loosely coupled code structure(which can be changed without butting head against the wall), this is very useful.

Disadvantage :

Too much separation and hiding of the code(encapsulation) makes maintenance very difficult .

Well friends, that's it for today. Hope you found it informative.

Goodbye.

No comments:

Post a Comment