Solving problems by modeling objects
Tue 21 Aug 2018

When we look at the reality or a situation in real world, what do we see? Now I’m sitting at a coffeeshop in Vietnam and look around. I’m seeing people who are talking to each other. I’m seeing the cars are moving, and the staffs are working. They are bringing many cups of coffee to customers.

In fact, all those things in programming will be represented by objects. So, what is the object? An object, you know, in my opinion, it consists attributes and behaviors. It’s hard to explain to you what it is. But we just get to know that each object is a message, a package which includes data. We put them all together to a container and we call it object. We can set anything, anyone as the objects. But be careful. Doing thing like this might make our program become messy. Luckily, it’s not only us who are encountering these problems which relate to software design. There were so many Engineers who solved these ones and made these designs as the prototypes in order the to let the other people follow. Hence, we call it design patterns.

But allow me to skip these patterns. We’re going to talk about these ones in other articles. What I want to tell you is the software designs appear to solve our problems in real world. And the very first step in software design is Object Oriented Design. I have no idea about the kind of design in future but today OOD is the best we have. The most important step in OOD is modeling objects. We have to recognize the objects in real world or in our coding assignments. Modeling them all. Because OOD is nothing except objects. The name said everything. Each object is always created by class. Hence, modeling objects is the most important.

When we look at the reality, we look at it with different perspectives. But we all do same thing. How many objects we need to solve problem? What are they? Some objects are useful but some others are not. For example, we look at a bike. There are actually a ton of objects in a bike such as the rip, cog, chain, mirror etc. A bike can be a big object. But we break them into parts in order to make it easy for us to solve problem. Because, you know, we can't solve it with the big picture inside our head. Because the problem is still the same. Nothing changed. We should break it into smaller problems. Small enough to solve them easily. It relies on the single responsibility pattern. Each object has its own attributes and behaviors (usage). We need to determine which one is need and modeling them. 

I have to say that the designs appear before the implementations. If we try to implement first and design later. It’s wrong track. We can’t get the good design with this. Because this is implementation. The logic can’t be controlled well and being consistent. It’s like we’re staying on a ship without captain. We’re trying to touch everything we see. We have no idea about the direction. We move to left. If while moving to left we found that it’s not the right direction, so we move to right or get back to starting point. It totally relies the feeling. Remember how many times you implemented and re-implemented. You found something wrong and you tried another way. It costed hours and hours. Nice try! but it went to nothing.

This article, what I want to say is we have to load our brain first with OOD and design patterns to make a good design before we implement any scope.