Inheritance and frameworks in component-oriented design

Inheritance and frameworks in component-oriented design

I've been familiar with object-oriented design for nine years. But now, trying to learn about the concepts of component-oriented design, which claims to be an extension of the former one, I can't understand what happens with the inheritance and frameworks. Normally, I used to have a framework of my own foundation classes, which consisted of several layers of inheritance, and these classes have been always used as a basis for further inheritance when building an application. As I can see, components seem to avoid this principle. If I have to create components as stand-alone, self-sufficient entities, which are to be sold or used elsewhere, I can see two ways: including all the parent classes in each component (which would make components enormously large and difficult to maintain) or avoiding inheritance altogether (pretty odd). Both ways look to me somewhat strange. Can you suggest the right process -- is there a third way?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The difference between these development methodologies is basically one of scale. Procedural programming works just fine on very small projects. However, as the complexity of the project grows, the procedural paradigm begins to break down.

This is where object-oriented programming steps up to the plate. Using OOP, the developer is able to successfully manage more complex applications. However, as the complexity continues to grow, then OOP begins to suffer as well. This is easily seen when the inheritance hierarchy begins to be quite deep.

Component-oriented design focuses on delivering an application that is composed of components. These components interact via events. Component-oriented design builds on top of object-oriented design principles in that the components themselves are built using OOP.

Service-oriented programming takes this one step further. Using a service-oriented architecture allows the application developer to focus on what an application does (a service) versus what an application is or has (components and objects). Again, in SOA, you use the principles learned in OOP and COP to build your application, but the focus becomes on delivering a service. Services themselves are all about solving a business domain problem. Using an SOA approach, very complex, dynamic applications can be successfully developed, deployed, and maintained.


This was first published in February 2003

Back to top