En tancar el mòdul 2 vas fer un diagnòstic incòmode del teu propi programa: retardMesGran, empleatRetardMesGran i llibreRetardMesGran són tres variables soltes que descriuen una sola cosa, i res no impedeix actualitzar-ne una i oblidar les altres dues. Aquest diagnòstic no és un detall d'estil: és el símptoma d'un límit estructural de l'estil de programació que has fet servir fins ara. Un programa procedimental organitza el codi en passos; quan els passos creixen, les dades relacionades es dispersen per variables independents i ningú no garanteix que continuïn essent coherents entre si. La programació orientada a objectes (POO) proposa una altra organització: agrupar les dades amb les operacions que les governen, en unitats anomenades objectes, de manera que una dada incoherent sigui impossible de construir. Aquesta lliçó encara no escriu la classe Llibre —això arriba a la següent—; la seva feina és que entenguis quin problema resol la POO, amb quin vocabulari es pensa i com es modela el domini de BiblioTech abans de teclejar una sola clau.

1. El punt de partida: BiblioTechApp 2.0 vista de prop
2. Per què el codi procedimental es degrada en créixer
3. Què és l'orientació a objectes
4. Classe enfront d'objecte: el plànol i la casa
5. Identitat, estat i comportament
6. Instància i referència
7. Els quatre pilars d'un cop d'ull
8. Modelar el domini: dels substantius a les classes
9. El model objectiu de BiblioTech
10. Relacions entre classes: associació, composició i agregació
11. Avantatges reals de la POO... i els seus costos
12. Errors Habituals i Consells
13. Exercicis

La teva aplicació funciona. Mostra un menú, valida entrades, aplica les regles de negoci de Nexus Software i emet rebuts alineats. Però mira el bloc de declaracions amb què arrenca main:

Compta el que hi ha: vint variables en el mateix àmbit, totes visibles des de qualsevol punt de les dues-centes línies de main, totes modificables des de qualsevol punt, i cap relació explícita entre elles. El compilador no sap que titol i isbn descriuen el mateix llibre. No sap que retardMesGran i empleatRetardMesGran han de canviar alhora. No sap que multa mai no pot superar MULTA_MAXIMA. Tot això viu al teu cap i als comentaris.

L'estil procedimental —dades per una banda, passos per l'altra— funciona perfectament en programes petits. El problema apareix quan el programa creix, i es manifesta sempre de les mateixes quatre maneres:

El quart símptoma és el més revelador. Pregunta't com registraries dues devolucions simultànies amb el disseny actual. La resposta honesta és: duplicant variables. I amb tres, triplicant-les. Aquest camí no porta enlloc.

A l'esquerra, dades i funcions es creuen en totes direccions. A la dreta, cada dada viu dins de la unitat que sap què fer-ne.

La POO és un paradigma: una manera d'organitzar un programa. La seva idea central cap en una frase:

Un programa és un conjunt d'objectes que col·laboren enviant-se missatges; cada objecte guarda les seves pròpies dades i és l'únic responsable de les operacions que les modifiquen.

Tres conseqüències immediates:

• Les dades deixen de ser passives. Un Prestec no és una tupla de valors que algú inspecciona des de fora; és una entitat a qui preguntes quanta multa correspon.
• Les regles viuen al costat de les dades que governen. La regla "la multa mai no supera 20 €" passa a ser un assumpte intern de Prestec, no una línia perduda dins de main.
• El programa es llegeix amb el vocabulari del negoci. prestec.calcularMulta() s'entén sense conèixer la implementació; multa = diesRetard * TARIFA_DIARIA; if (multa >= MULTA_MAXIMA) multa = MULTA_MAXIMA; obliga a llegir aritmètica per deduir-ne la intenció.

Java és un llenguatge orientat a objectes per disseny: llevat dels vuit tipus primitius que vas veure al mòdul 1, tot el que has manipulat ja era un objecte. String, Scanner o System.out són objectes; scanner.nextLine() és exactament un missatge enviat a un objecte. Fa dos mòduls que fas servir POO sense saber-ho; el que comença ara és escriure els teus propis tipus.

Aquesta és la distinció fonamental, i convé fixar-la amb una analogia abans de veure sintaxi.

Una classe és un plànol d'arquitecte: descriu què tindrà cada casa (nombre d'habitacions, superfície) i què s'hi podrà fer (obrir la porta, encendre el llum). El plànol no és una casa: no hi pots viure, no té adreça postal i no es pot pintar de blau.

