Code design: questo caso specifico di monkeypatching in python è accettabile?

-1

Sto usando python per svolgere alcuni compiti di ricerca. Ho una gerarchia di classi per "strumenti", in cui ogni oggetto è un'istanza di un particolare strumento. Tutti condividono alcune funzionalità e hanno molte somiglianze nei loro stati.

Alcuni di questi strumenti possono utilizzare uno dei vari metodi basati sullo stato corrente dell'oggetto strumento. Lo strumento specifico che sto per porre riguarda effettivamente chiamate funzioni da moduli esterni invece di metodi scritti direttamente nella classe. Il motivo alla base di questo è di suddividere il codice in più file, cioè non avere alcun enorme file di mostri che abbia tutti i vari metodi e le funzioni di supporto utilizzate da quei metodi, quando tutto ciò di cui ha bisogno in un dato momento è un particolare sottoinsieme molto mirato . Cioè quando la modalità dello strumento è "clean_house", funzionerei solo come "wash_windows", "vacuum_carpet" e "ask_girlfriend_for_help", mentre quando la modalità è "do_work", utilizzo funzioni come "write_code", "debug_code", e "ask_SO_question". I sottoinsiemi non si intersecano in alcun modo, ad esempio "write_code" non chiamerebbe mai "ask_girlfriend_for_help", ecc.

Invece di chiamare queste funzioni dall'ambito del modulo all'interno dei metodi di classe, mi sembra che sia una buona idea monkeypatch sulla classe dello strumento, dato che ci sono metodi di istanza che devono chiamare per andare oltre la gerarchia delle classi e modificare lo stato di un oggetto di parte (protetto) utilizzato in seguito nel distruttore.

So che la monkeypatching è spesso considerata una progettazione scadente o una pratica di ultima istanza quando le hot-fix sono in ordine ( Post del programmatore SE qui ), ma è giustificato in questo caso? Qualche suggerimento di progettazione di codice alternativo?

    
posta Greg Kramida 09.08.2013 - 14:49
fonte

1 risposta

1

Non sei davvero un patch per le scimmie. La patch di Monkey è l'atto di usare la natura dinamica di Python per cambiare il codice di terze parti. Quello che stai facendo è usare la stessa natura dinamica per costruire la tua classe. Questa non è la stessa cosa, di per sé.

Sembra che tu stia delegando funzionalità ad altri moduli. Sembra una pratica perfetta. Ma non vedo perché dovresti modificare il tuo strumento per farlo; il tuo strumento può trasferire chiamate di metodo a un oggetto sottostante responsabile dell'attuazione effettiva, in base allo stato corrente.

Questi oggetti responsabili possono comunque modificare lo stato dello strumento, poiché in Python nulla è realmente privato.

    
risposta data 09.08.2013 - 15:10
fonte