Object Science From the roots

Introduction

Although some books use a specific domain, such as the financial or medical domain, to explain object concepts, the best way to learn is from the roots from which the object concept arose. Those roots are nothing more than a description of the world as it is.

For example, consider the following two passages:

• Passage 1:
  1. English is a language. Tamil is a language.
  2. All languages contain alphabets.
  3. Alphabets of a language combine together to form words.
  4. All languages are used for communication.
• Passage 2:
  1. A shopping complex can have cinema theatres.
  2. Each cinema theatre shows some movies.
  3. All movies run for a specified time.
  4. Tickets are issued to the people who watch the movies.

We can observe that the above two passages are about some of the most common things we face in our daily life. What is triggered within you when you read through these passages?

The answer is Associations. There are associations between things that we see, associations between things we use in our daily lives, associations between things which I use to write an email, associations between things that help us get to our offices.

What are those things? The things for which we try to define associations become the Entities in a given domain. Identification of the entities and the type of associations between those entities are the first and the major tasks in building a good object oriented system.

How to build a Domain Model?

The simple answer is to talk with the domain experts. For example, if the PVR theatre owner approaches me to build some Theatre Management Software for him, being a Object Oriented guy I will first build the domain model. I could do that by speaking with the owner, perhaps as follows:

• PVR Owner: Hi, good morning. I need to computerize my PVR theatres. Could you please help me?
• Me: Yes, of course. But I need to understand your domain. May I ask some questions?
• PVR Owner: Yes, of course.
• Me: Thank you. First of all, I would like to know how many theatres will there be in a complex.
• PVR Owner: There is no restriction, because I can buy space for any number of theatres in a complex, provided that the owner of the complex agrees. Right now I am ready to buy a complex and build theatres in the entire complex. But I may not have any theatre at all in some complexes.
• Me: Okay, that means that one complex can have 0 or n number of theatres, right? Could you please tell me about the movies you show in your theatres?
• PVR Owner: The same movie can run in one or many of the theatres, but there is a specific time during which a movie runs. During that time no other movie can run in the same theatre. Each showing of a movie will accommodate a certain number of people depending on the number of seats present in each theatre hall.
• Me: Okay I will just summarize what you said:
  
  • One Complex can have n number of theatres.
  • One theatre can cast n number of shows.
  • One Showing has a specific time period.
  • One movie can be watched by n number of people.
• . . . The conversation continues.

From the conversation, it is possible to infer various properties of the system to be designed. When we identify any two entities in a domain, obviously there is some type of relationship between them. Some books say that the nouns of a system might become the entities of a domain, but this is not a good way to start, because even the verbs can be modeled beautifully as entities in the Behavioral modeling of a domain.

In object terminology, the entities in a domain are called the abstractions of the domain. A good object oriented system encapsulates all the domain abstractions properly.

Abstraction and Encapsulation

Abstraction and encapsulation are two earmarks of a good object oriented design. To understand this, consider the following guideline:

In a complex system built of subsystems, the functioning of one subsystem should not depend on the interior working of another subsystem.

In other words the entire circulatory system is abstracted and its internal working is encapsulated and hidden from the respiratory system and vice versa.

Abstraction and encapsulation can be further discussed in more detail in a future article.

Importance of Domain Models

The question could be raised: "Why do I need to have a domain model? All I need is just a program which will solve my client’s problem, right?"

We need a clear domain model because we are trying to solve a problem that exists in that domain. We are building a domain model to make the design of the system flexible enough so that it can accommodate changes when the client requirements change. From a programming perspective, the entities and abstractions in a domain model might become classes when you finally write the code to solve the problem.

Role of UML

UML helps in defining the associations between the identified entities of a domain by providing a graphical display of the defined associations. For example, everything that can be inferred in Passage 1, Passage 2 and in the previous conversation with the Theater Owner can be neatly represented in a graphical way using UML.

UML simply defines the syntax for drawing an object model of an domain, but what is important is the model of the domain in which we are going to solve the problem, and not the tool which we use to describe the domain. UML is a tool which may help to bring more clarity to the domain model which we trying to explain. This might be a very useful tool, since a very clear form of communication between human beings since the Stone Age is with the use of diagrams.

Some Scenarios to Trigger Object Thinking

To get accustomed to thinking in terms of objects, you can use the scenarios above as a starting and try to build as many as you can. In addition, here are 3 more scenarios to consider:

1. Chinese food is a kind of a food. Indian food is a kind of a food.
2. North Indian and South Indian are the types of Indian foods.
3. All foods are made of ingredients.
4. Veg ingredients and non-veg ingredients are two types of ingredients.
5. Living beings eat food.
6. Man is a type of living being.
7. . . . etc.

1. A database can store information.
2. A database contains tables.
3. Tables contain columns.
4. Any number of triggers can act upon a table.
5. SQL is a database. Oracle is a database. MySQL is a database.
6. . . . etc.

1. Letters, email, and phones are various kinds of communication devices.
2. Mobile and landline are types of phones.
3. All communication items have a destination to communicate.
4. An address is a type of a destination, an email address is a type of a destination, a phone number is a type of destination.
5. A communication item can have n number of paths to reach the destination.
6. Wired medium, wireless medium, cables, post masters, courier agents, pigeon are all types of communication medium.
7. . . . etc.

All we need to think in terms of objects is observation - keen observation of the things and the associations between the things in that domain.

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)