> In realtà più che esempi volevo capire i criteri che utilizzate per
prendere la decisione di "sdoppiare" il bean e perché.
>
Facendo retrospettiva, per me devono verificarsi queste due condizioni (
*entrambe*):
- c'e' un paradigm shift (esco dal mondo OO per entrare nel relazionale,
request/response, publish/subscribe, ecc.ecc.)
- ho bisogno di una rappresentazione diversa (devo inserire una
serializzazione che non riesco a rappresentare, mi esporrei a un problema
di sicurezza, etc.etc)
E poi YAGNI, se posso lo evito. Ho sempre tempo a rifattorizzare dopo.
Prendi le mie considerazioni con le molle pero' perche':
- sono un agilista convito, affanculo BDUF, l'architettura evolvera' ed
emergera' ad ogni iterazione
- ormai faccio solo piu' microservizi (alla faccia di quelli che mi
prendevano per il culo nel 2013 :)) quindi se vuoi la mia architettura
internamente e' generalmente molto semplice
*>> L'uso dei builder per costruire oggetti nei test è stato reso popolare
dal GOOS*
>>
>Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD
mi sembra a dir poco opinabile [...]
>
A riguardo di quello che dice Matteo, penso che tu l'abia intepretato male.
Quando dice "*...**l'uso dei builder per costruire oggetti nei
test..**" *intende
esattamente questo, e' una frase da leggere tutta di un fiato: non e'
un'affermazione generale su come i Builder possano essere stati resi
popolari.
Se vogliamo parlare in generale di popolarita', pero', date un'occhiata ad
apache-http:
- 3,x: Apache scopre il factory pattern, tutto e' una factory
- 4.x: Apache scopre il builder pattern: tutto e' un builder
Raga, se scoprono il Visitor siamo fottuti :)
Ciao,
Bruno
2018-01-15 21:47 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>
>
> In realtà più che esempi volevo capire i criteri che utilizzate per
> prendere la decisione di "sdoppiare" il bean e perché.
>
> Ad esempio: creo sempre dei bean specifici per le "viste" sugli oggetti
> perché ... / creo un bean specifico per la "vista" di un particolare
> oggetto soltanto quando ... perché ... / creo una "duplicazione" dello
> stesso bean soltanto sotto tortura perché ...
>
> Personalmente credo che ogni decisione abbia dei pro e dei contro, non
> sempre sono evidenti subito. La mia inclinazione è quella di avere degli
> oggetti core del sistema (oggetti "veri" come li hai chiamati, con della
> logica vera) + una rappresentazione per ogni tipo di boundary (vista da
> serializzare/deserializzare, entity per il database, dto per colloquiare
> con un servizio esterno al sistema ecc.), ma in molti casi la logica vera
> poi non è molta, ed il sistema si limita per la maggior parte a trasformare.
>
> Ciao,
> Tatiana
>
> пн, 15 янв. 2018 г. в 18:59, bruno bossola bboss...@gmail.com
> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>
>>
>>
>> Mah, per esempio nei servizi REST raramente serializzo l'oggetto, ma una
>> "vista" di esso. Lo stesso in ingresso, ricevo una "vista" e da quella
>> ottengo il vero oggetto.
>> Questo per me e' l'esempio piu' comune, e faccio a mano, si, li testo di
>> solito perche' quando creo l'oggetto "vero" di solito passo parametri
>> (magari un repository) e c'e' della logica "vera" da disegnare.
>>
>> Ciao,
>>
>> Bruno.
>>
>> 2018-01-15 17:35 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
>> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>>
>> Ciao a tutti,
>>>
>>> Vorrei allargare la questione posta da Federico.
>>>
>>> In quali occasioni ricorrete al mapping dei bean (trasformazione di un
>>> bean in un altro bean di struttura molto simile se non uguale)? Quando
>>> secondo voi è giustificata la creazione di questi bean differenti e quando
>>> invece è insensato?
>>>
>>> Preferite mapper automatici tipo dozer o fate a mano (al di là di come e
>>> dove, comunque a mano)?
>>>
>>> Grazie,
>>> Tatiana
>>>
>>> вс, 14 янв. 2018 г.. в 11:23, bruno bossola bboss...@gmail.com
>>> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>>>
>>
>>>>
>>>> Se il problema e' che da A devo costruire B, allora un metodo in A che
>>>> si chiama "buildB()": questo per "information expert" (GRASP)
>>>> <https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Information_expert>,
>>>> e
>>>> se ci sono cose secondarie da usare nella conversione le passo come
>>>> parametro.
>>>>
>>>> In altri casi dipende... in genere cerco di assegnare la
>>>> responsabilita' a qualche oggetto che ha senso che ce l'abbia :)
>>>> Ciao,
>>>>
>>>> Bruno
>>>>
>>>>
>>>> 2018-01-12 17:35 GMT+00:00 Federico Fissore feder...@fsfe.org
>>>> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>>>>
>>>>>
>>>>>
>>>>> Ciao
>>>>>
>>>>> domandina del venerdì sera
>>>>>
>>>>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>>>>
>>>>> return ExpenseBuilder.anExpense()
>>>>> .withId(id)
>>>>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>>>>> .withDate(new Date())
>>>>> .withReason("Something pretty")
>>>>> .build();
>>>>>
>>>>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>>>>> presi da un altro bean via getter, oppure quest altro bean offre lui
>>>>> un
>>>>> metodo che restituisce un builder pre-popolato
>>>>>
>>>>> Anche voi siete abituati a fare così quando dovete passare dati da una
>>>>> DTO a un altro? Se no, come fate?
>>>>>
>>>>> ciao
>>>>>
>>>>> federico
>>>>>
>>>>
>>>>
>
