La lliçó anterior va acabar amb un diagnòstic: el domini de BiblioTech ja no es pot corrompre des de fora, però la superfície pública de les seves classes ha crescut sense control. Prestec exposa més de vint mètodes, entre ells un getEmpleatNoUsar() el nom del qual confessa que no hauria d'existir. Encapsular respon la pregunta com amago el que hi ha a dins; queda per respondre la més difícil: què mereix ser a fora. Aquest és el territori de l'abstracció, el quart pilar de la POO i, a diferència dels altres tres, no un mecanisme del llenguatge sinó una disciplina de disseny: quedar-se amb l'essencial per al problema que es resol i descartar tota la resta. Un mapa de metro és una abstracció magistral —menteix sobre les distàncies, ignora la geografia i tanmateix et porta a la teva destinació millor que un plànol a escala—. Aquesta lliçó t'ensenya a dissenyar així: a decidir què exposes, a no barrejar nivells dins d'un mètode, a documentar contractes i a reconèixer tant les abstraccions que degoten com el vici contrari, abstreure el que ningú no ha demanat.

1. L'abstracció com a disciplina de disseny
2. Abstracció enfront d'encapsulament
3. Nivells d'abstracció i per què no s'han de barrejar
4. Refactorització: separar la regla de la presentació
5. Disseny per contracte: precondicions, postcondicions i invariants
6. El vocabulari del domini
7. Separar el què del com
8. API pública mínima i el cost d'exposar de més
9. Abstraccions amb fuites
10. Sobreabstracció i YAGNI
11. Els mecanismes que falten: interfícies i classes abstractes
12. Errors Habituals i Consells
13. Exercicis

Abstreure és quedar-se amb l'essencial i descartar l'accidental. La paraula clau és "per al problema": no existeix l'abstracció correcta en absolut, només la correcta per a un propòsit.

El mateix llibre físic s'abstreu de manera diferent segons qui el modeli:

Cap no és més "vertadera" que una altra. Un Llibre a BiblioTech no té pes perquè a BiblioTech no li importa el pes, i afegir-lo "per si de cas" seria contaminar el model.

D'aquí la primera pregunta que t'has de fer davant de qualsevol classe:

Què necessita saber i fer aquest objecte per al problema que resolem? Tota la resta sobra.

Els dos conceptes es confonen constantment perquè col·laboren, però responen preguntes diferents:

Es pot tenir l'una sense l'altra, i tots dos errors són reals:

• Bon encapsulament, mala abstracció: tots els camps private, però amb trenta getters i setters validats. Res no es corromp, però la classe no significa res; és un full de càlcul amb sintaxi Java.
• Bona abstracció, mal encapsulament: una API pública magnífica —prestar(), retornar(), calcularMulta()— al costat de camps public que permeten saltar-se-la. El disseny és correcte i no es compleix.

Necessites totes dues. L'abstracció decideix quines portes hi ha; l'encapsulament garanteix que no n'hi ha d'altres.

Un programa té capes de detall, del concepte al bit:

La regla, coneguda com a principi de nivell únic d'abstracció:

Dins d'un mateix mètode, totes les sentències haurien de pertànyer aproximadament al mateix nivell.

Per què? Perquè llegir un mètode que salta de nivell obliga a canviar de marc mental a cada línia. Un mètode que diu "registra la devolució, i per cert aquí va la fórmula de l'IVA i l'amplada de columna del rebut" no es pot llegir en diagonal: cal llegir-lo sencer, cada vegada.

Aquest és l'aspecte de la barreja, i probablement en reconeguis l'estil perquè és exactament el del teu main del mòdul 2:

Els problemes concrets, més enllà de l'estètica:

1. No es pot reutilitzar la regla. Si un altre punt del programa necessita la multa, ha de copiar la fórmula o cridar aquest mètode i aguantar el rebut per consola.
2. No es pot provar. Per verificar el càlcul cal capturar la sortida estàndard (mòdul 11).
3. No es pot canviar el canal. Si demà el rebut és una pàgina web o un PDF, cal reescriure la lògica de negoci juntament amb el format.
4. El sostre de 20 € està duplicat. Ja viu a Material.MULTA_MAXIMA, i aquí apareix com a literal. Dues veritats per a un mateix fet.
5. Viola la Llei de Demeter tres vegades amb prestec.getMaterial().getX().