Un objecte és una casa construïda a partir d'aquest plànol: ocupa un lloc concret, té valors concrets (140 m², pintada de blau) i es pot fer servir. Del mateix plànol se'n construeixen mil cases, totes amb la mateixa estructura i cadascuna amb els seus propis valors.

Traduït al domini: escriuràs una classe Llibre i hi crearàs tres objectes, un per a "Java Eficaç" (ISBN 978-0000000001), un altre per a "Patrons de Disseny" (978-0000000002) i un altre per a "Refactorització" (978-0000000003). Els tres comparteixen estructura —tots tenen títol, autor, ISBN, any i disponibilitat— i difereixen en els valors.

Tot objecte es descriu amb tres propietats. Interioritzar-les t'estalviarà confusions durant tot el mòdul.

• Identitat: quin objecte és, amb independència dels seus valors. Dos exemplars físics de "Java Eficaç" al prestatge són objectes diferents encara que comparteixin títol i ISBN. En Java la identitat és la posició en memòria, i és el que compara == (ho vas veure al mòdul 1 amb el string pool, i tornarà a 03-09).
• Estat: els valors que l'objecte guarda en un instant. L'estat d'un Llibre inclou titol, autor, isbn, anyPublicacio i disponible. L'estat canvia: disponible passa de true a false quan algú se l'emporta.
• Comportament: les operacions que l'objecte sap fer. Un Prestec sap calcular els seus dies de retard, la seva multa i la seva gravetat.

Aplicat al vocabulari que ja utilitzes:

Fixa't en un detall que governarà tot el mòdul: la columna de la dreta és el que avui està solt dins de main. La POO no inventa comportament nou; el muda de lloc, del procediment a l'objecte que li correspon.

Dues paraules que sentiràs constantment i que convé separar des d'ara:

• Instància és sinònim d'objecte: l'exemplar concret creat a partir d'una classe. "Crear una instància de Llibre" i "crear un objecte Llibre" volen dir el mateix.
• Referència és la variable amb què arribes a aquest objecte. No és l'objecte: és l'adreça on viu.

La distinció importa perquè en Java mai no manipules objectes directament, sempre a través de referències. Quan escrius:

passen tres coses independents: es reserva memòria per a un objecte Llibre al heap (al mòdul 1 en dèiem "monticle"), es declara una variable javaEficac a la pila, i es guarda en aquesta variable l'adreça de l'objecte. Una conseqüència immediata, que la lliçó 03-02 desenvolupa amb detall: dues referències poden apuntar al mateix objecte, i llavors un canvi fet a través d'una es veu a través de l'altra.

La POO se sosté sobre quatre idees. Aquí les tens en una frase cadascuna, amb la lliçó on es desenvolupen; no intentis dominar-les ara, només reconèixer-ne els noms quan apareguin.

Un apunt d'honestedat: aquests quatre termes es reciten molt i s'entenen poc. Al final del mòdul no els hauràs memoritzat, els hauràs fet servir, que és l'única manera d'aprendre'ls.

Abans d'escriure codi cal decidir quines classes existeixen. Hi ha una tècnica senzilla i sorprenentment eficaç per començar: subratllar els substantius de l'enunciat del problema. Aquest és l'enunciat de BiblioTech tal com el donaria el departament de Nexus Software:

La biblioteca tècnica interna gestiona els llibres que els empleats prenen en préstec. Cada llibre té títol, autor, ISBN i any de publicació, i pot estar disponible o no. Un préstec dura 15 dies; passat aquest termini s'acumulen dies de retard que generen una multa de 0,25 € diaris amb un màxim de 20 €. Un retard de fins a 7 dies es considera lleu; per damunt, greu.

Substantius candidats: biblioteca, llibre, empleat, préstec, títol, autor, ISBN, any, dies, multa, retard.

Ara es filtren amb tres criteris:

1. Té identitat pròpia i estat que canvia? → és candidat a classe. Llibre, Empleat, Préstec ho compleixen.
2. És un simple valor descriptiu d'una altra cosa? → és candidat a atribut. Títol, ISBN, any descriuen un llibre; dies de retard i multa descriuen un préstec.
3. És el sistema sencer o un concepte vague? → normalment no és una classe de domini. Biblioteca és el sistema; el que apareixerà més endavant és un Cataleg que guarda materials i un GestorPrestecs que orquestra operacions (mòduls 5 i següents).

Resultat del filtratge per a aquest mòdul: tres classes, Llibre, Empleat i Prestec, exactament les que es van anunciar en tancar el mòdul 2.

