what is collaborations in c++

[nihaS]

hi
I m new here and not sure about how things go about...
but could any one tell me about collaborations of objects in c++

[Ancient Dragon]

Depends on what you are talking about. Here is one explanation.

[rubberman]

Since you are in the C++ forum, I assume it is collaboration, as in CRC. Here is an article from the wikipedia about that: http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

[nihaS]

Depends on what you are talking about. Here is one explanation.

hey thank you...
but from the bits and pieces i had heard its like using parts of objects from different classes n making a new object...
is it true??
if you know anything about it could you please explain it!

[Ancient Dragon]

I have no idea -- never heard of the term, for whatever that's worth.

[mike_2000_17]

This, to my knowledge, is not a particularly common pattern, especially in OOP. It is, however, somewhat ubiquitous in Generic Programming (which can be used alongside OOP).

In OOP, I think they are mostly referred to as mixins (as in, mixing in different classes to make a sort-of bast_ard superclass). Read more.

As for the term collaborations, I think it is not very much used (I had never heard it, as an OOP design pattern, at least). And googling for it yields too much lexical pollution problem with other more common use of the word "collaboration" in OOP and C++ programming, for example, Collaboration Diagrams (as pointed out by rubberman) or just general non-technical use of the word "collaboration". But I did find this little article that seem to refer to it as a technical term and provides a basic explanation of it (and it basically equates it to the concept of mixins).

To explain it, the basic idea is to create some classes that are not really fully function or useful by themselves but implement just one particular feature. Then, by assembling a set of such simple, "incomplete" classes together, you can make a complete one. The simplest example I can think of is the non_copyable class (part of Boost for example). Say I have this simple class:

class non_copyable {
  private:
    non_copyable(const non_copyable&);
    non_copyable& operator=(const non_copyable&);
};

Because both the copy-constructor and assignment operator are private and are not supplied with an implementation, this class is non-copyable (i.e. an object of this class cannot be copied or assigned to another object). This is a very useful idiom for many cases in OOP where it does not make any sense to copy a class. Now, the above "non_copyable" class is useless by itself (it is just an empty class, without even any virtual methods), however, if you derive a class from it, you will mix-in the feature of non-copyability to the derived class without having to declare those special private functions. As in:

class my_singleton : public non_copyable {
  //...
};

In the above case, the my_singleton class inherits the non-copyable property of its base class. But notice that the non_copyable class is not a base class in the traditional OOP sense (i.e. a class that defines common functionality, common data members, and/or virtual member functions).

In OOP, this pattern is not, I think, all that useful because generally it is difficult to do in a useful way, and can become clumsy otherwise. Typically, composition is better suited for joining several objects together to create a superclass that combines their functionality. And in cases where (multiple) inheritance is useful, it typically is regarded as just normal OOP class hierarchies.

However, in the realm of Generic Programming, using templates, this idiom can be much better utilised. Consider, for example, the curiously recurring template pattern (CRTP), which is extensively used in Generic Programming, alongside OOP.

[rubberman]

Ah, CRTP - been there, done that, didn't know what it was called... :-) As usual Mike has a huge base of useful knowledge! :-) Mixins I'm familiar with, and that can also be a very useful pattern, but easily misused.