Oop - cosa va nel codice principale?

[zoc]

Ciao tutti. Come vedete dal titolo la domanda é un po' confusa perché io sono un po confuso!
Il fatto é questo. Sto studiando la programmazione oop. Sto capendo a livello teorico le classi e il loro significato. Penso di riuscire anche a capire possibili design di semplici applicazioni ( uso principalmente php ). Quello che non capisco é il flusso. Sembra quasi che per ogni cosa ci sia la necessitá di una classe, via via risalendo fino ad arrivare alla classe madre.
Ma allora nel codice principale cosa ci va? Le inclusioni dei file delle classi e l'istanza della classe madre? La classe madre poi penserá a ricreare le altre istanze delle altre classi se necessario?
sono un po confuso... Grazie e Help!

[paolino_delta_t]

Stai guardando alla programmazione OOP dal punto di vista sbagliato.

Lo scopo è quello di modularizzare il più possibile il codice, in modo da rendere gestibili programmi complessi. Una classe è, in linea di principio, un insieme di dati+codice che svolgono una specifica funzione, rappresentano uno specifico oggetto nell'universo del programma.

Se vuoi creare una calcolatrice, è logico pensare che dovrai creare una classe calcolatrice, la quale contiene tutto il codice necessario ( usabile tramite i metodi ) e le relative variabili necessarie a svolgere le funzioni che implementa. Ma la calcolatrice c'ha i tasti, e ogni tasto è a sua volta un oggetto, implementata tramite una classe.

Nel main devi metterci il meno possibile, giusto ciò che serve per istanziare le classi principali.

Riguardo le classi madri, tieni presente che queste non vengono usate per istanziare altre classi, ma sono semplicemente una versione più astratta delle classi figlie. Esempio: classe madre veicolo, classi figlie bicicletta, motorino, auto. La classe madre implementa tutti e soli i metodi relativi ad un veicolo astratto ( spesso vengono usate per definire solo l'interfaccia, ma non contengono codice ). Le classi figlie specializzano la classe madre, aggiungendo codice e metodi specifici per ogni tipo di veicolo.

[zoc]

Ciao Paolino. Hai centrato il punto.
Anche io sto cominciando a pensare che nel main ci deve andare il meno possibile, quello che non capisco e' quanto di deve andare. Da quello che sto intuendo ci vanno solo la creazione delle istanze necessarie a dare vita al programma.
E un'altra perplessita' mi viene pensando se sia giusto o meno istanziare classi da altre classi... mmm non so se mi riesco a spiegare.

Provo a fare un esempio.
Sto programmando un expert advisor in mql ( simil c++ ).
Il succo del programma e' che ci deve essere una classe che controlla le condizioni di mercato.
A seconda di quello che succede mi deve azionare una determinata serie di processi gestiti da altre classi ( controllo eventuali posizioni aperte, apertura posizioni ( richiamando un altra classe che regola il numero dei decimali ), chiusura posizioni, inserimento di indicatori o altro ).
In poche parole ci deve essere un direttore di orchestra in cui ci sono i percorsi logici. A seconda di quello che succede mi crea delle istanze di altre classi che hanno ruoli differenti.
Il tutto torna? Oppure nel main devo avere tutti i percorsi logici e nel caso instanziare le classi. Ma cosi facendo mi sembra di tornare un po' alla programmazione procedurale

grazie mille!

[paolino_delta_t]

La prima cosa da capire è che non c'è nessuna regola o legge riguardo la strutturazione di un programma OOP. Detto questo, la prassi è quella di creare classi che siano riusabili. Tieni in mente questo principio quando strutturi le classi e le loro interazioni. Una classe che può essere usata in un altro programma, ovviamente non può avere parte della sua logica fuori dalla classe stessa, ma deve avere tutto quello che le serve internamente.

Riguardo l'istanziare altri oggetti dall'interno di una classe, è una relazione del tipo HAS-A. In pratica, usando una classe all'interno di un'altra classe, è come se la classe usata fosse un componente della classe che la usa ( così come una ruota è un componente di un auto ).

Ma ripeto, non esistono regole precise, bisogna affidarsi all'esperienza per stabilire come meglio strutturare la gerarchia delle classi.

Nel tuo caso specifico, la classe che controlla le condizioni di mercato può benissimo istanziare altre classi per svolgere attività specifiche. Ma potresti pure sviluppare tali funzionalità nel "main" ( che in fondo, da un punto di vista logico, altro non è che una classe pure lui ).

Piuttosto la difficoltà vera è nello sviluppare le altri classi e permettere che eventualmente possano interagire ( se è necessario ).

[zoc]

Ciao Paolino e grazie per i consigli.
Purtroppo sto facendo molta fatica ad entrare nell'ottica has-a, is-a e company.

Il dubbio principale è come fare a far interagire due classi e come decidere il metodo di connessione.
1) Nel costruttore della prima classe faccio un istanza della seconda ( ma leggendo in giro non viene molto sconsigliata questa strada a causa della possibile pesantezza del codice )
2) Faccio un istanza della seconda classe all'interno della prima, ma non nel costruttore, ovvero in un metodo.
3) Non creo istanze della seconda dalla prima, ma allora mi chiedo come sia possibile metterle in connessione. Forse solo nel main script.

