Perché i metodi accessor della specifica JavaBean diventano lo standard per lo sviluppo Java?

9

La specifica JavaBeans descrive un JavaBean come

A Java Bean is a reusable software component that can be manipulated visually in a builder tool

Poiché la maggior parte delle righe di codice scritte non sembrano avere nulla a che fare con l'essere manipolati visivamente in uno strumento di costruzione, perché la specifica JavaBean è stata la "via" per scrivere il codice orientato agli oggetti?

Desidero rinunciare al tradizionale getter / setter in favore di Fluent Interfaces tutto il codice, non solo in costruttori, ma temete di farlo, poiché questo non è tradizionalmente il modo in cui il codice orientato agli oggetti è scritto in Java.

    
posta Dakotah North 01.06.2012 - 21:20
fonte

2 risposte

7

Gli accessor in stile JavaBean si sono dimostrati adatti per tutti i tipi di scenari simili allo scenario originale di "builder tool" in un punto centrale: i componenti vengono passati in giro e manipolati da contenitori e strumenti generici e dall'applicazione codice. In un server di app si dispone di componenti di servizio a cui un EJB o un contenitore Spring aggiunge iniezioni di transazioni e dipendenze, modelli di dominio persistenti a cui un ORM aggiunge il caricamento pigro e il rilevamento delle modifiche e che può essere serializzato in XML da una libreria senza alcun codice specifico.

Gli accessor forniscono una API comune che è molto flessibile nel modo in cui il componente può essere utilizzato - non vieta un ordine di operazioni. Ogni chiamata di accesso è indipendente dalle altre e tutte seguono lo stesso schema, quindi puoi aggiungere facilmente livelli generici che aggiungono funzionalità senza interrompere il modello di utilizzo previsto.

Al contrario, le interfacce fluenti sono spesso progettate per l'uso one-shot: l'oggetto viene creato, viene chiamata una catena di metodi che termina con un metodo che produce un risultato finale e l'oggetto viene quindi abbandonato. C'è molta meno flessibilità (soprattutto nei metodi facoltativi) e genericità, ma questo è esattamente il vantaggio: l'interfaccia ti costringe a un modello di utilizzo previsto, rendendolo molto facile da usare.

Quindi JavaBeans e le interfacce fluenti hanno vantaggi in diversi scenari e da ciò che dovresti usare dipende. E potresti persino combinarli entrambi.

    
risposta data 01.06.2012 - 22:33
fonte
3

Bene, poiché la specifica JavaBeans a cui ci si collega definisce una convenzione per l'accesso alle proprietà, la gente ha deciso di sfruttare la convenzione e creare framework attorno ad essa. Alcuni di questi framework, come Hibernate, erano abbastanza utili e sono diventati molto popolari. Quindi, poiché le persone hanno utilizzato framework basati sulle specifiche JavaBeans, javaBeans è diventato sempre più onnipresente e intorno a loro sono stati creati sempre più framework.

Le interfacce fluenti sono un'ottima idea, ma giocano bene con Spring or Struts 2? Mi batte.

    
risposta data 01.06.2012 - 22:42
fonte

Leggi altre domande sui tag