Reescrivim el mètode anterior repartint cada línia al seu nivell.

Nivell 3, regles de negoci: ja són al domini. Prestec.registrarDevolucio(int) calcula la multa, marca el préstec, allibera el material i descompta a l'empleat (lliçó 03-07). No cal escriure res de nou.

Nivell 1, presentació: una classe a part, fora del domini.

Nivell 4, el cas d'ús: coordina, no calcula ni imprimeix.

Dues línies. I cadascuna al seu nivell.

Compara l'abans i el després:

Nota el paquet nou, presentacio. L'estructura de BiblioTech comença a reflectir els seus nivells d'abstracció:

Aquesta separació és la llavor de l'arquitectura per capes que veuràs completa al mòdul 12.

Una abstracció és una promesa: "crida'm així i et retornaré això". Com més explícita sigui la promesa, menys marge hi ha per als malentesos. El disseny per contracte formalitza aquesta promesa en tres parts:

En Java no hi ha sintaxi per als contractes (altres llenguatges sí que en tenen), així que es documenten amb Javadoc, que ja coneixes del mòdul 1:

Avantatges d'escriure-ho:

• Qui crida sap què ha de complir sense llegir la implementació. Això és, literalment, la definició d'abstracció.
• T'obliga a tu, en escriure-ho, a pensar en els casos límit: què passa si ja estava retornat? I si els dies són negatius? Molts contractes revelen forats de disseny abans que existeixin com a errors.
• L'IDE el mostra en autocompletar, així que el contracte viatja amb el codi.

I una guia pràctica sobre precondicions: hi ha dues estratègies, i convé triar conscientment.

Comprovar-ho tot a tot arreu multiplica el codi sense aportar seguretat: si un mètode private només el criden dos mètodes de la mateixa classe que ja van validar, tornar a validar és soroll.

Una bona abstracció parla l'idioma del negoci. Si un bibliotecari de Nexus Software llegís el teu codi per damunt de l'espatlla, hauria de reconèixer les paraules.

Compara:

A la idea de fer servir un únic vocabulari compartit entre el codi, la documentació i les converses amb el negoci se l'anomena llenguatge ubic. La seva regla pràctica és simple: si el negoci diu "multa", el codi diu multa, no penaltyAmount, fee ni charge.

El vocabulari de BiblioTech, que fas servir des del mòdul 1, és exactament això: titol, autor, isbn, disponible, diesRetard, multa, gravetat, referencia, prestar, retornar. Cap paraula tècnica no s'ha colat al domini, i per això prestec.registrarDevolucio(20) s'entén sense obrir la classe.

El resultat tangible d'una bona abstracció és que qui crida deixa de saber com es fan les coses.

Recorre el que ha passat amb el càlcul de la multa al llarg del curs:

La prova definitiva que el què i el com estan separats és aquesta: pots canviar la implementació sense tocar els que criden? Si Nexus Software decideix demà que la tarifa sigui progressiva —0,25 € els set primers dies i 0,50 € a partir del vuitè—, quants fitxers cal tocar?

Un fitxer. Ni main, ni el rebut, ni Prestec se n'assabenten. Això és el que compra l'abstracció, i és la raó per la qual es paga el seu cost en indirecció.

L'API pública d'una classe és tot el que altres poden fer servir: mètodes i camps public, i els seus constructors. És la seva promesa cap a l'exterior.

I aquesta promesa té un cost que gairebé ningú no calcula en escriure el codi:

La regla d'or:

És fàcil afegir un mètode públic més tard; és caríssim treure'l. Davant del dubte, deixa'l private.

Aplicat a Prestec, revisem la seva API actual amb un criteri sever:

Amb aquesta poda, Prestec passa de més de vint membres públics a catorze, i cap no permet descompensar el sistema. L'exercici 1 et demana portar-la fins al final.

