[JAVA] Java OOP disaccoppiamento

[bisso85]

Buongiorno a tutti,
complimenti per il sito, autorevole fonte di informazione e formazione che seguo da molti anni.

Tuttavia al momento sono perplesso di fronte a questo articolo. Non mi è chiaro come "disaccoppiare" le classi in questo modo aumenti la scalabilità del software (a parere mio la diminuisce). In seconda istanza, si tratta di un work-around per aggirare il tipaggio ed i costrutti del linguaggio pensati per ridurre gli errori in fase di progettazione e programmazione.

Qualcuno mi spiega l'articolo?

[valia]

perché la diminuisce?

la prima parte (il disaccoppiamento tra le classi) è pratica già integrata da anni nell'OOP.
Per ricordare l'utilità io dico sempre che la cosa importante è dire COSA fa una classe, non COME lo fa. COSA una classe fa lo dici tramite una interfaccia, ecco che imporre l'appartenenza ad una interfaccia slega l'implementazione dalla dichiarazione (o meglio relega tutto ad un unico punto del codice.

Pensa ad esempio List e ArrayList: la seconda è una implementazione della prima.

List myList = new ArrayList();

ti consente di dire:
voglio un oggetto in grado di fare quello che dichiaro in List. Come lo fai non importa.
Nei metodi ricorda di passare sempre per List. Se tu usassi ArrayList sono nell'istante di istanziazione, vedi che ti ritrovi un unico punto in cui dici chi è l'implementata. A questo punto se un domani hai ArrayList2 migliore di ArrayList, vedi che la modifica è alquanto "leggera".
Di contro qui paghi il fatto che sei legato ai metodi dell'interfaccia, ecco la seconda parte dell'articolo (spet che me la rileggo bene)

edit

la seconda parte, come già ti accennavo, tiene conto dell'accoppiamento tra i metodi.
Cioè sei comunque legato a quello che dichiari nell'interfaccia, modificare quella potrebbe essere deleterio. Allora si è pensato di disaccoppiare anche a livello di metodo, creando un layer intermedio (l'esecutore appunto) e tutto è spiegato lì.

Quanto è utile tutto nella realtà?
Beh fai conto che dipende sempre da quello che fai e dalle dimensioni della classe, in generale aumenti di poco la complessità, ma aumenti la scalabilità (che poi è quello che si vuole ottenere con queste tecniche)

[bisso85]

In effetti forse a sfuggirmi sono i contesti dove questo tipo di disaccoppiamento è utile.

Invece, per quanto riguarda la scalabilità, trattandosi di una proprietà strutturale e non funzionale, non capisco come il disaccoppiare le classi a livello di metodo possa consentire alla mia infrastruttura di sopportare aumenti di carico computazionale. Diminuisce perché lo string-matching mi porta ad un carico maggiore rispetto all'uso dei naturali puntatori a funzione.

[valia]

Originariamente inviato da bisso85
In effetti forse a sfuggirmi sono i contesti dove questo tipo di disaccoppiamento è utile.

Invece, per quanto riguarda la scalabilità, trattandosi di una proprietà strutturale e non funzionale, non capisco come il disaccoppiare le classi a livello di metodo possa consentire alla mia infrastruttura di sopportare aumenti di carico computazionale.
Diminuisce perché lo string-matching mi porta ad un carico maggiore rispetto all'uso dei naturali puntatori a funzione.

scalabilità è intesa come "possibilità di espandere a costi limitati". E' ovvio che aggiungere un layer all'esecuzione crei carico computazionale. Quando vai a "progettare" sistemi di questo tipo fai un calcolo tra costi e benefici, rientrano anche questi parametri nel computo e decidi di conseguenza. Nei piccoli progetti di solito è un overhead non necessario.

Spero di aver risposto al tuo quesito, onestamente non mi è molto chiaro quello che vuoi dire (anche parlando di puntatori a funzione)

[bisso85]

Quello che dici tu rientra nella caratteristica di manutenibilità del software, caratteristica ben distinta dalla scalabilità. A parte il fatto che l'autore può essersi sbagliato, ma non credo dato che aveva già scritto un articolo in precedenza dove riprendeva gli stessi concetti.

Per quanto riguarda i puntatori a funzione "naturali", utilizzando i normali costrutti del linguaggio il compilatore risolve tutti i riferimenti in fase di compilazione attraverso l'uso di puntatori (a funzione) diretti in memoria. La "tecnica" proposta si frappone a questo meccanismo aggiungendo un carico inutile. In termini di scalabilità, il software si troverà ad essere _in grado di gestire minimo un ordine di grandezza di richieste in meno.

