Reflection on OOP

Written by Yusuf on 19 Feb 2022

In a forum, students were sharing stories about system failures that cause big consequences. One story tells about how the failed system is causing the loss of $450 mil. in just 45 minutes. It is general knowledge to buy a stock when the price is low, and sell when the price is high. Unfortunately, what’s being deployed to the production is doing exactly the opposite of it. In addition, an investigation found that this is also happened due to no code review or QA process before the deployment.

Another interesting story that was shared is coming from a well-known company in the aviation industry, Boeing. A faulty in the new model’s system was causing two fatal crashes in just five months. Similar to the previous incident, lack of documentation and the improper software development process - rushed release, contributed as the cause of this incident.

According to SAP, being object-oriented means that the focus of the development is on objects that represent abstracts or concrete things in the real world, defined by their characteristics and properties. Each object is encapsulated, making its information hidden from another object and reusable.

One thing that should always be remembered from this course is that object can be anything. It’s not only about classes in programming language, even a database can be an object in object-oriented. Just like a class having one or more relationship with other classes, a table in a database also possible to have a relationship with another table. Although, the definitions and the type of relationships are different in Class diagram and ERD.

Eventually, it’s all about building a system, but the approach is by breaking it down into object, microservices, etc.

In object-oriented system design, one of the advantages is to make it easier to troubleshoot problems. It means that being object-oriented helps us in making sure that the system will behave according to the expectations.

In order to do that, the trick is to test its logic in different ways: documentation, source code, and unit test.

From this course, it gave me several new knowledge that can be used in my day to day activity at work. I have never done a logic test in my documentation before, and I’ve been doing an improper unit test all this time. It turns out, all those three are strongly related to each other, despite they are totally different.

So, the to-do list for me to keep practicing:

More practice on making diagrams
More practice on unit testing when developing anything

Acquiring this knowledge can help me to progress in my career, as it should improve the quality of my work. I think it also exposes me to managerial path of engineering, a position which usually does the design rather than executing the development of the design. Combined with my existing technical skill, they are probably more attractive in the labor market.