Perché è buono dividere un programma in più classi? [chiuso]

La risposta più semplice è che se metti tutto in una classe, devi preoccuparti di tutto contemporaneamente quando stai scrivendo un nuovo codice. Questo potrebbe funzionare per piccoli progetti, ma per applicazioni enormi (stiamo parlando di centinaia di migliaia di linee), questo diventa presto quasi impossibile.

Per risolvere questo problema, suddividi parti di funzionalità nelle proprie classi e incapsula tutta la logica. Quindi, quando vuoi lavorare sulla classe, non devi pensare a cos'altro sta succedendo nel codice. Puoi concentrarti solo su quel piccolo pezzo di codice. Questo è inestimabile per lavorare in modo efficiente, tuttavia è difficile apprezzarlo senza lavorare su applicazioni enormi.

Naturalmente ci sono innumerevoli altri vantaggi a rompere il tuo codice in parti più piccole: il codice è più gestibile, più testabile, più riutilizzabile, ecc., ma il più grande vantaggio è che rende massicci i programmi gestibili riducendo la quantità di codice a cui devi pensare contemporaneamente.

Bene, la risposta più semplice potrebbe essere "Aiuta ad organizzare le cose". Se non altro, puoi confrontarlo con le sezioni di un taccuino: è semplicemente più semplice se hai "tutte le cose relative all'interfaccia utente" qui e "tutte le cose relative al gameplay".

La risposta più sofisticata è che dividere il lavoro non è solo conveniente, ma molto importante per gestire la complessità (e "gestire la complessità" è praticamente il nome del gioco quando si parla di programmazione). Le classi o altri tipi di modulo ti consentono di "separare le preoccupazioni". Non solo sai dove cercare "cose relative all'interfaccia utente" ma puoi essere sicuro che se vuoi apportare una modifica all'interfaccia utente, puoi semplicemente farlo in un unico punto e non devi preoccupati "ora, è il posto solo dove ho impostato il mio font su Comic Sans?". E tu puoi fare un cambiamento e sapere che l'effetto di quel cambiamento è solo a qualsiasi (piccolo) scopo è appropriato. Se tutto è in una singola classe o modulo, essenzialmente tutto è globale e questo rende le cose molto difficili da ragionare.

Nel caso specifico delle classi come tipo di modulo software, c'è anche un sacco di comportamenti associati a una classe, e molti sviluppatori nel paradigma orientato agli oggetti trovano molto utile avere nomi significativi associati alle classi quel gruppo ha collegato le funzioni insieme. Quindi probabilmente non avresti una classe UI , probabilmente avresti una classe Button . C'è un intero corpo di conoscenze e tecniche associate alla progettazione di classi orientate agli oggetti ed è il modo più comune di organizzare grandi sistemi nella programmazione tradizionale.

Questa è una buona domanda! Semplice e ben chiesto. Beh ... la risposta non è così facile da capire per uno studente che sta studiando informatica e probabilmente non conosce in OO profonda e probabilmente non ha esperienza di lavoro.

Quindi, posso rispondere descrivendo uno scenario e facendoti immaginare come il software multi-classi sia migliore del software monolitico (prodotto da una sola classe):

• Readability : è molto più difficile sfogliare e scrivere codice in un file con 10000 righe rispetto a diversi file piccoli e organizzati.
• Riutilizzabilità : se scrivi una singola classe, puoi inserire la duplicazione del codice . Ciò significa più linee di codice e probabilmente più bug (!)
• Testabilità : cosa ne pensi di testare una singola funzionalità? Se tu isolare una funzionalità logica in una classe, la tua vita sarà più facile.
• Mantenibilità del codice : puoi correggere un bug o migliorare la funzionalità con le classi di moltiplicazione in un'unica posizione: le belle classi piccole.
• Struttura del progetto : oooooh puoi immaginare quanto sia brutto a apparirà un progetto con un solo file sorgente?

Ci sono molte buone risposte qui, e sono decisamente d'accordo con loro, ma sento che c'è qualcosa di più degno di nota.