Intendendo la scalabilità nei termini che dici tu invece, e parlando quindi di "espandibilità" e "riusabilità", con questa tecnica non si riesce a fare niente in più di quello che si potrebbe fare usando le normali interfacce per un semplice motivo: che si chiami action e la gestisci come esposto nell'articolo o che la chiami metodo e la gestisci nel modo corretto, chi deve compiere quella azione deve conoscerla. Detta in altre parole cambia solo per il programmatore: c'é chi trova comodo il tipaggio stretto di java perché ti impedisce di commettere errori "stupidi" e chi trova comodo il tipaggio interpretato di php perché ti permette di scrivere codice più velocemente.

Come dici tu è necessario fare un calcolo tra costi e benefici, ma a priori scegliendo un linguaggio ottimizzato per lo stile che si ritiene migliore: con la tecnica proposta java offre prestazioni peggiori di php.

[valia]

Ecco che avevo capito bene, tu ti riferivi a quello che succede in fase di compilazione (aspetto che tendo a tralasciare in java).
Non è detto che il carico sia inutile, magari tu non hai visto in realtà una applicazione di questi principi, ma ci sono casi in cui si preferisce "pagare" lo scotto di un layer in più e ottenere altri vantaggi (ritorni a costi/benefici da comparare).
Quelle due tecniche in realtà le ho pure viste applicate, ti assicuro che l'aggiunta di un modulo è un'operazione banale che richiede il tempo di scrittura del modulo (non da poco se devi integrarti in sistemi esistenti). Come già hai visto, paghi il "passare" attraverso un layer successivo, ma negli ambiti in cui è usato questo è visto un vantaggio, non un difetto.

E' vero che chi deve compiere l'azione deve conoscerla, ma pensa ad un fornitore di servizi: ti dicono che questo fornisce 10 servizi (dicendoti quali). Tu fin'ora hai solo l'interfaccia, quindi significa che una variazione minima di questa, tu devi variare tanto. Ad un utilizzatore del servizio, in questo modo, posso "comunicare" la nuova feature, ma non lo obbligo da un update.
Lato "fornitore servizio" ho fatto una classe è l'ho registrata"
Lato "utilizzatore servizio" mi aggiorno quando mi pare.

sono concetti che vengono applicati in vari ambiti e ciclicamente, se ne capisci la potenzialità sai anche che spesso si preferisce "pagare" lo scotto del layer in più ma avere possibilità di "crescere" in modo semplice.

Riguardo scalabile, è vero che lo fai rientrare nella manutenzione, a volte si usa impropriamente il termine scalabile per indicare l'incremento del software o delle funzionalità richieste (ecco perché l'ho usato in quel modo).

Ci andrei piano col paragonare php a java, sono due cose differenti (parli di un linguaggio di programmazione e di un linguaggio di scripting).

[bisso85]

prova

[bisso85]

Originariamente inviato da valia
Ecco che avevo capito bene, tu ti riferivi a quello che succede in fase di compilazione (aspetto che tendo a tralasciare in java).
Non è detto che il carico sia inutile, magari tu non hai visto in realtà una applicazione di questi principi, ma ci sono casi in cui si preferisce "pagare" lo scotto di un layer in più e ottenere altri vantaggi (ritorni a costi/benefici da comparare).
Quelle due tecniche in realtà le ho pure viste applicate, ti assicuro che l'aggiunta di un modulo è un'operazione banale che richiede il tempo di scrittura del modulo (non da poco se devi integrarti in sistemi esistenti). Come già hai visto, paghi il "passare" attraverso un layer successivo, ma negli ambiti in cui è usato questo è visto un vantaggio, non un difetto. _

Non pensare a ciò che succede in compilazione e di conseguenza a runtime non è una buona pratica. In ogni caso spero bene che chi decide di usarlo non lo veda come un difetto, però tipicamente sistemi così eterogenei prevedono dei meccanismi di trasporto (endogeni e/o esogeni) che, oltre ad operazioni di traduzione, introducono questo tipo di astrazione, senza bisogno di ridurre Java a linguaggio di scripting.

