Object-oriented or Component-oriented, which to choose?
What different? why one over another?
Nowadays there is a lot of different architecture and paradigm that programmer can use to develop their software. However, there is two common one, that is object-oriented and component-oriented programming. Which to use and what’s the difference? We’ll talk about it in this article
What’s different between the two?
Interface vs. Inheritance
In object-oriented programming, the software is often modeled as complex hierarchies of classes that resemble the business problem that the software trying to solve. Programmers will often reuse existing code by inheriting it from an existing base class and specializing its behavior. This is not the case with component-oriented programming. Reusability in component-oriented programming is achieved by extending the interface which each component later specializes by the needs of that certain component.
Black-box vs. White-box
In object-oriented programming, most programmers will need to be familiar with the details of the base class implementation. This form of reuse is called white-box reusability. This kind of reusability did not allow easy adaptation of third-party framework nor expand the software on a larger scale. On the other hand, component-oriented programming promotes black-box reusability instead. This kind of reusability allows each component to use an existing component without caring about its internals as long as the component complies with a predefined set of operations or interfaces.
Monolith vs. Blocks
Software that is built using the object-oriented mind is usually resulting in monolithic binary code that shared the same process, address space, deployment unit, security privilege, etc. This may increase complexities for multiple engineer work since they need to share all the source files for the program to work. This is not the case with component-oriented programming. The perfect analogy for component-oriented programming is the LEGO™ block. While it may necessary to share core components (foundation) of the apps, each component works separately and can be worked on independently without the worry of affecting other components or the need to have complete source code of the software.
Loose-integration vs Tight-integration
Another difference between object-oriented and component-oriented programming is the focus. Object-oriented thinking tends to focus on the tight integration between objects, which is usually small, where objects are reused across the entire software while component-oriented thinking tends to focus on the responsibility of each component and mostly operate independently which may or may not share common objects with other components.
Advantages of Each Orientation
Object-Oriented Programming
- Improve Product Development Productivity
Object-Oriented Programming is modular as they divide the business logic into an object-based system that is extensible as we can add new features and behaviors into the object. You can also reuse the object within the entire application without the need of rewrote the object again. Due to these factors, Object-oriented Programming can improve product development productivity.
- Improve Software Maintenance
Because Object-oriented is modular, extensible, and reusable, maintenance of the software will be easier since we did not need to make too many changes in the software when there are some problems.
- Enable Rapid Development
Because Object-oriented programming usually have feature-rich libraries, OOP enables faster development. The code developed previously can also be reused in another project since the code revolves around the object, not certain business logic.
Component-based Software Development
- Additional Cost of Low Control and Care
Because the software is separated into components, engineers did not need to look at another component or part of the software to search for certain code parts. Because the code is in one place, the engineers will have more control over it and did not need to worry much that their changes will affect other components.
- Reliable and Rapid Development
Due to the component's reusability, it allows the team to focus more on business needs rather than the entities. Furthermore, systems built using component-based design are usually easier to develop, deploy, and maintain. Also, component-based designs are generally more reliable because when something not working, usually the one that will crash will be only the offending component rather than a complete failure of the program (it still sucks, but at least the application won’t completely fail *wink*).