10.5 — Dependencies

So far, we’ve explored 3 types of relationships: composition, aggregation, and association. We’ve saved the simplest one for last: dependencies.

In casual conversation, we use the term dependency to indicate that an object is reliant upon another object for a given task. For example, if you break your foot, you are dependent on crutches to get around (but not otherwise). Flowers are dependent upon bees to pollinate them, in order to grow fruit or propagate (but not otherwise).

A dependency occurs when one object invokes another object’s functionality in order to accomplish some specific task. This is a weaker relationship than an association, but still, any change to the dependent object may break functionality in the caller. A dependency is always a unidirectional relationship.

A good example of a dependency that you’ve already seen many times is std::cout (of type std::ostream). Our classes that use std::cout use it in order to accomplish the task of printing something to the console, but not otherwise.

For example:

In the above code, Point isn’t directly related to std::cout, but it has a dependency on std::cout since operator<< uses std::cout to print the Point to the console.

Dependencies vs Association in C++

There’s typically some confusion about what differentiates a dependency from an association.

In C++, associations are a relationship between two classes at the class level. That is, one class keeps a direct or indirect “link” to the associated class as a member. For example, a Doctor class has an array of pointers to its Patients as a member. You can always ask the Doctor who its patients are. The Driver class holds the id of the Car the driver object owns as an integer member. The Driver always knows what Car is associated with it.

Dependencies typically are not represented at the class level -- that is, the dependent object is not linked as a member. Rather, the dependent object is typically instantiated as needed (like opening a file to write data to), or passed into a function as a parameter (like std::ostream in the overloaded operator<< above).

Humor break

Dependencies (courtesy of our friends at xkcd):

Of course, you and I know that this actually a reflexive association!

10.6 -- Container classes
10.4 -- Association

5 comments to 10.5 — Dependencies

  • daniel

    when you say

    outside of the class and don’t mention Point::std::ostream, how does compiler know its the operator overload for point class.
    what if there is more than one class and both have this kind of overload ?

    • Alex

      There is no such thing as Point::std::ostream. I’ll presume you meant Point::operator<<. What happens is when you do something like this:

      C++ tries to match this to a function. It'll try to see if there is a std::ostream::operator<<(Point) function, but there obviously won't be. Next it checks for an operator<<(std::ostream, Point). It will find our overloaded operator definition and match to that. Note that in a binary operator, the left hand side operand always becomes the implicit object, so there's never any ambiguity about which class to look in. For non-member functions, the left hand side operand becomes the first parameter and the right hand side operator becomes the second, so there's also no ambiguity here.

  • Matt

    Typo in section "Dependencies vs Association in C++"… second paragraph, second sentence. I think "a a" should be "as a".

  • daniel

    Thank you for this great tutorial.
    I found one typo: There should be a verb "IS" in the last sentence.

    Of course, you and I know that this "IS" actually a reflexive association!

Leave a Comment

Put C++ code inside [code][/code] tags to use the syntax highlighter