Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

GayleSaver

Component Object Model

This topic is 6391 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I think that component-based programming is the wave of the future. Soon, applications will migrate to COM instead of traditional static components. What do you think?

Share this post


Link to post
Share on other sites
Advertisement
I think the component object model violates pretty much every principle of true object-oriented programming possible. I think it''s nice for things like plugins (web stuff and common controls comes to mind), but in general, any large architecture based on this stuff is going to be ugly as heck. Yes, I''ve used COM. No, I don''t like it much.

-fel

Share this post


Link to post
Share on other sites
Yes, I think you are right. But COM is only really useful when implemented in the language level, like in VB6 or C#. So as long as we use C++, we won''t have a wide use of COM.

Tim

--------------------------
glvelocity.gamedev.net
www.gamedev.net/hosted/glvelocity

Share this post


Link to post
Share on other sites
quote:

I think the component object model violates pretty much every principle of true object-oriented programming possible


How so? I think it may violate some - like the lack of multi-interface inheritence.

It''s certainly useful. You can define your COM objects in IDL and ''compile'' them in both MSVC & Delphi to produce .h & unit.pas files automatically. You can write the object implementation in either language and use it with VC, Delphi, and VB.

The biggest two complaints of COM, from what I''ve read, are the lack of standardized RTTI & dependance on the registry. Which are two issues supposedly addressed by COM+.

DirectX is composed of COM objects!

Share this post


Link to post
Share on other sites
I thought that was the one thing it took to the ultimate? the whole "black box reuse" idea (that term is retarded).

er do you mean that the interface is defined seperately from the implentation along with the possiblity (plan) for the same interface to have more than one implementation? neccessary evil, so you don''t break old code.

Share this post


Link to post
Share on other sites
I''m mystified also... There''s nothing inherent in COM that breaks encapsulation. In fact it''s stricter than most because it doesn''t allow public data members. Of course whoever writes the COM object is free to do as lousy a job as then can.

IMHO COM has it''s uses but the idea of building software more or less purely out of components is not going to be really viable for quite a while. The main problem being that each upgrade (or round of fixes) to the component tends to introduce new problems as well as solving old ones. You also have "version hell" problems when multiple versions of the component are floating around.

-Mike

Share this post


Link to post
Share on other sites
You only have version hell if you break the #1 rule of COM. Once you release an interface it can never change .
Or did you mean while debugging it? and trying it out on a bunch of PCs before you release it?

Share this post


Link to post
Share on other sites
COM underlies most fundamental Microsoft architectures right now...

One prominent author wrote, "most likely will have to be a COM programmer in the future to be a Windows programmer."

Edited by - GayleSaver on February 20, 2001 2:27:33 PM

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!