Programmazione non orientata agli oggetti in linguaggio orientato agli oggetti [chiuso]

14

Recentemente mi è stato assegnato un compito di creazione di un calcolatore con funzioni addizione, sottrazione, moltiplicazione, divisione e potenza utilizzando Programmazione orientata agli oggetti . Ho completato con successo questo compito. Comunque in seguito ho riprogrammato l'intero programma senza usare la tecnica / metodo orientata agli oggetti.

La cosa che ho notato è che la lunghezza del mio codice è stata ridotta in modo significativo ed è stato abbastanza comprensibile. Quindi la mia domanda qui è quando dovrei usare la programmazione orientata agli oggetti? Va bene creare programmi senza Orientamento di oggetti in linguaggio orientato agli oggetti? Gentilmente aiutami con questo.

PS: Non sto chiedendo qui di dirmi meriti di programmazione orientata agli oggetti rispetto alla programmazione procedurale.

    
posta FaizanRabbani 23.12.2014 - 05:24
fonte

3 risposte

24

C ++ non è "solo" un linguaggio OO, è un linguaggio multi-paradigma. Quindi ti permette di decidere a favore o contro la programmazione OO, o di mixarli entrambi. L'uso delle tecniche OO aggiunge più struttura al tuo programma, dal quale potrai beneficiare quando il tuo programma raggiunge una certa dimensione o complessità. Questa struttura aggiuntiva, tuttavia, ha il prezzo di ulteriori righe di codice. Quindi per i programmi "piccoli" il modo migliore è spesso implementarli prima in uno stile non OO, e aggiungere sempre più tecniche OO più tardi quando il programma inizia a crescere nel corso degli anni (il che probabilmente non succederà a "esercizio"). "programmi, ma è il tipico ciclo di vita per molti programmi di business).

La parte difficile è non perdere il momento in cui la complessità del tuo programma raggiunge le dimensioni che richiedono più struttura. Altrimenti finirai con un enorme mucchio di spaghetti code.

    
risposta data 23.12.2014 - 07:22
fonte
10

How do professional programmers make judgement call on whether to go for OOP or not? It would be really helpful for me.

Per me, ci sono due punti decisionali. In primo luogo, a volte sarà ovvio all'inizio. Ci saranno molti tipi simili che condividono tutti i metodi comuni che differiscono ampiamente nei loro dettagli di implementazione. Ad esempio, stavo creando un sistema di flusso di lavoro e avevo bisogno della capacità di implementare attività arbitrarie. Per eseguire l'attività, ho implementato una classe base da cui ogni attività è stata ereditata, con un metodo astratto Execute() . Le classi ereditanti hanno fornito l'implementazione, ma il sistema del flusso di lavoro potrebbe iniziare l'esecuzione senza sapere nulla sul tipo di attività in esecuzione.

La maggior parte dei progetti non è così chiara. Il secondo punto di decisione è quando un sottoinsieme del progetto è cresciuto in un enorme groviglio di istruzioni if-then o di istruzioni switch-case, e specialmente quando quelle istruzioni if-then richiedono un sacco di codice di installazione per funzionare correttamente. Sento che sto iniziando a perdere la logica di quello che sto cercando di realizzare, e il codice inizia a sentirsi fragile. A quel punto, di solito è un segno che è il momento di rifattorizzare il codice in classi base con implementazioni specifiche.

Gran parte del passaggio a uno stile orientato agli oggetti rispetto a uno stile funzionale è la conversione delle istruzioni if-then in istruzioni "esegui questa azione". Invece di un enorme insieme di istruzioni if-then, devi solo dire al codice di eseguire la sua azione. L'azione effettivamente eseguita dipende dall'implementazione fornita.

Ad esempio, ecco lo stile funzionale nello pseudocodice in stile C #:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

Ma forse potresti riscriverlo a qualcosa di simile:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

E poi il codice stesso:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

Ora, quando c'è un codice molto piccolo dentro l'if-then, questo sembra un sacco di lavoro per non avere alcun beneficio. E quando c'è un codice molto piccolo nell'e-then, è corretto: è molto lavoro per il codice che è più difficile da capire.

Ma lo stile orientato agli oggetti brilla davvero quando hai più di un'azione rispetto al solo metodo Confirm() che deve essere eseguito. Forse hai una routine di inizializzazione, tre o più metodi di azione che possono essere eseguiti e un metodo Cleanup() . L'algoritmo di base è identico, tranne che fa le sue chiamate negli oggetti appropriati che implementano una classe base comune. Ora si inizia a vedere un vero vantaggio per lo stile orientato agli oggetti: l'algoritmo di base è molto più facile da leggere rispetto a se stesse controllando le istruzioni if-then in ogni fase del modo.

    
risposta data 23.12.2014 - 07:01
fonte
3

Sì, è perfettamente normale utilizzare il codice vecchio stile, a condizione che lo scopo del progetto sia ben noto o limitato. Se hai intenzione di estendere il tuo programma o il tuo progetto OOP è un modo per andare, perché puoi mantenere ed estendere il tuo codice senza problemi, d'altra parte se lo hai pianificato ed hai concluso che non hai intenzione di pianificare l'estensibilità del il progetto che fai, quindi, scrivere codice senza OOP sarebbe sufficiente. Ciò non significa che se usi un approccio non OOP non puoi mai aggiornare il tuo progetto ma sarebbe una cosa noiosa. OOP ci aiuta a visualizzare il nostro concetto come se fosse un organismo di vita reale perché li capiamo meglio di ogni altra cosa.

    
risposta data 23.12.2014 - 09:46
fonte

Leggi altre domande sui tag