Scusa, ma sei serio O_O ?
Qualche post fa ho elencato alcuni motivi per cui ritengo che java non ispiri affatto a rispettare la regola del KISS (si Are, anche io preferisco le milf
).
Comunque...
=> Garbage collection: come si può rispettare una corretta implementazione della programmazione orientata agli oggetti (OOP) quando un modulo non può deallocare le risorse da lui allocate, lasciando questo compito ad un altro modulo?
Nell'OOP un modulo che alloca delle risorse deve anche occuparsi della loro deallocazione.
Chi mi garantisce che il Garbage Collector entri realmente in funzione quando serve, liberando una risorsa importante (un file handler ad esempio) in tempi utili?
Questo è un grosso punto a sfavore di Java nel contesto della 'modularità del codice'.
Codice non modulare = non semplice da mantenere = tempo = costi!
Qualche volta ho letto robe del tipo:
Il Garbage Collector è utile perchè se ho due oggetti che referenziano gli stessi dati, dal momento in cui gli oggetti stessi non si occupano di liberare le risorse, non devo scegliere quale tra i due oggetti dovrà deallocare le risorse.
=_= Una situazione di questo tipo vuol dire che ci sono dei problemi di progettazione = tempo = costi!
=> java non usa puntatori: falso..in java tutto è un puntatore! Se voglio usare un tipo di dato che non sia incluso nel linguaggio sono costretto a lavorare sempre in upcasting.
Bello vero ? Un po' meno bello quando upcasto su un tipo errato e ricevo un bellissimo errore in release, quando ho già consegnato il software al cliente.
=> Divoratore di memoria: Supponiamo di avere un bel vettore, un simpatico array di 100milioni di oggetti INT. Un INT alloca circa 16 bytes di memoria nel migliore dei casi (la grandezza di un puntatore, solitamente 4 bytes, più 4 bytes per l'engine di allocazione della memoria = 8 bytes + 4bytes l'INT a 32bit). 16*100.000.000 = 1.600.000.000 che sono circa 1,5 GB.
In C++ un vettore contenente 100milioni di oggetti non supera i 400MB.
=> Impossibilità di effettuare l'Overload degli Operatori: minori possibilità di astrazione = codice più difficile da mantenere, più difficile da leggere e potenzialmente inefficente.
Se vuoi posso continuare! Qualcos'altro riesco a tirarlo fuori!
A supporto di queste mie parole ti porto l'esempio che vivo ogni giorno: una applicazione mission critical di un servizio pubblico, piattaforma tecnologica J2E+ORACLE su AIX e WebSphere.
Essendo un applicazione che necessità di costanti aggiornamenti per stare dietro alla folle burocrazia italiana, posso garantirti che noi dell'assistenza ne vediamo di tutti i colori ogni qualvolta venga aggiornato qualcosa.
Il bello è che dietro c'è gente che di libri di ingegneria ne ha masticati fin troppi, capaci di lavorare a livelli di astrazione assurdi, ma che spesso si incrinano davanti ai limiti di piattaforme tecnologiche che promettono ciò che non possono mantenere..questo porta al compromesso.
in base a questo posso dirti che secondo il mio umile parere Java non aiuta il programmatore nel seguire la sacrosanta regola oldschool del KISS.
)
