Ideal OOP Design

1

Dopo aver appreso il design OOP, ho scoperto che il mio modo di programmare non era corretto. Uno dovrebbe convertire entità fisiche o componenti separabili logicamente in classi che sono riutilizzabili e hanno il loro comportamento e proprietà. Non si deve semplicemente convertire tutte le entità in oggetti, perché ciò sarebbe davvero ingombrante.

Se sto sviluppando un sistema di filtri in console che controlla se il mio programma vuole un intero da utente allora deve essere un numero intero, non dovrebbe essere un valore corrotto dall'errore di digitazione dell'utente o dall'input errato. Per tale scopo dovrei creare una classe separata per gestire tutto il suo funzionamento e i suoi comportamenti, distinti dalla console che funziona in modo che se in seguito voglio usare quel sistema nella GUI, allora posso.

Ma la creazione di oggetti per tale classe non ha senso, così ho finito per creare tutto ciò che era statico dai membri dei dati a funzioni che sembravano piuttosto creare un disegno procedurale in qualche modo con le classi. Con un solo vantaggio, tutti i dati sono stati raggruppati in unità per classi note come incapsulamento.

La mia domanda è, va bene avere tali interfacce con le classi o si deve tornare a procedurale per loro? Spesso mi trovo ad affrontare problemi con la progettazione durante l'applicazione del design OOP ai meccanismi di lavoro del mio codice.

Modifica-1

Lascia che ti spieghi la domanda in modo più preciso supponi di voler creare un sistema di filtri. Quindi prendi input da stringhe dall'utente e poi controlli se i dati contengono numeri o alfa o se i dati sono veramente puri, non una combinazione di alfa e numeri che rendono il codice più robusto e privo di errori. Per questo ho creato una classe in cui è necessario passare una stringa e controllerà il tipo di dati che è, in base al suo funzionamento interno mentre lavora con tale meccanismo creando oggetti multipli della classe del sistema filtro non ha senso perché se lo si fa quindi tutti gli oggetti sarebbero identici in funzionalità e utilizzo. Il che significa chiaramente che non ci sarebbe alcun vantaggio se la classe avesse più istanze. Così ho finito per creare tutto statico perché non volevo creare oggetti

    
posta Harshul Sharma 11.06.2016 - 11:26
fonte

2 risposte

0

La cosa che hai chiesto è chiamata funzione di utilità .

Ci sono molte informazioni, opinioni e informazioni errate sul ruolo e sulla proprietà delle funzioni di utilità nel mondo orientato agli oggetti.

Nel tuo esempio, la funzione di utilità è molto semplice, quindi avrei preferito conservarla come funzione di utilità n. 1 . La tua funzione di utilità ha una firma molto semplice:

# 1 : non è un membro di una classe. Tuttavia, potrebbe ancora essere inserito in uno spazio dei nomi.

bool ValidateNumber(const std::string& str);

Quando la funzione di utilità viene utilizzata nel contesto di I / O utente (in particolare I / O utente basato su console), in genere viene coinvolta la seguente logica:

  • Sottoprogramma "chiedi all'utente il numero e ripeti fino al successo"
    • Stampa prompt
    • Accetta una riga di testo dall'utente
    • Convalida l'input (richiamando la funzione di utilità sopra)
    • Se la convalida fallisce,
      • Stampa un messaggio di errore che spiega cosa non va
      • Passa al "prompt di stampa", ecc.
    • Se la convalida ha esito positivo, il numero convertito viene restituito da questa subroutine.

Si noti che questa subroutine ha molti stati e logica. Ha una complessità sufficiente da poter essere trasformato in una classe e istanziato in un oggetto. Potrebbe anche essere reso personalizzabile, ad es. consentendo a un'applicazione di creare un'istanza di due oggetti, ognuno con un prompt diverso.

Nell'interfaccia utente grafica (GUI), è più frequente vedere una subroutine che richiede il numero di essere racchiusa in un oggetto. Questo perché nel mondo della GUI, un elemento della GUI che richiede un numero avrà alcuni disegni unici, in particolare uno "spinbox" (una coppia di frecce su / giù che consentono all'utente di incrementare / decrementare il numero quando si fa clic). Ciò favorisce strongmente la conversione della subroutine in un oggetto.

    
risposta data 11.06.2016 - 12:55
fonte
1

È perfettamente corretto evitare di creare classi e utilizzare funzioni statiche. Il fatto che tu abbia bisogno di una sola istanza è effettivamente un'indicazione che non hai davvero bisogno di definire una classe. Questo è particolarmente vero in C ++, che è un linguaggio multi-paradigma. Se è necessario raggruppare diverse funzioni di filtro, definire uno spazio dei nomi.

    
risposta data 11.06.2016 - 12:40
fonte

Leggi altre domande sui tag