CBO coupling between object

Coupling between objects (CBO) is a count of the number of classes that are coupled to a particular class i.e. where the methods of one class call the methods or access the variables of the other. These calls need to be counted in both directions so the CBO of class A is the size of the set of classes that class A references and those classes that reference class A. Since this is a set - each class is counted only once even if the reference operates in both directions i.e. if A references B and B references A, B is only counted once.

This is the definition given here - www.virtualmachinery.com/sidebar3.htm

There is some more detail in the link - as well as an interesting general discussion of the Chidamber and Kemerer metrics - CBO is a part of these metrics.

Here's an example with UML that complements the other answers:

Notes:

• CBO doesn't care about the direction of a dependency. D has a CBO of 1 because C depends on it, even though D depends on no other classes. B and C are similar cases.
• Coupling can be via attributes (composition), associations, local variables, instanciations or injected dependencies (arguments to methods).

Coupling is when a class (A) depends (knows about, requires, uses) on another specific class(B). This means when you change a public member B that is used by A, you have to change A as well. You want low coupling between types, so that you can change classes without many side effects. Usually, coupling 'comes' together with bad encapsulation so you'll have A knowing information that should be private to B.

Some types are generic enough (like List in C#) and you can use them directly without fearing side effects. But whatever classes you define for your own app, you need to be aware that those might change. So in many situations, you are more interested in some behaviour (or attributes) of B, instead of A using the whole B. In those cases, it's better to extract an interface (to abstract the desired behaviour) and then A will know only about an abstraction, while B will implement it. This allows you to have more than one concrete implementation (useful every time you're dealing with things like databases, network, import/export etc) and A won't know about B.

Thus, A can unknowingly use any of B,C,D etc as long as they implement the interface and you can change things in B,C,D as long as this doesn't break the public contract (the interface).

While we usually want our classes to be decoupled, but cohesive (as in to work together), in many situations coupling won't really hurt you, as decoupling might require more effort than provide value. It's up to the developer to identify those situations and to make a proper decision. However, this comes with experience, so in the mean time, just try not to couple your classes too much.