I una pregunta que separa un model bo d'un de mediocre: de qui és cada responsabilitat? Una responsabilitat mal col·locada compila igual, però enverina el disseny.

Aquest és el model al qual arribaràs en acabar el mòdul. Guarda'l com a mapa: cada lliçó hi afegeix una peça.

Llegeix-lo així: un Prestec coneix un Llibre i un Empleat; ni el llibre ni l'empleat no necessiten conèixer el préstec. Les fletxes indiquen la direcció de la dependència, i aquesta direcció és una decisió de disseny, no un accident.

A la lliçó 03-05 aquest diagrama creixerà cap amunt: apareixerà una classe Material de la qual Llibre, Revista i Dvd seran especialitzacions.

Les classes rarament viuen aïllades. Hi ha tres formes típiques de relacionar-se, a més de l'herència:

La prova pràctica per distingir agregació de composició és preguntar-se: si destrueixo l'objecte contenidor, té sentit que la part continuï existint? Si la resposta és sí, és agregació; si és no, composició. Un llibre sobreviu al catàleg que el llista; el desglossament intern d'una multa no sobreviu al préstec que la va generar.

No t'obsessionis amb aquestes etiquetes: en codi Java, associació, agregació i composició s'escriuen gairebé igual (un camp que referencia un altre objecte). El seu valor és en el disseny i en la conversa amb altres desenvolupadors.

Els cursos solen enumerar només la columna esquerra. Un professional necessita les dues.

Regla pràctica que et servirà durant anys: la POO paga quan el programa ha de créixer i canviar. Un script de trenta línies que s'executa un cop no necessita classes. BiblioTech sí: creixerà durant deu mòduls més.