Una abstracció amb fuites (leaky abstraction) és la que promet amagar un detall però obliga a conèixer-lo igualment. La llei enunciada per Joel Spolsky diu, amb una mica d'humor negre, que totes les abstraccions no trivials degoten: la qüestió no és evitar-ho del tot, sinó no agreujar-ho.

Exemples que ja has vist o veuràs:

Com reduir les fuites:

• Retorna tipus immutables o còpies en lloc d'estat intern.
• No exposis tipus de la implementació a la signatura pública. Si demà vols canviar un array per una llista, la teva signatura no t'hauria d'obligar a trencar ningú.
• Documenta el que degota quan no ho puguis evitar. Una fuita documentada és un contracte; una fuita silenciosa és un parany.

El vici oposat també existeix, i en mans d'algú que acaba de descobrir la POO és el més freqüent: abstreure el que ningú no ha demanat.

Símptomes de sobreabstracció:

• Jerarquies de cinc nivells per a tres casos concrets.
• Classes anomenades AbstractBaseGenericProcessorFactory.
• Paràmetres de configuració que sempre valen el mateix.
• Punts d'extensió "per si algun dia" que no es fan servir mai.
• Una interfície per a cada classe, amb una única implementació.

El principi que ho conté s'anomena YAGNI: You Aren't Gonna Need It, "no ho necessitaràs". Formulat com a regla:

No afegeixis flexibilitat fins que tinguis dos casos reals que la requereixin. Amb un, és endevinar.

Aplicat a BiblioTech, un contrast honest:

I un advertiment sobre l'equilibri: sobreabstreure és un error car però visible; infraabstreure produeix el main de dues-centes línies del mòdul 2, que també ho és. La resposta professional no és triar un extrem, sinó refactoritzar quan apareix el segon cas. És exactament el que has fet: Material no existia fins que van aparèixer revistes i DVD.

Tota aquesta lliçó ha parlat d'abstracció com a disciplina: què modelar, què exposar, com separar nivells. Però Java ofereix a més dos mecanismes del llenguatge dissenyats específicament per materialitzar-la, i tots dos arriben al mòdul següent:

Dues mancances concretes del disseny actual que aquests mecanismes resoldran:

Primera: Material es pot instanciar. Avui res no impedeix escriure new Material("Alguna cosa", "REF-1", true), i això no significa res: a la biblioteca hi ha llibres, revistes i DVD, no "materials genèrics". Una classe abstracta ho prohibeix a nivell de compilador.

Segona: getTipus() retorna "Material" per defecte. Si algú crea una subclasse nova i oblida sobreescriure'l, apareixerà "Material" als llistats sense que ningú ho detecti. Un mètode abstracte converteix aquest oblit en un error de compilació:

Queda't amb això: al mòdul 4 aprendràs com s'escriuen; en aquesta lliçó has après per què existeixen. L'ordre importa, perquè qui aprèn interface sense haver entès l'abstracció acaba creant una interfície per classe sense saber per a què.

• Confondre abstracció amb encapsulament. Abstracció és què exposo; encapsulament és com ho amago. La taula de l'apartat 2 els separa.
• Barrejar nivells en un mètode. Regles de negoci i printf al mateix bloc és l'error més freqüent en codi de principiant, i el més car de desfer.
• Ficar presentació a les classes de domini. Un Llibre que sap imprimir la seva fitxa per consola no es podrà reutilitzar en un web. La presentació va en un altre paquet.
• Fer públic "per si de cas". Cada mètode públic és un compromís permanent. Comença private i puja només quan algú ho necessiti de debò.
• Noms genèrics. Manager, Processor, Helper, Data, Info, Util. Si no pots posar un nom concret a una classe, probablement encara no saps què és.
• Documentar el com en lloc del què. Un Javadoc que diu "recorre l'array i suma" queda obsolet tan bon punt canviïs la implementació. Documenta el contracte: què rep, què retorna, què garanteix.
• Abstreure sense un segon cas. YAGNI. Espera que aparegui el segon suport, la segona base de dades, el segon format.
• Consell: descriu el mètode en una frase. Si necessites "i" o "a més", el mètode fa dues coses i probablement barreja nivells.
• Consell: llegeix el teu codi com si fossis el bibliotecari. Si p.registrarDevolucio(20) s'entén i dm.process(i, 20) no, ja saps quin està ben anomenat.
• Consell: la prova del canvi. Davant de cada decisió de disseny, pregunta't què caldria tocar si la regla canviés. Com menys fitxers, millor l'abstracció.

