Part 2, Object-Oriented Methodology in Programming

Object-Oriented Methodology in Programming, Part 2

This article is based on the previous one, “Object-Oriented Methodology in Programming “...

As we considered in the Object-Oriented Methodology publication, we imagine OOM applied to constructing our “dream house.” 

We have an abstract “dream house” and perform our Object-Oriented Analysis (OOA), defining what we want to see at the end (particular dream house).

OOD allows us to draft the “house plan.” The formal design process helps determine 1) which objects will be used in the program and 2) how they will interact or coexist. The design provides the structure of objects and answers some questions that may arise during code writing. For example, during the house design phase, deciding that placing the garage in the pool might pose some inconveniences is helpful. During the code writing, remember the login page (if any) goes first and differs from the landing page (usually).

However, it’s essential to remember that design is not the aim. 

Just as Object-Oriented Analysis (OOA) suffers from analysis paralysis, design can suffer from design paralysis.

Attempting to describe every detail of the program in the project is not recommended. It is impossible to consider every detail and project element before they are necessary in the coding process; some elements can be added during implementation. There’s a risk of going too deep into the design stage of a program, leaving little time for actual coding. 

What you truly need is to design all architecturally significant parts of the system. How can you determine which parts are architecturally substantial? Architecturally substantial parts are those where the choice made WILL significantly impact the program’s structure or the system’s behavior. If we compare it to building a house, the substantial part is a roof, walls, basement, etc…Wrong architecture of these parts WILL significantly impact the house. But the exact location of the door handles might not be crucial now.

In summary, we have 3 crucial levels:

Object-Oriented Analysis (OOA): Object-Oriented Analysis (OOA) is focused on creating models of real-world scenarios based on an object-oriented perspective.

Object-Oriented Analysis is a methodology in which system requirements are perceived from the point of view of classes and objects identified in the domain.

Object-Oriented Design (OOD): while programming primarily involves the correct and effective utilization of mechanisms specific to programming languages, design, on the other hand, emphasizes the proper and efficient structuring of complex systems.

Object-Oriented Design is a design methodology that combines the process of object decomposition and the representation of logical, physical, static, and dynamic models of the designed system.

This definition encompasses two essential areas:

 Object-Oriented Design 

1) is based on object-oriented decomposition; 

2) employs various techniques for representing models that reflect the logical (classes and objects) and physical (modules and processes) structure of the system, as well as its static and dynamic aspects.

Object-oriented decomposition distinguishes Object-Oriented Design from Structural Design. In the object-oriented decomposition, one should break down the complex system into smaller pieces (sub-systems). The most known example is the elephant:

• Is it possible to eat a whole elephant?
• No, but divide it and eat it in pieces.

In Object-Oriented Design, the logical structure of the system is reflected by abstractions in the form of classes and objects, while in Structural Design, it is reflected by algorithms.

Object-Oriented Programming (OOP):

Object-Oriented Programming is a programming methodology based on representing a program as a collection of objects, each of which is an instance of a specific class, and classes form a hierarchy based on inheritance.

OOP has four significant definitions:

• Data Abstraction 
• Encapsulation
• Inheritance
• Polymorphism

In the context of OOP, mentioning Dynamic Binding and Message Passing is also helpful.

But keep your patience; we’ll highlight these definitions in the respective articles.

So, now we have general knowledge about Object-Oriented Methodology.

We start our journey with Object-Oriented Analysis and decomposition in the following article.

To prepare, you can do a small exercise immediately. Look around. What objects surround you? Can you focus on every object in your surroundings? Can you realize that every object consists of other smaller objects? Can you imagine the purpose of every object? By changing the properties of a smaller object, you can change the appearance and even purpose of the bigger object.

It’s simple, isn’t it?