OO versus component design/architecture
-
I'm trying to understand some of the implications of development for .NET versus COM. To me, .NET is well expressed using OO design techniques (as does C++ or Java) whereas COM components are more like applying a list of interfaces on groupings of code. Does anyone know of any web sites that illustrate the differences of how to design systems using OO (classes, inheritance, etc.) versus decomposing systems to various interfaces and COM components. Thanks Dale Thompson
-
I'm trying to understand some of the implications of development for .NET versus COM. To me, .NET is well expressed using OO design techniques (as does C++ or Java) whereas COM components are more like applying a list of interfaces on groupings of code. Does anyone know of any web sites that illustrate the differences of how to design systems using OO (classes, inheritance, etc.) versus decomposing systems to various interfaces and COM components. Thanks Dale Thompson
Actually, Java is more suited to component design than OO design. It lacks multiple inheritance, but supports "applying a list of interfaces on groupings of code" through the interface keyword. When you look at it that way maybe you'll see that there's little difference between the two methodologies. In any event, I believe that .NET supports implementation inheritance, the piece needed for true OO design. So I don't think you're question really applies to .NET any way. William E. Kempf
-
I'm trying to understand some of the implications of development for .NET versus COM. To me, .NET is well expressed using OO design techniques (as does C++ or Java) whereas COM components are more like applying a list of interfaces on groupings of code. Does anyone know of any web sites that illustrate the differences of how to design systems using OO (classes, inheritance, etc.) versus decomposing systems to various interfaces and COM components. Thanks Dale Thompson
To me, .NET represents a kind of "jumping-off" that used COM/COM+/DCOM as its launchpad. It's my perception that COM and .NET are both very component-based. For instance, any objct created in .NET has the choice of exposing several interfaces to itself which are easily published and used by clients through the CLR. .NET though also makes use of OO in forcing formerly non-OO languages to be more object-oriented. For instance, VB.NET is much more OO than is VB 6, and C++, C#, and Java are more similar than ever before. Sincerely Yours, Brian Hart "And that's the news from Lake Wobegon, where all the women are strong, the men are good-looking, and the children are above-average." - Garrison Keillor
-
I'm trying to understand some of the implications of development for .NET versus COM. To me, .NET is well expressed using OO design techniques (as does C++ or Java) whereas COM components are more like applying a list of interfaces on groupings of code. Does anyone know of any web sites that illustrate the differences of how to design systems using OO (classes, inheritance, etc.) versus decomposing systems to various interfaces and COM components. Thanks Dale Thompson
I don't know of any websites but the path that, I venture to say, most C++ developers follow is this: 1. When developing code that will used strictly by C++ modules all built using the same compiler, use the OO approach. In other words, create C++ classes and _declspec(dllexport) them from DLLs to be used/inherited by other C++ DLLs/EXEs. 2. If the code needs to be used by modules written in other languages, such as VB, go with COM components. This typically means writing an ATL wrapper class that exposes a C++ class's methods using COM friendly types (such as BSTR). So you can see that COM is utilized mainly to enable modules to be language-independent. The preferred approach is the OO route, where you can do more than just use code, you can also extend it (via inheritance). As I understand it, .NET gives us both of these advantages so it'll make things easier in that respect. Regards, Alvaro
-
I'm trying to understand some of the implications of development for .NET versus COM. To me, .NET is well expressed using OO design techniques (as does C++ or Java) whereas COM components are more like applying a list of interfaces on groupings of code. Does anyone know of any web sites that illustrate the differences of how to design systems using OO (classes, inheritance, etc.) versus decomposing systems to various interfaces and COM components. Thanks Dale Thompson
Hmm, I think my question was not obvious enough. ;-) I'm looking for information comparing contrasting OO design and COM component design? In referring to OO, I am particularly interested in the Java/.NET style inheritance (or C++ w/o multiple inheritance). I'm not too concerned with this nuance. To me, the bigger deal is that OO design has well defined "interface" relationships (among the members of a class hierarchy, for instance). I'm not very sure how one models the relationships of COM interfaces and the components that support them. Thanks again Dale Thompson
-
Hmm, I think my question was not obvious enough. ;-) I'm looking for information comparing contrasting OO design and COM component design? In referring to OO, I am particularly interested in the Java/.NET style inheritance (or C++ w/o multiple inheritance). I'm not too concerned with this nuance. To me, the bigger deal is that OO design has well defined "interface" relationships (among the members of a class hierarchy, for instance). I'm not very sure how one models the relationships of COM interfaces and the components that support them. Thanks again Dale Thompson
To maybe hint at an answer to your question, all of the resources I've seen that discuss interface inheritance are in books. Something like ATL Internals or Inside ATL go into nitty-gritty about the different COM design patterns for interfaces -- MI, delegation, tear-offs, aggregation, to name a few. However, I think a lot of the "cool" ATL tricks for COM interfaces go away under .NET, because it directly supports aggregation with its single inheritance interface mechanism, which I think MS is assuming will meet 99% of everyone's needs. Of course, .NET's interface inheritance mechanism distinctly borrowed from Java, so you can always look at Gosling's justification of it (vs. C++ multiple inheritance) in the book The Java Language Specification. Another free route is to subscribe to .NET newsgroup (discuss.develop.com) and ask the same question there or do a search on "interface inheritance". You'll find lots of discussion on the topic (especially the SI vs. MI topic)
-
I don't know of any websites but the path that, I venture to say, most C++ developers follow is this: 1. When developing code that will used strictly by C++ modules all built using the same compiler, use the OO approach. In other words, create C++ classes and _declspec(dllexport) them from DLLs to be used/inherited by other C++ DLLs/EXEs. 2. If the code needs to be used by modules written in other languages, such as VB, go with COM components. This typically means writing an ATL wrapper class that exposes a C++ class's methods using COM friendly types (such as BSTR). So you can see that COM is utilized mainly to enable modules to be language-independent. The preferred approach is the OO route, where you can do more than just use code, you can also extend it (via inheritance). As I understand it, .NET gives us both of these advantages so it'll make things easier in that respect. Regards, Alvaro
This theory works until you have to deploy under MTS. I think the general problem with OO is that it simply does not fit well with RDBMS theory, which is prevailing way of buidling databases today. OO works very well for some areas (such as CAD, GIS, etc.) but fails miserably when it comes to databases. Many OO->RDBMS mapping techniques end up in code bloats (complexity is the mother of all defects), fragile cache mechanisms, unconventional solutions... So I think a decision between components and objects is (as so many things in software engineering) dictated by problem you are trying to solve. If your company basis is MS Windows and you are creating integration system you'll build easy to use middleware components, which, if not performance or transaction critical, can act as you proposed (as a facade to underlying systems). For e-commerce systems, transactioned components are law (MTS). For diagramming application or workflow application, OO is preferred selection. This implies the conclusion, that components will be much more wide spread because the majority of produced software today are enterprise integrations. Regards, Tomaz
-
Hmm, I think my question was not obvious enough. ;-) I'm looking for information comparing contrasting OO design and COM component design? In referring to OO, I am particularly interested in the Java/.NET style inheritance (or C++ w/o multiple inheritance). I'm not too concerned with this nuance. To me, the bigger deal is that OO design has well defined "interface" relationships (among the members of a class hierarchy, for instance). I'm not very sure how one models the relationships of COM interfaces and the components that support them. Thanks again Dale Thompson
> I'm looking for information comparing contrasting OO design and COM component design? Cetus links could be a good starting point for this kind of information. They have over 18,000 links on objects & components. Sascha
-
To maybe hint at an answer to your question, all of the resources I've seen that discuss interface inheritance are in books. Something like ATL Internals or Inside ATL go into nitty-gritty about the different COM design patterns for interfaces -- MI, delegation, tear-offs, aggregation, to name a few. However, I think a lot of the "cool" ATL tricks for COM interfaces go away under .NET, because it directly supports aggregation with its single inheritance interface mechanism, which I think MS is assuming will meet 99% of everyone's needs. Of course, .NET's interface inheritance mechanism distinctly borrowed from Java, so you can always look at Gosling's justification of it (vs. C++ multiple inheritance) in the book The Java Language Specification. Another free route is to subscribe to .NET newsgroup (discuss.develop.com) and ask the same question there or do a search on "interface inheritance". You'll find lots of discussion on the topic (especially the SI vs. MI topic)
-
Hmm, I think my question was not obvious enough. ;-) I'm looking for information comparing contrasting OO design and COM component design? In referring to OO, I am particularly interested in the Java/.NET style inheritance (or C++ w/o multiple inheritance). I'm not too concerned with this nuance. To me, the bigger deal is that OO design has well defined "interface" relationships (among the members of a class hierarchy, for instance). I'm not very sure how one models the relationships of COM interfaces and the components that support them. Thanks again Dale Thompson
Actually, I did find a post on the ATL newsgroup referring to a collection of online info about OO vs. components. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0106b&L=atl&D=0&P=13446
