Quan evitar l’acoblament

“Acoblament baix” és un dels principis de disseny de software més àmpliament acceptats (de fet, no crec que poguem trobar cap referència enlloc on algú indiqui que és bó mantenir l’acoblament alt) però si apliquem aquest principi sense cap altre criteri, ens podem trobar [LAR] amb un disseny molt pobre on alguns objectes només actuin com a contenidors de dades (i no tinguin cap acoblament amb altres classes) mentre que altres concentrin tots els acoblaments i totes les responsabilitats del sistema. Per tant, i citant en Larman Some moderate degree of coupling between classes is normal and necessary for creating an object-oriented system in which tasks are fulfilled by a collaboration between connected objects.

Un cop acceptem que és necessari assumir un cert grau d’acoblament al sistema, necessitem establir criteris per a decidir, entre dos acoblaments, quin és més greu per tal de mantenir un bon disseny. El propi Larman ens ofereix algunes pistes a la discussió del patró GRASP: Hem d’evitar l’acoblament cap als elements menys estables o amb més possibilitats d’evolucionar.

Però en Larman no és l’únic autor que ha tractat aquest tema. D’altres, com ara en Robert C. Martin, l’han tractat des del punt de vista de la gestió de dependències. El principi d’inversió de dependències diu que:

• a. Els elements d’alt nivell (d’abstracció) no haurien de dependre dels de baix nivell. Tots dos haurien de dependre d’abstraccions
• b. Les abstraccions no haurien de dependre dels detalls. Els detalls haurien de dependre de les abstraccions

D’aquest principi podriem extreure un altre criteri: Evitar els acoblaments cap a elements de més baix nivell d’abstracció.

Finalment, una tercera variable que hem de tenir en compte és que el concepte d’acoblament depèn de quina sigui la unitat organitzativa que volguem tractar. Per exemple, podem considerar els acoblaments entre classes, entre paquets, mòduls o subsistemes. En Robert C. Martin [MAR] dedica un capítol sencer a la gestió de l’acoblament entre paquets, mentre que altres autors com en Bertrand Meyer [MEY] o en Martin Fowler també tracten el tema de l’acoblament associat al concepte de mòdul o subsistema. Per tant, és molt important gestionar l’acoblament a nivell de paquets.

Recapitulant, doncs, ens trobem amb tres variables o criteris per decidir: La possibilitat de canvis, el nivell d’abstracció i la pertanyença a un mateix paquet. En realitat, però, si hem fet una bona organització de paquets, totes les classes d’un mateix paquet tindran un mateix nivell d’abstracció i, a més, hauran previst el mateix tipus de canvi, de manera que, si hem fet una bona organització de paquets, el criteri principal és evitar els acoblaments cap a classes d’altres paquets, especialment si el seu nivell d’abstracció és més baix que el del paquet de la classe en qüestió ja que son les que ténen més possiblitats de treballar a un nivell d’abstracció diferent o de canviar per motius que poden no haver estat previstos al disseny de la nostra classe.

Significa això que la resta d’acoblaments no s’han d’evitar? Mai. Això només significa que, en termes generals, hem d’evitar, de manera preferent, els acoblaments cap a classes que pertanyin a altres paquets. Per exemple, és una mala decissió afegir un acoblament cap a una classe d’un altre paquet per evitar un acoblament cap a una classe del mateix paquet.

Referències:

[LAR] Craig Larman, Applying Uml and Patterns, 3rd Edition
[MAR] Robert C. Martin, Agile Software Development: Principles, Patterns and Practices
[MEY] Bertrand Meyer, Object Oriented Software Construction