Come dividere il progetto OO in pacchetti?

0

Sono un programmatore hobbista che lavora sui miei progetti. Io uso Java.

Fino a poco tempo fa il mio progetto medio era solo 1000 LoC. Il mio ultimo progetto tuttavia è più grande e sta iniziando a superare 1500 LoC. Stimo che raggiungerà circa 2000.

Non ho mai organizzato le mie lezioni in pacchetti. Tutti erano sempre nel pacchetto predefinito e funzionava perfettamente.

Tuttavia, man mano che i miei progetti crescono e la quantità di lezioni aumenta, sto iniziando a sentirmi disorganizzato.

La mia domanda è: in che modo si divide le sue lezioni in pacchetti? Ciò che intendo è, in base a quali criteri dividi le classi?

La classe 'parte' dell'app? Aka GUI in un pacchetto, la logica di business nell'altro, il networking, ecc.? O forse classi di alto livello rispetto a classi di livello inferiore? classi Aka che eseguono lavori concreti e specifici in pacchetti propri e classi "architettoniche" che li legano tutti insieme nei propri pacchetti? O forse semplicemente dividi in base ai criteri di "cosa ti sembra giusto e organizzato" specificamente per te?

Ad esempio, sto lavorando a un'app che crea musica. È fondamentalmente diviso in due sistemi principali: il sistema che crea la musica e il sistema che visualizza la GUI e controlla l'altro sistema (cioè un pulsante che preme in quel sistema che attiva l'altro sistema).

Il sistema di creazione musicale è anche diviso in due sistemi: per creare melodie e creare progressioni di accordi. E la parte della generazione di progressione di accordi, tra le altre cose contiene un gruppo di classi che fungono da algoritmi intercambiabili per un modello di strategia coinvolto (cioè classi utilizzate per uno specifico dettaglio di implementazione).

Naturalmente ci sono classi di livello superiore e di livello inferiore coinvolte in ogni sistema. Ad esempio il sistema di generazione progressione contiene una classe ProgressionGenerator , che è di alto livello e lega l'intero sistema. Ha anche una classe Chord che è molto più di basso livello (ad esempio, si occupa di riprodurre note specifiche).

Il modo in cui organizzerei questo in classi è così:

Il sistema di creazione musicale in un unico pacchetto, il sistema GUI che controlla l'altro sistema in un altro pacchetto.

Rispetto alla creazione della melodia in un sotto-pacchetto del pakage della creazione musicale e alla creazione della progressione in un sotto-pacchetto differente.

E all'interno del sotto pacchetto di creazione della progressione, un altro sottopackage che contata le classi utilizzate per quel modello di strategia coinvolto da qualche parte in quel sistema.

Questo suona come un buon approccio per organizzare le cose in pacchetti? Con quali criteri dividi le classi in pacchetti? Con "cosa sembra giusto" o con termini più tecnici?

    
posta Aviv Cohn 10.05.2014 - 13:39
fonte

3 risposte

1

In generale, tendo ad organizzarmi in base alla responsabilità / funzione. Ma dipende totalmente dal tuo progetto concreto e dall'architettura, e qui non esiste una singola risposta / linea guida definita. Per non parlare del fatto che il gusto personale svolge anche un ruolo importante qui.

Il mio suggerimento: guarda come le altre persone / organizzazioni lo stanno facendo. Approfitta di Open Source. Cerca progetti Java su github , ad esempio, e sfoglia la loro fonte. Avrai un'idea di approcci diversi e potrai decidere quali ti piacciono.

    
risposta data 10.05.2014 - 14:53
fonte
3

Non esiste una risposta alla tua domanda e dipende dall'architettura della tua applicazione. Questa domanda potrebbe essere chiusa.

2000 Le linee di codice sono in realtà piuttosto piccole. Come dividi il tuo programma in classi è la stessa domanda di come faccio programmazione orientata agli oggetti . Probabilmente dovresti iniziare con Wikipedia e poi comprare un libro sull'argomento o trovare un corso online.

In termini di linee guida potresti iniziare con SOLID e Principi di imballaggio

Dai Principi di Imballaggio, il Reuse-release equivalence principle (REP) afferma:

REP essentially means that the package must be created with reusable classes.

Cioè, se non è necessario riutilizzare, non è necessario comprimerli in modo indipendente dalla propria applicazione.

    
risposta data 10.05.2014 - 14:32
fonte
0

Organizza e modella le tue classi in modo che tu possa OTTENERE I BENEFICI di OOP e SOLID, ecc.

Incapsulamento e occultamento dei dati. Esistono molti modi per organizzare le cose in classi strettamente legate l'una all'altra e soddisfare ancora la definizione "ufficiale" di OOP. I linguaggi OOP e i principi di progettazione rendono più semplice e forniscono gli strumenti per ottenere l'incapsulamento e l'occultamento dei dati, e di fatto rendono difficile creare un pasticcio così strettamente legato e dipendente. Cerca di capire PERCHÉ vorresti farlo nel modo OOP, comprendendo quali sono i metodi OOP che potrebbero darti, in futuro.

Polymorphism e riutilizzo. Ancora una volta c'è un milione di modi per estrarre qualche astrazione da quasi ogni 'cosa' o concetto. Il punto di OOP è che puoi ottenere un beneficio da questo filosofare. È possibile ottenere il riutilizzo, la generalizzazione, meno codice per una maggiore funzionalità. Meno manutenzione, ecc.

Questi sono alcuni buoni. Guarda il resto dell'OOP e SOLID e decidi se puoi davvero ottenere un beneficio e lascia che ti porti ad una strategia di organizzazione naturale.

Inoltre, ci sono molte volte in cui i principi OOP non ti aiutano veramente; almeno nelle dimensioni e nella maturità attuali del prodotto; semplicemente rendono le cose più complicate. Ma questa adesione, "in linea di principio", può rendere il tuo prodotto più a prova di futuro. Un buon esempio potrebbe essere qualcosa come Dependency-Inversion / Injection, o forse qualcosa come Factory patterns. Spesso eccessivo, ma quando la tua app cresce, ringrazia le stelle celesti che hai messo quell'amo (DI, Factory) lì nella versione 1.

    
risposta data 10.05.2014 - 16:22
fonte

Leggi altre domande sui tag