Solución:
El acoplamiento entre objetos (CBO) es un recuento del número de clases que están acopladas a una clase en particular, es decir, donde los métodos de una clase llaman a los métodos o acceden a las variables de la otra. Estas llamadas deben contarse en ambas direcciones, por lo que el CBO de la clase A es el tamaño del conjunto de clases a las que hace referencia la clase A y las clases que hacen referencia a la clase A. Dado que se trata de un conjunto, cada clase se cuenta solo una vez, incluso si el la referencia opera en ambas direcciones, es decir, si A hace referencia a B y B hace referencia a A, B sólo se cuenta una vez.
Esta es la definición dada aquí – www.virtualmachinery.com/sidebar3.htm
Hay más detalles en el enlace, así como una interesante discusión general de las métricas de Chidamber y Kemerer, CBO es parte de estas métricas.
Aquí hay un ejemplo con UML que complementa las otras respuestas:
Notas:
- A la CBO no le importa la dirección de una dependencia. D tiene un CBO de 1 porque C depende de él, aunque D no depende de otras clases. B y C son casos similares.
- El acoplamiento puede ser a través de atributos (composición), asociaciones, variables locales, instanciaciones o dependencias inyectadas (argumentos a métodos).
El acoplamiento es cuando una clase (A) depende (conoce, requiere, usa) de otra clase específica (B). Esto significa que cuando cambia un miembro público B utilizado por A, también debe cambiar A. Desea un bajo acoplamiento entre tipos, de modo que pueda cambiar de clase sin muchos efectos secundarios. Por lo general, el acoplamiento “ viene ” junto con una encapsulación incorrecta, por lo que tendrá A información de conocimiento que debería ser privada para B.
Algunos tipos son lo suficientemente genéricos (como List en C #) y puede usarlos directamente sin temer efectos secundarios. Pero independientemente de las clases que defina para su propia aplicación, debe tener en cuenta que pueden cambiar. Entonces, en muchas situaciones, está más interesado en algún comportamiento (o atributos) de B, en lugar de A usando todo el B. En esos casos, es mejor extraer una interfaz (para abstraer el comportamiento deseado) y entonces A sabrá solo sobre una abstracción, mientras que B la implementará. Esto le permite tener más de una implementación concreta (útil cada vez que se trata de cosas como bases de datos, red, importación / exportación, etc.) y A no sabrá acerca de B.
Por lo tanto, A puede usar sin saberlo B, C, D, etc., siempre que implementen la interfaz y usted pueda cambiar cosas en B, C, D siempre que esto no rompa el contrato público (la interfaz).
Si bien generalmente queremos que nuestras clases estén desacopladas, pero cohesivas (como en trabajar juntas), en muchas situaciones, el acoplamiento no te hará daño, ya que el desacoplamiento puede requerir más esfuerzo que proporcionar valor. Depende del desarrollador identificar esas situaciones y tomar una decisión adecuada. Sin embargo, esto viene con la experiencia, así que mientras tanto, trata de no combinar demasiado tus clases.