Al momento, come hai detto, stai lavorando da solo sul tuo progetto. Tuttavia, in futuro, ci saranno momenti in cui dovrai lavorare in un ambiente di squadra. Durante quei tempi, dividerai il lavoro (presumibilmente il progetto sarà abbastanza grande). Di conseguenza, ci sono alcune opzioni (credo proprio due principali ) diverse. Puoi avere più copie di un file e lavorare su "pezzi" separati del file e quindi "combinarli" con copia e incolla successivamente e quindi modificare in modo che le tue parti possano lavorare insieme, oppure puoi dividere quei "pezzi" piuttosto facilmente in classi diverse e discuti come scriverai quelle classi e userai quella conoscenza per andare avanti.

Ci sarà ancora bisogno di lavorare per integrare tutti i pezzi separati, ma sarà molto più facile da mantenere. Perché il file x contiene codice y e questo è il codice che sai che devi modificare. Questo entra nella cosa dell'organizzazione di cui parlano la maggior parte delle altre risposte.

In possesso di un programma in testa. Link da Giorgio

In effetti ciò che hai fatto è una programmazione procedurale reinventata. Intendiamoci, è possibile scrivere software in questo modo e probabilmente al compilatore non interesserà. Per molti anni questo è stato il modo in cui sono state fatte le cose fino a quando i computer sono diventati più veloci e gli strumenti sono migliorati.

Detto questo se dividi il tuo codice in diverse unità logiche (Classi, moduli, ecc.) è che puoi avere molte brevi parti di codice facili da capire. che può essere mantenuto in seguito. Molti dei miei moduli sono meno di 20 righe di codice. So che tutto il codice su un determinato argomento si trova in un posto specifico. Significa anche che se qualcun altro si unisce al progetto, sarà molto più facile trovare le cose.

Come Gerald Sussman ha detto che i nostri programmi dovrebbero essere scritti per primi in modo che le persone possano leggerli e secondi in modo che il computer possa eseguirli. (E se non hai ancora letto "Struttura e interpretazione dei programmi per computer, dovresti)

Uno usa più classi perché quando entri in una roba più grande scoprirai che non c'è semplicemente modo di tenere traccia di tutto quando si tratta di una grande pila di codice.

Devi semplicemente dividere e conquistare per gestirlo.

La programmazione orientata agli oggetti è la migliore idea che abbia mai visto in programmazione. Ma non è la cosa migliore in tutti i casi, hai bisogno di un po 'di esperienza di programmazione per vederne il significato, e molte persone affermano di fare OOP quando non lo sono.

Se riesci a cercare "programmazione strutturata" probabilmente troverai qualcosa di più immediatamente utile. (Assicurati di leggere sulla programmazione strutturata vecchia , i termini vecchi spesso hanno significati nuovi e più elaborati e non hai ancora bisogno di niente di speciale.) Questo è un concetto piuttosto semplice di rompere il tuo programma in subroutine , che è molto più facile che scomposizione in oggetti. L'idea è che il tuo programma principale è una breve routine che chiama subroutine ("metodi" in Java) per fare il lavoro. Ogni subroutine conosce solo ciò che viene detto dai suoi parametri. (Uno di quei parametri potrebbe essere un nome di file, quindi puoi imbrogliare un po '.) Quindi, guardare l'intestazione di una subroutine / metodo ti dà una rapida idea di cosa fa e sapere quali sono i metodi nel programma principale vedi cosa it fa quasi a colpo d'occhio.

Quindi tutte le subroutine sono suddivise in modo simile fino a quando poche righe di codice senza chiamate di metodo faranno il lavoro. Un programma principale che chiama alcuni metodi, ognuno dei quali chiama alcuni metodi, ognuno dei quali ... Giù a piccoli metodi semplici che fanno il lavoro. In questo modo, puoi guardare qualsiasi parte di un programma molto grande (o un piccolo programma) e capire rapidamente cosa fa.

Java è progettato in modo specifico per le persone che scrivono codice orientato agli oggetti. Ma anche il più intenso programma OO utilizza una programmazione strutturata e puoi sempre sovvertire qualsiasi lingua. (Ho fatto OO in chiaro C.) Così puoi fare SP, o qualsiasi altra cosa, in Java. Dimentica le lezioni e concentrati su grandi metodi che possono essere suddivisi in piccoli e gestibili. Devo aggiungere che SP ti aiuta molto a permetterti di riutilizzare il tuo codice, e anche con il DRY (google, ma significa "Non ripeterti").

Spero di aver spiegato perché e come suddividere il tuo codice in più parti senza introdurre "classi". Sono una grande idea e sono l'ideale per i giochi e Java è un ottimo linguaggio per OOP. Ma è meglio sapere perché stai facendo quello che stai facendo. Lascia OOP da solo fino a quando non inizia a dare un senso a te.