Aquest és l'exercici central de la lliçó. Pren la classe Prestec tal com va quedar a 03-07 i redueix la seva superfície pública al mínim necessari.

1. Llista tots els seus membres públics actuals.
2. Per a cadascun, decideix: mantenir, fer private o eliminar, justificant la decisió en una frase.
3. Elimina getEmpleatNoUsar() i substitueix-ne els usos per delegacions adequades.
4. Escriu el Javadoc complet, amb precondicions i postcondicions, dels tres mètodes que consideris el nucli de la classe.
5. Comprova que BiblioTechApp i RebutConsola continuen funcionant amb l'API reduïda.

Refactoritza aquest mètode repartint cada línia al seu nivell. Ha de quedar: les regles al domini, la presentació a RebutConsola i el cas d'ús reduït a tres o quatre línies llegibles.

Per a cada proposta d'un company, decideix si està justificada, si és sobreabstracció (YAGNI) o si és una abstracció amb fuites. Justifica-ho en dues o tres frases i, quan escaigui, proposa l'alternativa.

1. Crear MaterialFisic i MaterialDigital com a nivells intermedis entre Material i les tres classes actuals.
2. Afegir a Material un mètode public String[] getCampsInterns() que retorni l'estat en brut "per depurar".
3. Extreure les quatre constants de negoci a una classe ReglesNegoci amb mètodes static.
4. Afegir a Prestec un paràmetre boolean modeSilencios a registrarDevolucio per no imprimir avisos.

Solució 1

1 i 2. Revisió membre per membre:

3. Substitució dels dos getters eliminats. On abans s'escrivia p.getMaterial().getTipus() o p.getEmpleatNoUsar().getIdentificador(), s'afegeixen delegacions:

Són tres mètodes trivials, i aquesta és l'objecció habitual: "he canviat un getter per tres". La resposta és que ara la classe controla què es pot saber de l'empleat, i ningú no pot cridar registrarPrestec() a la seva esquena. S'ha canviat una porta oberta per tres finestres amb reixa.

4. Javadoc dels tres mètodes nucli:

Fixa't en un detall del tercer: documentar "accepta nuls i respon false" és una decisió de disseny. Sense ella, cada crida hauria de comprovar pel seu compte, o descobrir el comportament a base de NullPointerException.

5. RebutConsola ja feia servir només delegacions (getTitolMaterial(), getNomEmpleat()), així que continua compilant sense canvis. És el senyal que la poda era correcta: el que s'ha eliminat no ho feia servir ningú legítim.

Solució 2

El mètode original barreja quatre nivells: interacció amb l'usuari, validació de regles, creació del préstec i presentació de resultats. Es reparteix així.

Domini. La comprovació combinada ja existeix (Prestec.esPotPrestar) i el venciment el calcula el constructor. No cal afegir regles noves, només un mètode que expliqui per què no es pot prestar:

Presentació. Tot el text, a RebutConsola:

Interacció amb l'usuari. També és presentació, així que la confirmació s'aïlla:

Cas d'ús. Coordina i res més:

Millores aconseguides, més enllà de la longitud:

Solució 3

1. MaterialFisic / MaterialDigital — sobreabstracció (YAGNI). Avui els tres materials del catàleg són físics, així que MaterialDigital no tindria cap subclasse i MaterialFisic no aportaria ni un camp ni un mètode que Material no tingui ja. Afegiria un nivell a la jerarquia —justament el que 03-05 desaconsella— a canvi de res. Alternativa: esperar. El dia que entri un curs en vídeo sota demanda, amb regles pròpies d'accés, s'introdueix el nivell intermedi amb un cas real a la mà.

