Passaggio da procedurale ad OOP

[Ketto93]

Salve,

Ultimamente mi vengono richiesti molti script in PHP per alcuni siti web e per mia fortuna chi me li ha richiesti non ci capisce un granchè. Creo script che ripetono sempre le stesse righe di codice e molte volte mi chiedo se non appesantisca troppo la pagina...
Vorrei quindi passare alla programmazione ad oggetti, così da rendermi anche più semplice la modifica e la lettura dei vecchi file.
Ho studiato per il mio primo semestre in Ingegneria Elettronica un libro di Java (qui l'indice del libro) e un po' di programmazione ad oggetti per quel linguaggio (cose base come la dichiarazione di variabili private, pubbliche e la dichiarazione di metodi all'interno della classe).
Cosa mi consigliate per cominciare il tutto in PHP? Al momento non ho una grande disponibilità economica tale da portarmi a comprare un libro cartaceo, quindi mi dovrò accontentare di qualcosa on-line gratuito.

Grazie mille per i consigli.

[longilineo]

le buone pratiche della programmazione a oggetti e i design pattern sono concetti che prescindono dal linguaggio.

Sebbene lo stesso non valga per l'implementazione che può variare più o meno leggermente da linguaggio a linguaggio di sicuro se sai quale approccio adottare l'implementazione è un problema secondario e troverai facilmente quello che ti serve cercando un pò online.

Considera che in alcuni casi è una cattiva pratica ricorrere troppo ossessivamente ai design pattern, in realtà serve tanta pratica ed esperienza.

[Ketto93]

Capisco e ti ringrazio per la rapida risposta.
Il fatto è che l'obiettivo che vorrei raggiungere è che ogni mio script realizzato abbia un suo "framework personale" sul quale fare riferimento (non so se mi sono spiegato )

[Longo8]

I libri cartacei servono a poco in questo ambito; più precisamente servono se vuoi sviluppare una vena critica sulla programmazione di un certo tipo riguardo un linguaggio leggendo ciò che viene detto su di esso.
Più che altro ti consiglierei di iniziare a leggere il manuale e qualche sito con degli esempi (ne è pieno il web) e man mano iniziare a farlo.
Altra soluzione è quella di rivolgerti ad un esperto (ma anche non molto esperto) perchè ti aiuti, ovviamente nessuno fa niente per niete

[Santino83_02]

Originariamente inviato da Ketto93
Capisco e ti ringrazio per la rapida risposta.
Il fatto è che l'obiettivo che vorrei raggiungere è che ogni mio script realizzato abbia un suo "framework personale" sul quale fare riferimento (non so se mi sono spiegato )

E quindi che vuoi sapere, come si realizza un framework? Ti suggerirei di "tradurre" il procedurale in oop degli script che hai già realizzato... alla fine otterrai un insieme di classi che svolgono vari compiti, una volta che le hai magari ci fai un framework sopra...più che altro ti suggerirei per ora di puntare ad avere classi Utility per realizzare i compiti che ora copi/incolli in giro

[Santino83_02]

ah dimenticavo:

fai finta che questa frase non sia mai stata pronunciata: "Considera che in alcuni casi è una cattiva pratica ricorrere troppo ossessivamente ai design pattern, in realtà serve tanta pratica ed esperienza."

[longilineo]

Originariamente inviato da Santino83_02
ah dimenticavo:

fai finta che questa frase non sia mai stata pronunciata: "Considera che in alcuni casi è una cattiva pratica ricorrere troppo ossessivamente ai design pattern, in realtà serve tanta pratica ed esperienza."

Non sono d'accordo l'impegno nello scrivere buon codice flessibile e facilmente espandibile è conseguenza di buona remunerazione occorre giudizio e sapere quando è meglio farsi poche pippe mentali e limitarsi a fare il giusto.

L'altro giorno un amico che sviluppa da tanti anni per un progetto più grosso del solito ha deciso di implementare Repository. A una settimana da quando aveva scritto il codice aveva problemi a ricordare come aveva strutturato il codice e a dirla tutta il lavoro non è che fosse poi così grande o contenesse una mole di dati tale da richiedere chissà quale scalabilità.
Questo è un esempio di come sia meglio a volte farsi poche pippe mentali e non strafare.
I design pattern sono strumenti potenti quando servono e quando uno sviluppatore li ha fatti propri e non è una cosa tanto semplice o che si acquisisce dall'oggi al domani.
A contrario di quanto si possa pensare usare i design pattern non consente di scrivere codice più semplice o più breve.

Ciò non toglie che alcune pratiche siano da evitare come la peste, ma per questo il più delle volte basta il buon senso.

[Ketto93]

Ok, quindi da quel che ho capito, mi consigliate di creare oggetti "utili" per i miei progetti (es: oggetto per l'interazione con il db, oggetto per l'interazione con i form, etc..) ??

[Longo8]

Originariamente inviato da Ketto93
Ok, quindi da quel che ho capito, mi consigliate di creare oggetti "utili" per i miei progetti (es: oggetto per l'interazione con il db, oggetto per l'interazione con i form, etc..) ??

Si ovvio. E' proprio questo il motivo per cui è nata la programmazione ad oggetti.
Perchè è molto più semplice da capire e si può riutilizzare quando vuoi senza scrivere altro codice.

[Santino83_02]

Originariamente inviato da longilineo
Non sono d'accordo l'impegno nello scrivere buon codice flessibile e facilmente espandibile è conseguenza di buona remunerazione occorre giudizio e sapere quando è meglio farsi poche pippe mentali e limitarsi a fare il giusto.

L'altro giorno un amico che sviluppa da tanti anni per un progetto più grosso del solito ha deciso di implementare Repository. A una settimana da quando aveva scritto il codice aveva problemi a ricordare come aveva strutturato il codice e a dirla tutta il lavoro non è che fosse poi così grande o contenesse una mole di dati tale da richiedere chissà quale scalabilità.
Questo è un esempio di come sia meglio a volte farsi poche pippe mentali e non strafare.
I design pattern sono strumenti potenti quando servono e quando uno sviluppatore li ha fatti propri e non è una cosa tanto semplice o che si acquisisce dall'oggi al domani.
A contrario di quanto si possa pensare usare i design pattern non consente di scrivere codice più semplice o più breve.

Ciò non toglie che alcune pratiche siano da evitare come la peste, ma per questo il più delle volte basta il buon senso.

ahahahahah bello sto discorso! Cioè tu mi porti d'esempio uno che "sviluppa da tanti anni" e che invece di usare un framework già pronto per la persistenza se lo implementa a mano? E cmq, prima di applicare un pattern o un altro uno dovrebbe farsi un pò di conti e vedere i pro e contro di ogni decisione.

I design patterns non servono per scrivere codice più semplice o breve, anzi in genere nel 99% dei casi è più "complesso" e lungo, ma servono semplicemente a risolvere i problemi per cui sono pensati e a non dover reinventare la ruota ad ogni nuovo progetto.

Su una cosa ti dò ragione: programmare nn vuol dire applicare a mani basse design patterns, anzi l'idea che ci sia un design pattern per ogni problema è sbagliata, quindi vada per il "buon senso" (chiamiamolo "buona programmazione" non credi?) e un programma scritto al 50% da patterns e al 50% da una buona progettazione