Originariamente inviato da valia
E' vero che chi deve compiere l'azione deve conoscerla, ma pensa ad un fornitore di servizi: ti dicono che questo fornisce 10 servizi (dicendoti quali). Tu fin'ora hai solo l'interfaccia, quindi significa che una variazione minima di questa, tu devi variare tanto. Ad un utilizzatore del servizio, in questo modo, posso "comunicare" la nuova feature, ma non lo obbligo da un update.
Lato "fornitore servizio" ho fatto una classe è l'ho registrata"
Lato "utilizzatore servizio" mi aggiorno quando mi pare.
sono concetti che vengono applicati in vari ambiti e ciclicamente, se ne capisci la potenzialità sai anche che spesso si preferisce "pagare" lo scotto del layer in più ma avere possibilità di "crescere" in modo semplice.

Soluzioni di questo tipo sono adottate tipicamente perché non si conosce il modo giusto per fare le cose e, nella convinzione di metterci meno, ci si imbarca in soluzioni acrobatiche. Trattandosi di un sito di formazione mi sarei aspettato articoli su queste tematiche suggerendo approcci più efficaci.

Originariamente inviato da valia
Riguardo scalabile, è vero che lo fai rientrare nella manutenzione, a volte si usa impropriamente il termine scalabile per indicare l'incremento del software o delle funzionalità richieste (ecco perché l'ho usato in quel modo). _

Sbagliare è umano, e sicuramente il linguaggio colloquiale tipicamente si concede licenze che formalmente non vengono accettate. Ma un articolo tecnico non è il posto giusto dove commettere ripetutamente un errore come questo.

Originariamente inviato da valia
Ci andrei piano col paragonare php a java, sono due cose differenti (parli di un linguaggio di programmazione e di un linguaggio di scripting).

Hai colto in pieno il motivo per cui non capisco questa "tecnica".

[valia]

Guarda, io sono tra quelle che conta i byte per qualsiasi cosa debba fare, cosa che ormai non si fa, quindi so bene che bisogna pensare a quello che succede sotto.

Non ho capito bene cosa vuoi dire con

però tipicamente sistemi così eterogenei prevedono dei meccanismi di trasporto (endogeni e/o esogeni) che, oltre ad operazioni di traduzione, introducono questo tipo di astrazione, senza bisogno di ridurre Java a linguaggio di scripting.

Sarà che io non considero mai Java un linguaggio di scripting (non vedo perché dovrei farlo).

soluzioni di questo tipo sono adottate tipicamente perché non si conosce il modo giusto per fare le cose e, nella convinzione di metterci meno, ci si imbarca in soluzioni acrobatiche. Trattandosi di un sito di formazione mi sarei aspettato articoli su queste tematiche suggerendo approcci più efficaci.

Dici che non si conosce il modo giusto per fare le cose, beh allora proponi un'altra soluzione. Mi va bene che dici che è sbagliato, ma dire "è sbagliato, si dovrebbe fare così" è ancora meglio.

Ma un articolo tecnico non è il posto giusto dove commettere ripetutamente un errore come questo.

Hai mai letto un articolo tecnico per tecnici?
Ad un certo livello (non me ne voglia nessuno) considero autorevoli articoli pubblicati e accessibili dagli addetti del settore, fai conto che il pubblico a cui si rivolge html.it non sempre è composto da tecnici, ma bisogna fare comprendere il concetto a chi non sa niente dell'argomento. E' un ottimo startpoint, ovviamente se si deve salire di livello bisogna andare altro. In questo ambito le semplificazioni sono ben accette

[bisso85]

Prima dici di non pensare a che succede quando compila, poi di contare i singoli byte.. Beh.. A parte queste cose indicative, ma tralasciabili, posso dire che di articoli tecnici ne ho letti molti, ma è raro facciano riferimento a linguaggi e contesti specifici. Ovvio che HTML.it è diverso, come dici tu, infatti è più specifico e pratico.

Per quanto riguarda le soluzioni alternative io non sto dicendo che ci sono modi migliori per disaccoppiare, ma che non si deve fare, o da programmare si passa a scriptare. Tra l'altro c'é anche l'alternativa della reflection affiancata ad un pattern bridge.. forse sarebbe minore come male.. Ma ugualmente da schivare progettando meglio l'architettura. Un'altra alternativa è la dependency injection che puoi evitare problemi di questo tipo andando a costruire le interfacce in modo opportuno e configurando opportunamente il container.

Sicuramente ci sono altre tecniche, come la divisione più accurata del codice in jar e l'uso di maven.. Ma credo sia il lavoro del nostro amico giornalista costruire articoli ed esempi a partire da queste pratiche.

Non ti piacerebbe sentire anche il parere di qualcun'altro? Due punti di vista sono troppo pochi