OOP: fare affidamento su proprietà protette in un contratto classe-sottoclasse

Question

OOP: fare affidamento su proprietà protette in un contratto classe-sottoclasse

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

0

Sto codificando in Python, ma la domanda sembra indipendente dal linguaggio di programmazione.

Ho una classe che rappresenta un controllo di sistema:

class Check:
   @abstractmethod
   def run()
     """ You have to define your own run(). As a result, it must set self._ok. """
      ...

   @property
   def is_ok():
      return self._is_ok

Poi abbiamo una serie di controlli per sottoclassi della classe Check, e sono usati nel modo seguente (semplificato):

class Checker:
    checks = [check1, check2...]

    def __call__(self):
        for check in self.checks:
            if not check.is_ok:
                alarm()

La domanda è: va bene obbligare la sottoclasse a impostare alcuni attributi di oggetti protetti?

object-oriented python object-oriented-design

posta Eugene Koval 05.11.2014 - 12:28

fonte

3 risposte

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

Memorizza il nome di un oggetto nell'oggetto o esternamente? Uso dei costruttori in Java

score 2 · Answer 1

Perché non sarebbe giusto richiedere alle sottoclassi di lavorare? Il genitore è astratto, dopo tutto.

La domanda più importante è: perché run() dovrebbe segnalare il successo tramite un meccanismo out-of-bound (impostando una variabile globale) piuttosto che un valore di ritorno? A volte ci sono motivi per farlo (ad esempio perché è una convenzione estremamente radicata, come errno in C), ma in genere è un brutto segno a causa di problemi di concorrenza, manutenibilità ecc.

score 2 · Answer 2

Per fornire un'alternativa al fatto che il valore sia impostato dalla sottoclasse, puoi invece fornire loro un doRun che restituisce vero / falso per indicare il successo e la corsa assegna quel risultato a self._ok , questo permette anche più controlli come catturare eccezioni o assicurando che venga eseguito solo una volta:

class Check:
   @abstractmethod
   def doRun()
     """ You have to define your own doRun(). As a result, it must return whether it was successful. """
      ...

   def run()
     if not is_ok """ runs once, remove if not needed """
         self._ok = doRun()

   @property
   def is_ok():
      return self._is_ok

score 0 · Answer 3

Un principio comunemente accettato (anche se non universalmente) della progettazione di un oggetto è che un oggetto dovrebbe essere immutabile a meno che ciò non renda il disegno sostanzialmente più complesso. Gli oggetti immutabili sono più facili da ragionare, possono essere usati in un ambiente multithread più facilmente e sono generalmente meno inclini agli errori.

Dal codice che ci hai mostrato, non c'è motivo per cui possa capire perché hai bisogno di oggetti mutabili, quindi userei quelli immutabili.