Come dovrei rappresentare un oggetto le cui istanze condividono lo stesso insieme di identificatori di funzioni membro, ma quegli identificatori specificano comportamenti diversi?

Question

Come dovrei rappresentare un oggetto le cui istanze condividono lo stesso insieme di identificatori di funzioni membro, ma quegli identificatori specificano comportamenti diversi?

#1 da (2 voti)

-1

Sto tentando di sviluppare un modulo Python open source per la modellazione di reti di compiti per la simulazione di eventi discreti. Il componente più fondamentale è l'oggetto compito, che include vari dati come una distribuzione di possibili tempi di durata dell'attività, una condizione di rilascio (criteri per l'avvio dell'attività), un effetto iniziale (istruzioni eseguite all'avvio dell'attività), un effetto finale (dichiarazioni eseguite al termine del compito, ad esempio l'inizio di un'attività diversa) e così via. Mentre ogni attività deve includere tutti gli elementi di cui sopra, la logica che contengono è univoca per ogni istanza di attività.

Un'intera rete di compiti potrebbe contenere un numero illimitato di compiti, quindi mi piacerebbe renderlo il più semplice possibile per crearne uno. Quindi stavo pensando di seguire un paradigma orientato agli oggetti e semplicemente di avere una classe di attività che gli utenti potevano creare, ma non sono sicuro di come implementare il fatto che ci sono diversi comportamenti associati a ciascuna istanza di attività. La soluzione ovvia sarebbe quella di rendere ogni attività una sottoclasse che sovrascrive la classe di attività principale (o eventualmente fornisce semplicemente un diverso file di implementazione di classe), ma ciò sembra sciocco perché comporterebbe un sacco di singleton inutili.

Ho anche considerato di includere questi metodi in un dizionario che viene passato al costruttore predefinito, ma non voglio che il processo di definizione di un'attività diventi non intuitivo / richieda troppi passaggi per l'utente finale. Sto anche cercando di capire come conservare i dati della rete di questo compito: raw Python, JSON (ma per quanto ne so, questo si verifica solo nello stesso problema poiché JSON non può rappresentare il comportamento associato a un'attività)? Sono sicuro che probabilmente è molto più semplice di quanto non lo sia, ma qualcuno può indicarmi un buon modello di progettazione per questo tipo di situazione? Grazie.

object-oriented python simulation singleton overriding

posta mcman 17.05.2017 - 20:40

fonte

1 risposta

Leggi altre domande sui tag object-oriented python simulation singleton overriding

Pratiche raccomandate per utilizzare PDO con il modello MVC [chiuso] Unit test di una libreria di database per scopi generali

score 2 · Accepted Answer

Ho implementato un framework di simulazione per simulazioni di tempo continuo (in Python) che ti ha permesso di definire un comportamento personalizzato all'interno di un framework di simulazione generale, quindi capisco cosa stai ottenendo con la necessità di estendere facilmente i tuoi oggetti di simulazione.

Una delle cose del design di OO è che l'ereditarietà gioca molto, ma in realtà è composizione e iniezione di dipendenza che ho trovato più utile. Dal punto di vista del design, la tua situazione richiede qualcosa come Pattern di strategia .

Ecco alcuni suggerimenti per rendere la tua attività facile da usare:

Implementa un "Task" come classe che prende altri oggetti come argomenti nel suo costruttore. Ad esempio, in base alla tua descirption, gli daresti un timer di durata dell'attività, un controllo delle condizioni di rilascio (criteri per l'avvio dell'attività), un implementatore dell'effetto iniziale (istruzioni eseguite all'avvio dell'attività), un implementatore dell'effetto finale (dichiarazioni eseguito alla conclusione dell'attività, ad esempio l'inizio di un'attività diversa, e così via.
Implementa ognuna delle classi utilizzate negli argomenti del costruttore di Task come classi astratte: è ciò che dovrai estendere quando crei un nuovo comportamento. Nota: se stai usando un linguaggio di programmazione funzionale (o dove le funzioni possono essere passate avanti e indietro come oggetti), puoi saltare la necessità di creare oggetti che incapsulino questo comportamento e semplicemente inserire le funzioni direttamente (ecco perché mi piace Python e il suo tipo)
Lo scopo della classe Attività è definire l'interfaccia comune che il tuo motore di simulazione si aspetta di avere a disposizione per lavorare con tutte le attività.
Ora, programma il tuo motore di simulazione in modo da permetterti solo di utilizzare l'interfaccia definita in (1).
Sottoclasse gli oggetti comportamentali definiti in (1) per rappresentare i diversi comportamenti che vuoi (e usa nomi validi e descrittivi per ogni sottoclasse). Cerca di pensare a come suddividere il comportamento in modo tale che sia riutilizzabile (ad esempio, non devi scrivere costantemente nuove sottoclassi, ma semplicemente comporre quelle esistenti).

Spero che questo ti aiuti a organizzare il tuo codice. La chiave è programmare un'interfaccia non una classe concreta. Quindi, puoi agganciare sottoclassi specifiche (con la stessa interfaccia) per cambiare comportamento anziché creare tonnellate di sottoclassi di Attività. Potresti anche essere in grado di utilizzare questi componenti più volte (bonus!)