È buona prassi creare interfacce che limitino l'utilizzo?

3

Quindi sto codificando un modo per inviare eventi a più client, e poi far decidere ai clienti come vogliono gestirli. Escludo i bit che non si prestano a spiegare la situazione.

class Event_Beacon

    def add_event_eater( self, ee ):
        self.event_eaters.add( ee )

    def broadcast_event( self, e ):
        for e in self.event_eaters:
            e.receive_event( e )

Ora, con quanto sopra, posso creare un'istanza di un Event_Beacon e passarlo in giro. Sto pensando che dovrei fermarmi in futuro dal possibile abuso di tutti gli accessi a Event_Beacon.

Ad esempio, supponiamo, ho un Event_Maker. Ha senso che questo Event_Maker abbia accesso al metodo broadcast_event, ma in realtà non add_event_eater. Se l'avessi appena passato con l'istanza del beacon dell'evento, avrei potuto in qualche futuro ampliamento di questo particolare evento, incidere casualmente un add_event_eater all'interno dell'evento.

Quindi è buona pratica creare un'interfaccia limitante in modo che io dia un altro oggetto esattamente di cui ha bisogno e niente di più? Qualcosa come:

class Event_Beacon_Broadcast_Remote

    def __init__( self, event_beacon ):
        self.beacon = event_beacon

    def broadcast_event( self, e ):
        self.beacon.broadcast_event( e )

    # note the lack of add_event_eater in this interface
    
posta user2738698 27.08.2016 - 08:48
fonte

3 risposte

4

È una buona idea se hai davvero il requisito esplicito per due diverse interfacce. In genere, è necessario che impedisca ad altri di abusare eventualmente dell'interfaccia esistente e di progettare un componente o una libreria riutilizzabile che deve fornire un accesso diverso dall'esterno del componente piuttosto che dall'interno.

Tuttavia, la creazione di tali interfacce "nel caso", per alcuni scenari ipotetici (o superstiziosi) è una violazione del principio YAGNI, aggiungerà solo un codice non necessario, che rende il software più difficile da mantenere e da evolvere.

(Ad esempio, per te o il tuo team potrebbe essere in gran parte sufficiente aggiungere un commento come "non usare in remoto" sopra il metodo add_event_eater .)

Devi decidere da solo se nella situazione mostrata per smettere di futuro di abusare dell'interfaccia cade nella prima o nella seconda categoria. Può essere l'una o l'altra, ma bisogna conoscere i casi d'uso e i requisiti del proprio sistema, i client dell'API e l'ambiente per prendere una decisione, quindi non possiamo decidere per voi.

    
risposta data 27.08.2016 - 09:45
fonte
4

Questa è un'idea abbastanza buona da dare il suo nome, chiamato Principio di segregazione dell'interfaccia . È l'io nei principi SOLIDI. Ti avvertirei di non pensare ai programmi come una sorta di sistema di sicurezza contro i manutentori abusivi e inetti del futuro. L'atteggiamento di cercare di rendere le cose il più semplici possibili per i futuri manutentori è molto meglio. La separazione delle interfacce fa ciò evitando l'introduzione di dipendenze non necessarie che hanno un costo di manutenzione ma nessun vantaggio.

    
risposta data 28.08.2016 - 06:42
fonte
0

Dirò di no. È una buona idea dividere le interfacce in gruppi di responsabilità. Se la pubblicazione degli eventi è separata da Event Listening, allora sì, dovresti creare due interfacce.

Ma sembra che tu stia facendo un passo avanti e utilizzandoli come una forma di diritti di accesso.

Il problema con questo è che i diritti a cui un oggetto che consuma ha bisogno non sono definiti dalla classe consumata. Per fornire tutti i possibili usi, sarai costretto a creare un'interfaccia per ogni combinazione di metodi sull'oggetto.

Con solo i due metodi che sono le tre interfacce, pubblicare, ascoltare e entrambi e sembra che siano aree logiche di responsabilità. Ma se hai dieci metodi, le sue 3 milioni di possibili combinazioni di accesso. Avere un'interfaccia per ciascuno sarebbe ridicolo

    
risposta data 27.08.2016 - 17:58
fonte

Leggi altre domande sui tag