• Confondre classe amb objecte en parlar-ne. "Modificaré el llibre" és ambigu: la classe Llibre (el plànol, i afecta tothom) o l'objecte javaEficac (un exemplar)? Acostuma't a anomenar la classe en majúscula i singular (Llibre) i els objectes amb noms concrets (javaEficac).
• Convertir en classe tot substantiu de l'enunciat. No tot allò que es pot anomenar mereix una classe. titol és un String, no una classe Titol. Aplica el filtre de l'apartat 8: identitat + estat que canvia.
• Crear classes que només guarden dades. Una classe amb cinc camps i deu getters, sense cap comportament, és una estructura de dades disfressada (se'n diu model anèmic). Pregunta't sempre què sap fer la classe, no només què conté.
• Col·locar el comportament a la classe equivocada. Si Llibre calculés multes, hauria de conèixer terminis, tarifes i dies transcorreguts, dades que no li pertanyen. Cada operació va on són les dades que necessita.
• Començar per l'herència. És el pilar més cridaner i el més perillós. Modela primer classes planes que funcionin; la jerarquia apareixerà sola quan la necessitis (lliçó 03-05).
• Consell: dibuixa abans de teclejar. Cinc minuts de diagrama de classes en paper estalvien hores de refactorització. No necessites UML formal: caixes amb nom, atributs i fletxes ja n'hi ha prou.
• Consell: anomena en l'idioma del negoci. Prestec, Llibre i Empleat són millors noms que DataRecord, Item o Manager, perquè qualsevol persona de Nexus Software els entén sense explicació.

Nexus Software vol ampliar BiblioTech amb un mòdul de sales de reunions:

Els empleats reserven sales de reunions. Cada sala té un nom, una capacitat màxima de persones i un equipament (projector sí o no). Una reserva la fa un empleat per a una sala, en una franja horària concreta, amb un nombre d'assistents que no pot superar la capacitat de la sala. Una reserva es pot cancel·lar.

Sense escriure codi Java complet:

1. Enumera els substantius i classifica'ls en classe, atribut o descartat, justificant cada decisió.
2. Escriu una taula de responsabilitats: què ha de saber fer cada classe.
3. Indica quin tipus de relació (associació, agregació o composició) hi ha entre Reserva i Sala, i entre Reserva i Empleat.

Amb el resultat de l'exercici 1:

1. Dibuixa el diagrama classDiagram de mermaid del model de sales.
2. Escriu els esquelets de les classes (només la declaració i els camps, amb comentaris on anirien les operacions). No implementis res: la sintaxi completa arriba a 03-02.

Un company proposa aquest disseny per a BiblioTech. Assenyala tres decisions que consideris errònies i explica on hauria de viure cada responsabilitat:

Solució 1

1. Classificació de substantius

Un matís professional: franja horària podria arribar a ser una classe pròpia (Franja, amb hora d'inici i de fi, i capaç de dir si se solapa amb una altra). És una decisió legítima, però prematura ara: comença per atributs i promou a classe només quan el concepte acumuli comportament propi.

2. Responsabilitats

Observa que "dir si admet N assistents" és de Sala, perquè la capacitat és una dada seva; en canvi "validar que hi caben" és de Reserva, perquè només la reserva coneix el nombre d'assistents. Cadascuna aporta el que sap.

3. Relacions

• Reserva → Sala: associació (o agregació). La sala existeix abans i després de la reserva; cancel·lar una reserva no destrueix la sala.
• Reserva → Empleat: associació. L'empleat té vida pròpia a l'empresa.

No hi ha composició evident en aquest model, llevat que la franja horària es modelés com a objecte intern de la reserva: llavors sí que seria composició, perquè aquesta franja no significa res fora de la seva reserva.

Solució 2

Diagrama

Esquelets

Dos detalls que reapareixeran: els camps que referencien altres classes (Sala sala) són exactament el que dibuixàvem com a fletxa al diagrama, i les hores es modelen com a enters perquè LocalTime pertany a java.time, que s'estudia a la lliçó 10-05.

Solució 3

(a) multaDelDarrerPrestec a Llibre està mal col·locat. La multa és conseqüència d'una operació de préstec concreta, no una propietat del llibre. Amb aquest disseny, si el mateix exemplar es presta cinc vegades, el camp només recorda la darrera multa i perd l'historial; i pitjor encara, obliga Llibre a conèixer terminis i tarifes, que no són assumpte seu. La multa pertany a Prestec.

(b) nomDeLempleatActual a Llibre està malament per dues raons. Primera, és la mateixa dispersió que pateix avui BiblioTechApp: guardar el nom en lloc de l'Empleat deixa la dada òrfena i sense possibilitat d'accedir a l'identificador ni als préstecs acumulats. Segona, i més important, el vincle llibre–empleat només existeix mentre hi ha un préstec, així que el seu lloc natural és la classe Prestec, que ja relaciona tots dos. Si Llibre ha de saber alguna cosa, és únicament si està disponible o no.

(c) imprimirRebutDeDevolucio() barreja domini i presentació. Una classe de domini no hauria de saber que existeix una consola, ni el format del rebut, ni l'amplada de les columnes. Si demà BiblioTech es converteix en aplicació web (mòdul 12), caldria reescriure la classe sencera. El rebut el genera qui s'ocupa de la interfície. És el problema dels nivells d'abstracció barrejats, que es tracta a fons a la lliçó 03-08.

(d) guardarEnFitxer() afegeix una responsabilitat aliena. Persistir en disc és un assumpte d'infraestructura (mòdul 7), no del concepte "llibre". Una classe amb dos motius diferents per canviar —canvia el negoci, canvia el format de fitxer— és una classe que farà infeliç qui la mantingui.

Disseny corregit, en esquelet:

En aquesta lliçó has canviat de manera de pensar abans de canviar de manera d'escriure. Has vist per què l'estil procedimental es degrada quan el programa creix —dades disperses, estat global, regles duplicades, impossibilitat d'escalar—, amb el teu propi BiblioTechApp com a cas d'estudi. Has après el vocabulari essencial: classe com a plànol i objecte com a exemplar, identitat, estat i comportament, instància i referència. Tens un mapa dels quatre pilars i de la lliçó on es desenvolupa cadascun. I, sobretot, has modelat el domini de BiblioTech: dels substantius de l'enunciat a tres classes —Llibre, Empleat, Prestec— amb responsabilitats explícites, relacions dibuixades i un diagrama objectiu que guiarà la resta del mòdul. També saps que la POO no és gratis: costa indirecció, cerimònia i risc de sobredisseny, i només es paga sola quan el programari ha de créixer.

Tens el plànol. A la lliçó següent, Classes i objectes, comences a construir: declararàs la classe Llibre amb la seva sintaxi exacta, veuràs quin valor prenen els camps abans d'assignar-los res, crearàs objectes amb new seguint pas a pas què passa a la pila i al heap, descobriràs què significa de debò un NullPointerException i per què dues referències al mateix objecte poden provocar sorpreses desagradables. En acabar-la, "Java Eficaç", "Patrons de Disseny" i "Refactorització" hauran deixat de ser cadenes de text soltes per convertir-se en tres objectes amb vida pròpia dins de BiblioTechApp.