A Real-world Introduction to Finding classes in Object-oriented Programming Languages
In object-oriented software design, classes are templates for defining the characteristics and operations of an object. Classes specify knowledge (attributes) — they know things — and behaviour (methods) — they do things.
Finding classes is the central decision for building an object-oriented software system.
But how do we find what all classes do we need while building our application?
Finding classes is not as easy as it seems. As a junior developer, I started to learn about it in the training sessions given at Xebia. This blog offers an approach to identify classes that I have learnt so far in my training.
STUDYING A REQUIREMENT DOCUMENT
Every software project starts with the making of a requirement specification document or SRS. But what do we look for in this document that helps us to identify the classes we need?
Natural Language Analysis.
This method was pioneered by Russell Abbott in 1983, and popularized by Grady Booch. The approach is not perfect, but it gives us a good starting point. It maps the parts of speech to different components of object-oriented programming.
As highlighted in the table above
- Nouns are good candidates for classes.
This approach suggests that we find all the noun in our requirement document and underline them. This will give us a list of possible classes that we might have in our object-oriented system.
Keeping this in mind, let’s proceed to a simple example and try to find possible classes
Buying a Toy in a Store
The customer named John Smith enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a type of toy, video game, which uses a data glove and a head-mounted display. He likes it. The suitability of the toy depends on the age of the daughter. His daughter is only 3 years old. The assistant recommends another type of toy, namely the board game “Monopoly”.
In the following step, I have highlighted all possible common nouns for this example
The customer named John Smith enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a type of toy, video game, which uses a data glove and a head-mounted display. He likes it. The suitability of the toy depends on the age of the daughter. His daughter is only 3 years old. The assistant recommends another type of toy, namely the board game “Monopoly”.
As I try to map the part of speech, I came up with the following set of classes.
- Customer
- Store
- Daughter
- Toy
- VideoGame
- BoardGame
Now, while going through the list of classes above, I see a daughter class. Do I really need a separate daughter class? To understand this, I look at what responsibility the Daughter Class has? It only has one attribute “age” which is helpful in finding what kind of toy customer should suitably buy.
“Can I pass on this responsibility to Toy or Customer class?” The answer is Yes.
This helps us to understand that initially, there will be a lot of candidate classes which is a good thing. However, through analysis, their number will be reduced as they might be dropped, combined and merged.
After dropping the Daughter class, This is the possible final list I could come up with.
- Customer
- Store
- Toy
- VideoGame
- BoardGame
In his book Object-Oriented Software Construction-2, Bertrand Meyer states
“Class Elicitation Principle: Class elicitation is a dual process: Class Suggestion, Class Rejection.”
Let’s try to implement the above principle in the following example
Cash Register
A simple cash register has a screen display, an electronic wire with a plug, and a numeric keypad which has keys for subtotal, tax, and total and a drawer for cash storage. The total key which triggers the release on the drawer. Such cash register devices have numeric buttons that simply place a number on the display screen, the subtotal displays the current total, the tax key computes the tax, and the total key adds the subtotal to the tax. Let us identify all the classes in the above problem statement
According to Class Elicitation principle,
In the initial pass, we begin with Class Suggestion where are going to identify all the nouns
- CashRegister
- Wire
- Plug
- Device
- Display
- Keypad
- Key
- Screen
- Button
- Number
- TotalTax
- Money
- SubtotalKey
- TaxKey
- TotalKey
The next step is Class Rejection. Here we are going to eliminate the unnecessary nouns.
The following classes are dropped because they seem irrelevant or vague to the context of our application and there is not much information about it in the problem statement.
- Wire
- Plug
- Device
I have already used Display and Key. Button is the same as Key and Screen is same as Display, so these can be merged as one. Now, I can remove two classes from the list i.e.,
- Button
- Screen
I think the number and total tax can be the attributes of Key class. Thus, I can also safely take out these two of the initial list.
- Number
- TotalTax
Next total key, subtotal key, number keys are all types of Key. They can be combined in Key class itself. So. they are also out of the list.
- SubtotalKey
- TaxKey
- TotalKey
After eliminating all the unnecessary nouns, these are the possible Final Classes, I am left with.
- Cash Register — main class
- Display — class
- Keypad — class containing keys
- Key — class that can have 0–9, tax, subtotal, total
- Money — class
This example helps us to understand that Class Rejection plays an important role as Class Suggestion. Therefore, finding classes means two things: not just how to come up with candidate classes but also how to find the inadequate among them. I would like to quote Bertrand Meyer “ Like a gardener, the object-oriented designer must all the time nurture the good plants and weed out the bad”
DANGER SIGNALS
The table below illustrates the danger signals that we should possibly look out for in order to reject the classes. In case, your classes don’t fall in one of the below categories, they might have the green light. However, if they are in this red zone, I think they should possibly be rejected.
OTHER SOURCES OF CLASSES
The other source of ideas to find classes include
- Existing library
- Discussions with customers and future users
- Discussions with experienced designers
- Algorithms and data structure literature
- Look for applicable design patterns, adhere to the SOLID principles
CONCLUSION
As a junior developer, most of the times, we don’t know where to begin when we are looking for classes that we need and all these times we make our decisions on the basis of what makes sense to us. As a result, the structure of the application becomes complex. But now, I know my starting point when I begin developing an object-oriented application. I hope you will also try using the approach described in this blog and will be able to accomplish a successful application’s business function.
