I just started playing with COM. Like my fellow C/C++ programmers I found COM ugly for many practical reasons, until the moment I've read this and this. If COM is all about interoperability, it makes sense that COM should remain at the border-edge of any implementation. I think this would be a good practice.
However, I discussed with a the guy how implemented a piece of code I'm working on (to investigate a heap corruption issue). And he didn't seem to approve the concept of putting COM on the edge. He still enumerates the benefits of providing COM interfaces for all and any. So,
Is it really a bad design to put COM everywhere in an implementation?
PS: In the implementation I'm working on, every thing is COM server. There are: ComNode, ComProperty, ComString, and even ComReal and ComInteger.
Related
I am having a tough time figuring out when I should use COM. I have done some reading but I simply cannot find a solid use-case for using it...I have browsed the internet trying to figure out when and why I should use it but the concept is simply too abstract and I don't understand it.
I get how using COM is interesting when it comes to writing code which can be consumed from various programming languages that support COM (What is the Component Object Model (COM)? Is it language-dependent?). But I would love to get a few solid examples of when COM was used and why it couldn't have been done realisticaly in another way.
Could someone list a few solid / real-world examples where using COM makes more sense that writing a DLL
which exports functionality through traditional functions if you put aside the multi-language aspect of COM ?
I know for instance that COM is used heavily in development which gravitates around Microsoft Office products...Why is this ?
I knew here is a link which discussed a bit about the difference between COM and XPCOM.
What is XPCOM? XPCOM vs COM?
however, I want to know this topic in more detail way.
For example, for reference counting and type inference, COM inherited from IUnknown, XPCOM inherited from nsISupport. What's the difference between IUnkown and nsISupoort except naming?
Further, Do these two different components support different threading management or memory management? Topics like this are really interested to me.
Please reply this post if you know any.
Thanks
What's the difference between IUnkown and nsISupoort except naming?
None, really. nsISupoort was specifically designed to be binary-compatible with IUnknown, to make it easier for FireFox to host ActiveX controls, and to be itself exposed as an ActiveX control.
Do these two different components support different threading management or memory management?
Yes. XPCOM uses its own memory allocator (nsMemory::Alloc et al), completely independent of COM allocator (CoTaskMemAlloc et al). COM provides an extensive set of threading models as well as marshaling support. XPCOM barely deals with threads at all (see nsIProxyObjectManager), and has no notion of marshaling.
Warning: this information may very well be obsolete. My familiarity with the state of Mozilla development is current as of 2010 or so.
I understand the pros and cons of using object oriented programming as a concept. What I'm looking for are the pros and cons of using oo in progress/openedge specifically. Are there challenges that I need to take into account? Are there parts of the language that don't mesh well with oo? Stuff like that.
Edit: using 10.2b
I'll give you my opinion, but be forewarned that I'm probably the biggest Progress hater out there. ;) That said, I have written several medium-sized projects in OOABL so I have some experience in the area. These are some things I wrote, just so you know I'm not talking out of my hat:
STOMP protocol framework for clients and servers
a simple ORM mimicking ActiveRecord
an ABL compiler interface for the organization I was at (backend and frontend)
a library for building up Excel and Word documents (serializing them using the MS Office 2003 XML schemas; none of that silly COM stuff)
an email client that could send emails using multiple strategies
OOABL Pros:
If you absolutely must write Progress code, it is a great option for creating reusable code.
Great way to clean up an existing procedural codebase
OOABL Cons:
Class hierarchies are limited; you can’t create inherited (sub-)
interfaces in 10.2B (I think this was going to be added in 11). Older
versions of OpenEdge have other limitations like lack of abstract
classes. This limits your ability to create clean OO design and will
hurt you when you start building non-trivial things.
Error handling sucks - CATCH/THROW doesn’t let you throw your custom
errors and force callers to catch them. Backwards compatibility
prevents this from evolving further so I doubt it will ever improve.
Object memory footprint is large, and there are no AVM debugging
tools to track down why (gotta love these closed systems!)
Garbage collection wasn’t existent ‘til 10.2A, and still
has some bugs even in 11 (see official OE forum for some examples)
Network programming (with sockets) is a PITA - you have to run a
separate persistent procedure to manage the socket. I think evented
programming in OOABL was a PITA in general; I remember getting a lot
of errors about “windowed environments” or something to that effect
when trying to use them. PUBLISH/SUBSCRIBE didn’t work either,
if memory serves.
Depending on your environment, code reviews may be difficult as most
Progress developers don’t do OOABL so may not understand your code
If above point is true, you may face active resistance from
entrenched developers who feel threatened by having to learn new
things
OO is all about building small, reusable pieces that can be combined to make a greater whole. A big problem with OOABL is that the “ABL” part drags you down with its coarse data structures and lack of enumerators, which prevent you from really being able to build truly beautiful things with it. Unfortunately, since it is a closed language you can’t just sidestep the hand you’re dealt and create your own new data or control structures for it externally.
Now, it is theoretically possible to try and build some of these things using MEMPTRs, fixed arrays (EXTENT), and maybe WORK-TABLEs. However, I had attempted this in 10.1C and the design fell apart due to the lack of interface inheritance and abstract classes, and as I expected, performance was quite bad. The latter part may just be due to my poor ability, but I suspect it's an implementation limitation that would be nigh impossible to surmount.
The bottom line is use OOABL if you absolutely must be coding in OpenEdge - it’s better than procedural ABL and the rough edges get slightly smoother after each iterative release of OpenEdge. However, it will never be a beautiful language (OO or otherwise).
If you want to learn proper object-oriented programming and aren’t constricted to ABL, I would highly recommend looking at a language that treats objects as a first-class citizen such as Ruby or Smalltalk.
In the last four years I have worked 80% of the time with OOABL (started with 10.1c).
I definitely recommend using OOABL but I think it is very important to consider that using OOABL the same way as in other OO languages is fraught with problems.
With "the same way" I mean design patterns and implementation practices that are common in the oo world. Also some types of applications, especially in the area of technical frameworks are hard to do with OpenEdge (e.g. ORM).
The causes are performance problems with OOABL and missing OO features in the language.
If you are programming in C# or Java for exampe, memory footprint and instantiation time of objects are not a big issue in many cases. Using ABL this becomes a big issue much more often.
This leads to other design decisions and prevents the implementation of some patterns and frameworks.
Some missing or bad OO features:
No class library, no data structures needed for oo
No package visibility as in java (internal in c#)
This becomes relevant especially in larger applications
No Generics
Really terrible Exception Handling
Very limited reflection capabilities (improved in oe11)
So if you are familiar with oo programming in other languages and start working with OOABL, you could reach a point at which you were missing a lot of things you expect to be there, and get frustrated when trying to implement such things in ABL.
If your application has to run on Windows only, it is also possible to implement new oo code in C# and call it from your existing progress code via clr bridge, which works very smoothly.
K+
Only one thing - "Error handling sucks" - it sucks, but not because you can not make your own error-classes a catch them in caller block - that works, I'm using that. What sucks is that mix from old NO-ERROR / ERROR-HANDLE option and Progress.Lang.Error / CATCH block and ROUTINE-LEVEL ON ERROR UNDO, THROW. That is a big problem, when exists no convention in team, which errorhandling and how will be used.
I asked this question about Microsoft .NET Libraries and the complexity of its source code. From what I'm reading, writing general purpose libraries and writing applications can be two different things. When writing libraries, you have to think about the client who could literally be everyone (supposing I release the library for use in the general public).
What kind of practices or theories or techniques are useful when learning to write libraries? Where do you learn to write code like the one in the .NET library? This looks like a "black art" which I don't know too much about.
That's a pretty subjective question, but here's on objective answer. The Framework Design Guidelines book (be sure to get the 2nd edition) is a very good book about how to write effective class libraries. The content is very good and the often dissenting annotations are thought-provoking. Every shop should have a copy of this book available.
You definitely need to watch Josh Bloch in his presentation How to Design a Good API & Why it Matters (1h 9m long). He is a Java guru but library design and object orientation are universal.
One piece of advice often ignored by library authors is to internalize costs. If something is hard to do, the library should do it. Too often I've seen the authors of a library push something hard onto the consumers of the API rather than solving it themselves. Instead, look for the hardest things and make sure the library does them or at least makes them very easy.
I will be paraphrasing from Effective C++ by Scott Meyers, which I have found to be the best advice I got:
Adhere to the principle of least astonishment: strive to provide classes whose operators and functions have a natural syntax and an intuitive semantics. Preserve consistency with the behavior of the built-in types: when in doubt, do as the ints do.
Recognize that anything somebody can do, they will do. They'll throw exceptions, they'll assign objects to themselves, they'll use objects before giving them values, they'll give objects values and never use them, they'll give them huge values, they'll give them tiny values, they'll give them null values. In general, if it will compile, somebody will do it. As a result, make your classes easy to use correctly and hard to use incorrectly. Accept that clients will make mistakes, and design your classes so you can prevent, detect, or correct such errors.
Strive for portable code. It's not much harder to write portable programs than to write unportable ones, and only rarely will the difference in performance be significant enough to justify unportable constructs.
Even programs designed for custom hardware often end up being ported, because stock hardware generally achieves an equivalent level of performance within a few years. Writing portable code allows you to switch platforms easily, to enlarge your client base, and to brag about supporting open systems. It also makes it easier to recover if you bet wrong in the operating system sweepstakes.
Design your code so that when changes are necessary, the impact is localized. Encapsulate as much as you can; make implementation details private.
Edit: I just noticed I very nearly duplicated what cherouvim had posted; sorry about that! But turns out we're linking to different speeches by Bloch, even if the subject is exactly the same. (cherouvim linked to a December 2005 talk, I to January 2007 one.) Well, I'll leave this answer here — you're probably best off by watching both and seeing how his message and way of presenting it has evolved :)
FWIW, I'd like to point to this Google Tech Talk by Joshua Bloch, who is a greatly respected guy in the Java world, and someone who has given speeches and written extensively on API design. (Oh, and designed some exceptionally good general purpose libraries, like the Java Collections Framework!)
Joshua Bloch, Google Tech Talks, January 24, 2007:
"How To Design A Good API and Why it
Matters" (the video is about 1 hour long)
You can also read many of the same ideas in his article Bumper-Sticker API Design (but I still recommend watching the presentation!)
(Seeing you come from the .NET side, I hope you don't let his Java background get in the way too much :-) This really is not Java-specific for the most part.)
Edit: Here's another 1½ minute bit of wisdom by Josh Bloch on why writing libraries is hard, and why it's still worth putting effort in it (economies of scale) — in a response to a question wondering, basically, "how hard can it be". (Part of a presentation about the Google Collections library, which is also totally worth watching, but more Java-centric.)
Krzysztof Cwalina's blog is a good starting place. His book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, is probably the definitive work for .NET library design best practices.
http://blogs.msdn.com/kcwalina/
The number one rule is to treat API design just like UI design: gather information about how your users really use your UI/API, what they find helpful and what gets in their way. Use that information to improve the design. Start with users who can put up with API churn and gradually stabilize the API as it matures.
I wrote a few notes about what I've learned about API design here: http://www.natpryce.com/articles/000732.html
I'd start looking more into design patterns. You'll probably not going to find much use for some of them, but as you get deeper into your library design the patterns will become more applicable. I'd also pick up a copy of NDepend - a great code measuring utility which may help you decouple things better. You can use .NET libraries as an example, but, personally, i don't find them to be great design examples mostly due to their complexities. Also, start looking at some open source projects to see how they're layered and structured.
A couple of separate points:
The .NET Framework isn't a class library. It's a Framework. It's a set of types meant to not only provide functionality, but to be extended by your own code. For instance, it does provide you with the Stream abstract class, and with concrete implementations like the NetworkStream class, but it also provides you the WebRequest class and the means to extend it, so that WebRequest.Create("myschema://host/more") can produce an instance of your own class deriving from WebRequest, which can have its own GetResponse method returning its own class derived from WebResponse, such that calling GetResponseStream will return your own class derived from Stream!
And your callers will not need to know this is going on behind the scenes!
A separate point is that for most developers, creating a reusable library is not, and should not be the goal. The goal should be to write the code necessary to meet requirements. In the process, reusable code may be found. In that case, it should be refactored out into a separate library, where it can be reused in the future.
I go further than that (when permitted). I will usually wait until I find two pieces of code that actually do the same thing, or which overlap. Presumably both pieces of code have passed all their unit tests. I will then factor out the common code into a separate class library and run all the unit tests again. Assuming that they still pass, I've begun the creation of some reusable code that works (since the unit tests still pass).
This is in contrast to a lesson I learned in school, when the result of an entire project was a beautiful reusable library - with no code to reuse it.
(Of course, I'm sure it would have worked if any code had used it...)
Lately I'm hearing much about COM at my work. I also learnt that COM is old. COM is deprecated. There is no future for COM. Are these true too?
I want to learn COM because I want to know what is the big fuss about it, but I'm unable to convince myself that this is a solid reason for spending so much time and learning it.
So, Can any one tell me:
Why should I learn COM?
Once I learn COM what can I do using it? I mean its applications.
I just don't see COM going away any time soon. If you want to be a windows expert, you must understand how it works.
Learning COM (or at least being au fait with its concepts) means you can integrate with thousands of existing components, including Microsoft Word and Excel.
I work largely in the Java domain, but having a little knowledge of COM means I can interface effectively to Word and Excel (in particular) to programatically create/read documents. I don't have an in depth knowledge, but I have a little, and having that increases my productivity substantially.
You should learn enough about COM to know that you don't want to learn any more.
The details of COM - particularly from a multithreaded or C++ application - are excruciatingly irritating, and I would not wish them on anyone (I don't know them myself, but I know enough to know this).
Therefore if you do need to call a COM library, you should learn enough COM to be able to do so, then stop. Ideally, use a language such as C# or Delphi where some (or hopefully most) of the details are handled for you relatively transparently.
There are a lot of COM libraries around, but if you feel you want to use one, you should look at its specific documentation for how to do this - it probably has a reasonable example that you can simply adapt for your own use without too much effort. If it does not, then it clearly isn't very good and shouldn't be used.
COM is definitely worth learning to at least some level if you are a Windows developer. Another common case for its use, in addition to the others already mentioned, is in the implementation of binary behaviors and BHOs for Internet Explorer. They are both implemented using COM interfaces between IE and your code.
I'd also like to recommend a couple of resources for learning about COM:
Don Box's Essential COM. It is an excellent description of why COM is the way it is and really helps you get a deeper understanding of what is going on. If you take the time to read this book, then you will have a fundamental understanding of COM internals that will serve you very well.
These two articles: { 1, 2 } ...are a very good discussion of the particular subject of COM apartments, alluded to as "excruciatingly irritating" (unfairly, imho) in MarkR's answer.