Evoluzionismo e creazionismo

[4-7-08 11.29.49]

Fxlvxx: perché tutte le dichiarazioni di tipo delle ServicePreference in Routines sono fatte senza import, bensì come it.5w1mm.53rv1c35.4d7.5ub7yp0106y.ServicePreference?
P1s1: i'll have a look at it
Fxlvxx: pardon, nel BuildTimeMapper
P1s1: ah, k
P1s1: refactoring
P1s1: devi sapere che la struttura dati service, servpref ,... ecc
P1s1: derivava, un tempo dal repository dei servizi
P1s1: che ne aveva i suoi par (EntityBean, ndr)
P1s1: su db
P1s1: e li scambiava col service manager
P1s1: che però non poteva persisterli così, ma li traduceva in altri par (sempre EntityBean, ndr)
P1s1: ecc
P1s1: via fino al m1ddl3w4r3
P1s1: questo perchè la divisione delle responsabilità fu fatta prima di scrivere una qualsiasi cazzo di api
P1s1: probabilmente anche prima di decidere come sarebbero state le strutture dati
Fxlvxx: mmm ok, quindi ora non esiste più un motivo preciso
P1s1: l'esistenza di 5w1mmB451c5 e' il tentativo, a posteriori, di rimettere ordine in tutto
P1s1: solo che le classi omonime non sempre vengono prese bene dal refactor
P1s1: e siccome quando una classe usava due classi omonime solo un import era possibile
P1s1: e il resto veniva come vedi nel codice
P1s1: poi (una volta fatto il refactor, ndr), sparita la classe omonima "recessiva"
P1s1: la classe "dominante", per usare un termine mendeleeviano,
P1s1: sarebbe dovuta rimanere l'unica importata

P1s1: in quel caso
P1s1: probabilmente è sparita la classe che era importata
P1s1: e visto che il nome dell'altra era già esplicito (con tanto di package, ancora ndr)
P1s1: il CTRL+O
P1s1: per organizzare gli import non l'ha vista

P1s1: ovviamente per la chiesa la classe e' stata creata cosi' come la vedi ora fin dall'inizio