Uno dei vantaggi è la riutilizzabilità. Un programma è fondamentalmente un gruppo di istruzioni raggruppate insieme. Scoprirai che alcune di quelle istruzioni sono adatte anche ad altri programmi.

Diciamo che fai una partita di salto. In seguito, quando decidi di fare un gioco di cannone, scopri che il calcolo della fisica che hai utilizzato nel gioco del salto è molto utile qui.

Quindi, invece di scriverlo di nuovo, o peggio di copiarlo e incollarlo nel nuovo programma, lo trasformi in una classe. Quindi la prossima volta che realizzi un altro gioco in cui la meccanica del gioco richiede la fisica, puoi semplicemente riutilizzarla. Ovviamente questo è troppo semplificato, ma spero che abbia senso.

Prima di tutto, si noti che sono un C ++ e Python, non Java, quindi alcuni di questi potrebbero non essere applicabili in modo completo. Per favore correggimi se faccio alcune ipotesi errate su come funzionano le classi in Java.

Le classi sono principalmente utili quando vengono istanziate. Una classe di cui non sono state create istanze è in realtà solo uno spazio dei nomi glorificato. Se utilizzi tutte le tue classi in questo modo, in effetti, i vantaggi di spostare oggetti dallo spazio dei nomi allo spazio dei nomi potrebbero sembrare insignificanti: al massimo, vincerai avendo alcuni dati privati in ognuno e quindi incapsulando un po 'le cose.

Tuttavia, non è qui che le classi brillano. Considera la classe String : potresti avere tutte le stesse funzioni usando char matrici e alcune funzioni statiche. A questo punto, le funzioni ti danno un po 'di sicurezza in più e zucchero sintattico. Puoi scrivere string.length() invece di length(char_array) ; non è un grosso problema, ma a molte persone piace ancora. Inoltre, sai che se qualcuno ti ha dato un String , è stato creato con il costruttore String e deve funzionare con la funzione length - se la versione dell'array non può gestire un personaggio allora non ha modo di impedirti di metterlo lì dentro.

Non è ancora così, però. Il punto chiave è che le classi raggruppano i dati e le funzioni che operano su di essi e ne astraggono entrambi. Quando hai un metodo void f(Builder b) sai che riceverai un Builder e puoi aspettarti che supporterà determinati comportamenti. Tuttavia, non si conosce nulla dei dati o delle funzioni in esecuzione: infatti, le definizioni per entrambi potrebbero non essere ancora scritte mentre si scrive e si compila f .

Il primo punto da capire è quindi che le classi rendono conveniente passare i dati assicurandosi che non sia rotto. Il secondo punto è che sia i dati che le funzioni (implementazioni) di un oggetto sono qualcosa sull'oggetto, non qualcosa che puoi semplicemente dire dal suo tipo.

L'intera idea si basa su una regola generale denominata divide and conquer .
Questo paradigma può essere usato quasi ovunque; dividi un problema in problemi più piccoli e poi risolvi questi piccoli, semplici e noti problemi.
Dividere il tuo programma in classi è uno dei tipi di divisione che ha iniziato a diventare comune nell'ultimo decennio. In questo paradigma di programmazione modelliamo il nostro problema con alcuni oggetti e proviamo a risolvere il problema inviando messaggi tra questi oggetti.
Alcune persone potrebbero dire che questo approccio è più facile da comprendere, espandere ed eseguire il debug.
Anche se alcune persone non sono d'accordo:)

Non si tratta di dividere un programma in classi, ma di come modellare la tua applicazione, cioè come visualizzi parti della tua applicazione. La divisione delle cose è solo un meccanismo che usiamo per capire meglio le cose complesse. Non è solo con la programmazione. Immagina una scheda con molti fili intrecciati tra loro, formando una struttura complessa con ogni filo che si collega da qualche parte (codice spaghetti). Dovrai seguire ogni filo fino alla fine per capire le connessioni. Al contrario, immagina fili raggruppati e codificati a colori in base alla loro funzione. Diventa molto più facile risolvere le cose.

L'idea è che non inizi con un programma lungo e poi lo dividi in classi. Ma prima modellate la vostra applicazione in termini di oggetti / classi e poi connetteteli per creare applicazioni.