Se l'app per utilità a scopo singolo utilizza una classe

Devi eseguire calcoli più accurati per un importo degli scopi . Per gli utenti finali, la tua utilità ha un unico scopo, giusto, ma per il suo codice non è così.

Vediamo, c'è la parte che hai indicato DoIt - ha lo scopo unico di fare funzione di utilità, bene, ma oltre c'è una parte che hai chiamato Main e ha uno scopo proprio, separato - serve come < a href="http://en.wikipedia.org/wiki/Main_function_%28programming%29"> punto di ingresso del programma .

Vedete, il codice ha almeno due scopi, non uno (il secondo non è visibile agli utenti finali ma i manutentori del vostro codice lo vedranno molto bene). E, se ti capita di avere degli argomenti da linea di comando passati all'utilità, ci sarà anche un codice con lo scopo terzo di analizzarli, vai a capire.

Va bene, c'è più di uno scopo e servirli in una classe devia da un principio di responsabilità singola (SRP) - da questa prospettiva hai pieno diritto di dividerlo, devi solo decidere se la deviazione è giustificata o meno.

Supponiamo che se il tuo codice per gestire gli argomenti della riga di comando è solo 5-10 linee, i vantaggi di mantenerlo vicino probabilmente sono la cieca adesione ai principi teorici. O forse il tuo codice DoIt è così pulito, elegante e compatto che avere anche solo una piccola quantità di codice di analisi non correlato ti fa sentire "sporco"? se è così, non trattenere il tuo dolore, dividerlo e sentirti meglio - il vero scopo di SRP è giustificare mosse del genere.

Un ragionamento simile si applica quando decidi se mantenere il punto di ingresso o dividerlo. Se tutto il tuo codice è in un singolo file, è ragionevole presumere che chiunque lo stia leggendo vedrà che anche quel punto di ingresso è lì. Se ne hai di più, beh, ha senso pensarci un po 'di più.

Per prima cosa mi sento piuttosto frustrato quando inserisco una base di codice non familiare. Devo perdere tempo a cercare di capire se iniziare a leggere il codice da MyVeryImportantClass o da MyAbsolutelyNecessaryClass . In casi del genere, sarei molto grato se ci fosse un semplice file separato (comunque piccolo) MainClass con cui potrei iniziare senza pensare.

Il tuo obiettivo finale è produrre codice pulito, affidabile e di facile lettura. Ciò significa gestire la complessità. Le classi ti aiutano a farlo creando livelli di astrazione in modo che tu possa guardare ad un'interfaccia pubblica semplice e non essere preoccupato da tutti i bulloni che fanno fare alla classe la cosa giusta.

Tuttavia devi anche ricordare che "i livelli di astrazione possono risolvere qualsiasi problema tranne che per avere troppi livelli di astrazione" (non la mia citazione ma non ricordo dove l'ho vista).

Quindi il mio consiglio sarebbe di iniziare in piccolo e seguire qualche altro buon consiglio che non è mio:

1. Falla funzionare
2. Fallo funzionare correttamente
3. Fai in modo che funzioni velocemente (questo probabilmente non si applica qui)

Se una funzione principale è abbastanza semplice, seguitela. Se noti che sta iniziando a crescere e trasformarsi, prendi una porzione di funzionalità e rendila una classe (o 2 o 20)

Ecco una regola empirica quando si tratta di decidere tra programmazione orientata agli oggetti e procedurale:

Use object-oriented programming (OOP) when the overall complexity of a system exceeds the complexity of its individual algorithm.

Se il flusso di controllo della tua applicazione è molto complesso, passa a OOP. Altrimenti, stai con la programmazione procedurale.

Entrambi. Mi sono ritrovato a dover iniziare ripetutamente con una cosa procedurale semplice, che è diventata una soluzione OOP completa composta da diverse classi e interfacce. Secondo me, è proprio così che le cose si evolvono nel mondo reale e non c'è niente di male in questo. Accade a causa di requisiti avanzati, a causa di una migliore comprensione del dominio del problema o per altri motivi.

Il punto cruciale durante questo processo è sviluppare un senso interiore, una sorta di rivelatore mentale, o forse una certa regola (come " se va oltre le 2000 righe, refactory in classi " ) che suona le campane di allarme proprio nel punto, dove il codice inizia a diventare troppo complesso per le procedure, ma è comunque abbastanza facile da rifattorizzare in classi.

Una volta arrivato a quel punto, il resto è facile.