Per esempio sto scrivendo un plugin di worpdress dove la classe principale mi fa determinate cose.
Una volta fatte le operazioni vengo reindirizzato alla prima pagina del plugin, dove vengono stampate le eventuali notice.
Per ora nel costruttore di questa classe principale ho anche anche:

if ( isset( $_GET['message'] ) ) add_action( 'admin_notices', array( $this, 'the_notice' ) );

e poi ho il metodo the_notice che mi stampa il messaggio giusto.
Vorrei provare a fare una classe che mi gestisca le notice, così da poterla riutilizzare in altri plugin e renderla indipendente.
Ma se creo l'istanza, nel costruttore della classe principale, è un po' come andare a sostituire la riga di codice scritta sopra... boh... sto fondendo!!

grazie ancora per la pazienza!

[Scara95]

Il tutto sta nell'organizzare il problema in componenti che risolvono problemi specifici.
Ad esempio per modellare il funzionamento di una posta potresti usare una gerarchia di classi del genere

Messaggio
+Lettera
+Pacco
+Telegramma

Persona
+Dipendente
 +Postino(Array(Messaggi), CasellePostaliDiCompetenza(CasellePostali))
 +Impegato

CasellaPostale(Array(Messaggi))

Posta(Array(Messaggi), Array(Dipendenti), CasellePostaliDiCompetenza(CasellePostali))

Alla fine nel codice principale istanzierai la Posta, i Postini, i Messaggi e le CasellePostali, ma darai tutto in gestione alla Posta che si organizzera come meglio crede in base alla sua logica interna, dividendo i messaggi e le caselle postali di competenza fra i vari postini.
Ai fini pratici sarebbero opportune delle modifiche, ma era per rendere l'idea. Come vedi ci sono diversi tipi di oggetti, ma alcuni ne usano altri altri invece sono un tipo più specifico di un tipo generico.

[paolino_delta_t]

Concordo con Scara. Prenditi un pò di tempo per fare uno schema come quello che ha fatto lui e cerca di realizzare la gerarchia più efficiente possibile.

Per rispondere alle tue tre domande sull'interazione tra oggetti, tutto dipende da come il problema è organizzato nella vita reale. Facevo l'esempio dell'auto e della ruota. Lì è chiaro che nel costruttore della classe auto ha perfettamente senso istanziare un oggetto della classe ruota.

Un altro esempio è quello di un programma con una GUI e la logica di business. Immagina che ad ognuna di queste due macro-entità faccio capo una classe specifica. E' ovvio che non ha alcun senso istanziare un oggetto di classe GUI all'interno della classe "logica di business" e viceversa.

In questo caso il codice che serve per far comunicare questi due mondi ( che dovranno comunicare, altrimenti i dati prodotti dalla logica di business non verranno mai visualizzati tramite GUI ) va nel cosidetto main. Occhio che il main lo puoi benissimo considerare come la classe principale ( root in gergo ), per cui si ritorna al discorso precedente, cioè nel paradigma OOP è tutto un gioco tra classi e oggetti.

[zoc]

ragazzi grazie mille per la pazienza!
ho capito che e' un processo lungo e l'unica cosa da fare e provare e riprovare continuandomi a documentare.
Ora sto guardando i design pattern, che praticamente danno una linea guida su come andare a progettare una struttura.
Il percorso continua!!!

grazie ancora