Programmazione OOP - Come e dove sfruttarla (concetti chiave)?

[daniele_dll]

Originariamente inviato da Tobler
Hola, sono pienamente d'accordo con te nel caso si debba lavorare ad un solo progetto. Anche a me piace molto la programmazione "hardcore" tutto scritto in un solo file, perchè ottimizzi da morire le prestazioni. Però quando hai già 3 o 4 ideone per la testa ti scoccia un po' dove riscrivere tutto da zero, e avere le classi pronte è un bel vantaggio perchè non perdi tempo a ricostruire.
Come si aggiunge di solito, ovviamente IMHO

scusami ma dire che "ottimizzi da morire le prestazioni" perché fai tutto in un file non è per niente vero

ti ritroverai con un file ENORME, INGESTIBILE, NON RIUSABILE ed in aggiunta il parser PHP, ad OGNI accesso, dovra parsarlo e compilarlo tutto indipendentemente da cosa deve essere eseguito

[Tobler]

Originariamente inviato da daniele_dll
scusami ma dire che "ottimizzi da morire le prestazioni" perché fai tutto in un file non è per niente vero

ti ritroverai con un file ENORME, INGESTIBILE, NON RIUSABILE ed in aggiunta il parser PHP, ad OGNI accesso, dovra parsarlo e compilarlo tutto indipendentemente da cosa deve essere eseguito

No ok non tutto il progetto in un solo file!

Una pagina php per ogni html che vuoi generare.

[LeaderGL]

Io mi trovo daccordo un po con tutti e due (kuarl e daniele_dll).

Come ho scritto all'inizio per buona pratica di OOP si cerca di avere un'elevata coesione ed un basso accoppiamento.

Questo significa che ogni classe, che rappresenta un oggetto "reale" con cui si ha a che fare, deve implementare (per quanto possibile, senza estremizzare) il necessario a rappresentare quel particolare oggetto.

Quindi una classe "User" dovrà possedere attributi e metodi per rappresentare (sottolineo rappresentare) un utente; quindi non per memorizzarlo su database, su file o su qualsiasi altra parte...solo per rappresentarlo.

Un utente è rappresentato da nome, cognome, codicefiscale, email, etc.

Nel momento in cui si vuole creare un nuovo utente le operazioni, in genere, sono:
1) Lettura dei dati provenienti dal form compilato da una persona
2) Validazione di quei dati
3) Creazione di un oggetto della classe "User"

se poi questo utente lo si vuole salvare da qualche parte avremo bisogno:
1) Una classe che si interfaccia con il nostro dispositivo di storage: database, file o qualsiasi altra cosa; quindi ci fornirà dei metodi per gestire il dispositivo
2) Una classe che avendo un riferimento alla classe di "storage" ed un oggetto di tipo "User" lo memorizzi.

Questo per buona pratica di progettazione ad oggetti. Che tradotto significa:
1) Classe di validazione dati
2) Classe user
3) Classe storage
4) Classe store_user (se così la vogliamo chiamare)

siccome poi in genere dobbiamo gestire molti utenti per ricerche o altro ci aggiungerei anche una "UserList" (una collezione di utenti).

Su tutto questo ovviamente si può dissentire (ad esempio a me non piace il pattern MVC applicato al web ed a php...lo trovo un po forzato e forse con un passaggio innutile) ma ciò non toglie che i libri di analisi e progettazione questo dicono. Basta poi guardare un secondo a java e ci si rende conto che nessuna classe ha dei metodi che te la salvano su file...perchè se improvvisamente non la vuoi più salvare su file son dolori.

Se noi implementiamo stesso nella classe "User" il salvataggio su database nel momento in cui cambia la logica di user o del database o di qualsiasi altro fatto noi dovremmo ristrutturare la nostra classe user e questo probabilmente avrà ritorsioni anche su altro codice. Mentre con la suddivisione dei compiti proposta noi dovremmo solo modificare la "store_user" ed avremmo fatto.

Possiamo addirittura scegliere di screare:
1) StoreDbUser
2) StoreFileUser
3) StoreCookieUser
4) StoreMemoryUser

senza toccare mai User. In genere è questo quello a cui si punta.

Mi piace invece l'idea dei meta-data che suggeriva daniele. E' un buon metodo per rendere un "User" espandibile con nuovi campi.

Possiamo prevedere un utente base che abbia: nome, cogmone, email; per poi ampliarlo attraverso i metadata con tutti i campi che ci interessano: seconda email, età, film preferito, numero di scarpe, etc...

Spero concordiate...

[andrea.paiola]

io trovo molto comodo avere in un array la configurazione dell'oggetto, così da non dover passare una variabile per ogni proprietà dell'oggetto... passo solo $conf['nome],$conf['cognome'] eccetera... metti che mi serve un campo in più e non dovrai toccare la classe, ma basterà aggiungere nella conf il dato in più... inoltre puoi eseguire facilmente azioni massive sulla configurazione, ciclando l'array

inoltre se mappi su db l'oggetto non sarai costretto ad una struttura fissa, ma essa dipenderà dalla configurazione

[LeaderGL]

Beh si, il modo in cui poi si passano/gestiscono i dati dipende dai gusti.

Però sono daccordo con te, in questo modo non devo riscrivere le intestazioni delle funzioni se decido di aggiungere o sottrarre un attributo, etc etc; anche se poi sarebbe da valutare a seconda dei casi...ci possono essere delle situazioni in cui per chiarezza ed altro è meglio magari avere l'elenco completo.

[andrea.paiola]

Originariamente inviato da LeaderGL
Beh si, il modo in cui poi si passano/gestiscono i dati dipende dai gusti.

Però sono daccordo con te, in questo modo non devo riscrivere le intestazioni delle funzioni se decido di aggiungere o sottrarre un attributo, etc etc; anche se poi sarebbe da valutare a seconda dei casi...ci possono essere delle situazioni in cui per chiarezza ed altro è meglio magari avere l'elenco completo.

si ma infatti non lo faccio per tutti gli oggetti, altrimenti per le azioni CRUD sulla conf degli oggetti conviene avere un oggetto generico da cui ereditare o avere in comune le interfacce