2. getCampsInterns() — abstracció amb fuites, i de les greus. Un mètode que retorna "l'estat en brut" publica la representació interna com a part de l'API: tan bon punt algú el faci servir en producció "només per a un log", ja no podràs canviar els camps sense trencar-lo. A més convida a analitzar la sortida en lloc de fer servir els mètodes. Alternativa: un toString() ben sobreescrit, que és exactament per a això i s'estudia a la lliçó següent. La depuració es fa amb el depurador (02-05), que veu els camps privats sense necessitat d'exposar-los.

3. Classe ReglesNegoci amb les constants — depèn, i per això és la més interessant. Tal com està formulada, és discutible: les constants ja viuen a Material, que és la classe que les fa servir, i treure-les a un contenidor separat les allunyaria del seu significat; a més getDiesPrestec() i getTarifaDiaria() són polimòrfiques per suport, així que una classe única no les podria representar sense tornar a un switch sobre el tipus, és a dir, desfent el que s'ha aconseguit a 03-06. Sí que estaria justificada si aquests valors s'haguessin de llegir d'un fitxer de configuració o canviar per seu, perquè llavors hi hauria un segon cas real. Avui no n'hi ha. Veredicte: YAGNI, amb data de revisió.

4. Paràmetre boolean modeSilencios — malament per dues raons. La primera és la de l'apartat de bones pràctiques de 03-03: un paràmetre booleà a la crida no diu res (registrarDevolucio(20, true) és il·legible). La segona és més profunda: la seva existència demostra que l'abstracció està trencada, perquè un mètode de domini no hauria d'imprimir res, i per tant no hi hauria d'haver res a silenciar. Alternativa: que registrarDevolucio no escrigui a la consola en absolut i retorni la informació —ho fa, retorna la multa—, deixant que la capa de presentació decideixi què mostrar i quan. El "mode silenciós" desapareix perquè el problema desapareix.

Un patró que convé reconèixer a les quatre respostes: les propostes 2 i 4 són pedaços sobre símptomes; un cop separats els nivells d'abstracció, cap de les dues no té raó de ser.

Has completat els quatre pilars. L'abstracció no és una paraula clau que es tecleja, sinó la disciplina de quedar-se amb l'essencial per al problema, i per això el mateix llibre es modela diferent en una biblioteca, una botiga i una impremta. Saps distingir-la de l'encapsulament —què exposo enfront de com ho amago— i per què necessites totes dues. Has après a detectar i corregir la barreja de nivells d'abstracció, el vici que convertia el teu main del mòdul 2 en un bloc il·legible, separant les regles de negoci al domini, la presentació al seu propi paquet i deixant el cas d'ús en dues línies. Saps escriure contractes en Javadoc amb precondicions, postcondicions i invariants, i triar conscientment entre validar defensivament o documentar i confiar. Modeles amb el vocabulari del domini, de manera que un bibliotecari de Nexus Software reconeixeria el teu codi. Has comprovat que separar el què del com es paga sol: canviar la política de multes a una tarifa progressiva afecta un fitxer. I tens criteri sobre els dos extrems: l'API pública mínima enfront del cost permanent d'exposar de més, les abstraccions amb fuites i el YAGNI que frena les jerarquies inventades per a casos que ningú no ha demanat.

També saps el que falta: els dos mecanismes amb què Java materialitza tot això —interfícies (04-01) i classes abstractes (04-02)— arriben al mòdul següent, i ara sabràs per a què serveixen, que és exactament el que li falta a qui els aprèn abans d'hora.

Queda una lliçó per tancar el mòdul, i és la que fa que els teus objectes es comportin com a ciutadans de primera classe del llenguatge. Ara mateix, imprimir un Llibre produeix un il·legible Llibre@1b6d3586, i dos exemplars amb el mateix ISBN es consideren diferents perquè equals compara adreces de memòria. A La classe Object: equals, hashCode i toString aprendràs el paper de l'arrel de tota la jerarquia, el contracte complet d'equals amb les seves cinc propietats, per què hashCode s'ha de sobreescriure sempre al seu costat i què es trenca si no ho fas. I compliràs la promesa que tanca el mòdul 2: les tres variables soltes retardMesGran, empleatRetardMesGran i llibreRetardMesGran es convertiran per fi en un únic objecte coherent.