Stupid Question 243-244: Are components(CBD) easier to use than objects(OOP), and what is Component Based Development?

I recently became a member of IEEE. I learned to love scientific journals while studying at the university, and I wanted easier access to the journals I read the most. Yesterday I read an interesting empirical study in IEEE Software about components and objects, and their reusability. If you don’t know what empirical study is just know that it’s research done on direct or indirect observation, not a study citing other studies. It also tends to have a direct goal, looking to answer a specific question.

Study: Atish P. Sinha, Hemant Jain, “Ease of Reuse: An Empirical Comparison of Components and Objects,” IEEE Software, vol. 30, no. 5, pp. 70-75, Sept.-Oct. 2013, doi:10.1109/MS.2012.131

A component is a reusable part that is independent, but not a full system. It does one thing and does it well, but you cannot modify it. Wikipedia uses a card processing component as an example, and as you might have guessed its not object oriented. In Component Based Development the components are combined to make a system, in object oriented programming we have objects that are supposed to resemble how the objects in our world work. A person is a person. A component is what it does/aimed at.

Both claim reusability, and both ways are. But which one wins?

According to this study components were considered easier to reuse. Two groups, identical, had to create a system- one group with components the other using a library, after first using both creating an insurance claim system. Afterwards they were asked questions and those were rated 1-7. 68 out of 76 completed.

I tried finding a duplicate of the study with more information, such as length of study, drop out reasons, how the survey (confirmation bias- internal validity) was done and if components and class libraries had been evaluated and were perceived to be of good and equal quality and so on (external validity and construct).

There is an underlying suggestion that component based developing is the future, and the result of that study confirms that. However I can’t say based on that that OOP is less reusable than components, I would instead argue that it depends on the context a demands. As in the study, to put together a small non-customized system, then I would hope components were easier to reuse as they are independent modules that are well documented. But as soon as you need to customize, which you often do,- or trouble shoot/add fixes, OOP provides and advantage by not being a ‘black box’. And those possibilities come at a slight cost, you need more knowledge of the libraries, OOP SOLID design, and what not.

The relation between of SOA - Service Oriented Architecture and CBD- Component Based Development, and combining those with OO and AOP (Aspect Oriented Programming) would give a more nuanced picture, but I’ll write about that in another post.

Let me know, as always, what you think.

I’m a mere a newb programmer trying to fully understand the large world of programming ;)

Comments

Hi Iris,
I think component oriented development is great and makes the code base grow easier than "pure" OOP projects only based on polymorphism. I don't think COP is having any competition against OOP tho. The trick is knowing when a functionality is part of the family of an object (polymorphic) or only a behavior (to be extracted as component).

My opinion is that OOP extension trees should not be deeper than 3 level since each level increases the complexity of the code exponentially. When a tree starts to become deeper, it should be splitted and / or components should be used to increase reusability and reduce the reach of further required modifications. With object composition, you can change the behavior of a class being extended without (most of the time) having to go trough the whole tree.

When I started using more object composition, I got great feedback that my code was very flexible and reusable. I also noticed that people could get a hold on how it works quite faster so I can only recommend to use it to transform exponential complexity of polymorphism into a linear complexity of composition.

Some interesting post about using composition to program a game :
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Btw, great blog ! I landed here while searching tutorials about the leap motion API and it made my day, keep up the good work and learning :) 

Component Based Development in its traditional sense was the COM/Corba RPC era of the late 90s.  You had procedural programming that begat object oriented programming that begat component based development that begat service oriented applications.  The major problem with component based architecture of that era was that your component spilled its guts across the wire.  Refactoring and recasting CBD as "SOA" is essentially component based architecture hidden behind an encapsulating facade at the service wall.

You mention that the study considers it the future (I haven't read the study...haven't been a member of IEEE for quite a while) but I consider it the past. Perhaps they were attempting to repurpose the term to something other than its traditional usage. 

My thought is that someone writing a study was either too young to know or was expecting the readership to be too young to know: "component" based development has been used for quite a long time now. Traditional component based development evolved into service oriented development.

Saying components are the future is like saying that capacitive touch screens might catch on some day. It's just not that compelling for the IEEE to conduct a study in 2013 that essentially restated a conclusion from 1999 like it was prescient. 

Last modified on 2013-09-27