Alla ricerca di alcuni consigli di progettazione OO

Question

Alla ricerca di alcuni consigli di progettazione OO

#1 da (12 voti)
#2 da (1 voti)

12

Sto sviluppando un'app che verrà utilizzata per aprire e chiudere le valvole in un ambiente industriale e stava pensando a qualcosa di semplice come questo: -

public static void ValveController
{
    public static void OpenValve(string valveName)
    {
        // Implementation to open the valve
    }

    public static void CloseValve(string valveName)
    {
        // Implementation to close the valve
    }
}

(L'implementazione dovrebbe scrivere alcuni byte di dati sulla porta seriale per controllare la valvola, un "indirizzo" derivato dal nome della valvola e un "1" o "0" per aprire o chiudere la valvola).

Un altro dev ha chiesto se dovremmo invece creare una classe separata per ogni valvola fisica, di cui ci sono dozzine. Sono d'accordo che sarebbe più bello scrivere codice come PlasmaValve.Open() piuttosto che ValveController.OpenValve("plasma") , ma questo è eccessivo?

Inoltre, mi stavo chiedendo come affrontare il design con un paio di ipotetici requisiti futuri in mente: -

Ci viene chiesto di supportare un nuovo tipo di valvola che richiede valori diversi per aprirlo e chiuderlo (non 0 e 1).
Ci viene chiesto di supportare una valvola che può essere impostata su qualsiasi posizione da 0 a 100, piuttosto che semplicemente "aperta" o "chiusa".

Normalmente userei l'ereditarietà per questo genere di cose, ma di recente ho iniziato a riflettere sulla "composizione sull'ereditarietà" e mi chiedo se ci sia una soluzione di slicker da usare con la composizione?

object-oriented design design-patterns

posta Andrew Stephens 15.10.2012 - 17:04

fonte

2 risposte

1

Il mio problema maggiore è l'utilizzo di stringhe per il parametro che identifica la valvola.

Crea almeno una classe Valve che ha un getAddress nel modulo richiesto dall'implementazione sottostante e passa a ValveController e assicurati di non poter creare valvole inesistenti. In questo modo non dovrai gestire stringhe errate in ogni metodo aperto e chiuso.

Se crei metodi di convenienza che chiamino open e close in ValveController dipende da te, ma onestamente terrò tutte le comunicazioni verso la porta seriale (inclusa la codifica) in una singola classe che altre classi faranno chiamare quando necessario. Ciò significa che quando è necessario migrare a un nuovo controller è necessario modificare solo una classe.

Se ti piacciono i test dovresti anche creare ValveController un singleton in modo da poterlo prendere in giro (o creare un training machine per gli operatori).

risposta data 15.10.2012 - 17:31

fonte

Leggi altre domande sui tag object-oriented design design-patterns

Che cosa fai quando non riesci a capire una certa parte della programmazione? [chiuso] Come potrebbero lavorare più persone su un sito web?

score 12 · Accepted Answer

Se ogni istanza dell'oggetto valvolare eseguisse lo stesso codice di ValveController, sembra che più istanze di una singola classe sarebbero la giusta via da seguire. In questo caso basta configurare quale valvola controlla (e come) nel costruttore dell'oggetto valvola.

Tuttavia, se ogni controllo di valvola richiede un codice diverso da eseguire, e l'attuale ValveController esegue una dichiarazione di switch gigante che fa cose diverse a seconda del tipo di valvola, allora il polimorfismo non è stato implementato correttamente. In tal caso, riscrivilo in più classi con una base comune (se questo ha senso) e lascia che il singolo principio di responsabilità sia la tua guida alla progettazione.