Quando NON usare una variabile membro / classe?

0

Sto cercando di imparare QUANDO NON utilizzare:

  • classi
  • variabili membro

QUI È IL CODICE

access_point_detection_classes.py

from scapy.all import *

class Handler :
    def __init__(self) :
        self.wap_list = []
        self.TempWAP = None



    def process_packet_capture(self, packet_capture) :
            for packet in packet_capture :
                if packet.haslayer(Dot11) :
                    if packet.subtype == 8 :
                        bssid = packet.addr3
                        if packet.haslayer(Dot11Elt) :
                            p = packet[Dot11Elt]
                            while isinstance(p, Dot11Elt) :
                                if p.ID == 0 :
                                    essid = p.info
                                if p.ID == 3 :
                                    channel = ord(p.info)
                                p = p.payload

                            self.TempWAP = WirelessAccessPoint(bssid, essid, channel)

                            if self.check_for_duplicates() == False:
                                self.wap_list.append(self.TempWAP)

    def check_for_duplicates(self) :
        for w in self.wap_list :
            if self.TempWAP.bssid == w.bssid :
                return True
        return False

class WirelessAccessPoint :
    def __init__(self, bssid, essid, channel) :
        self.bssid = bssid
        self.essid = essid
        self.channel = channel

access_point_detection.py

from scapy.all import *
from access_point_detection_classes_module import *

def main() :

    H = Handler()

    packet_capture = sniff(count = 50)

    H.process_packet_capture(packet_capture)

    for w in H.wap_list :
        print w.bssid
        print w.essid
        print w.channel
        print '++++++++++++++++++++++++'




    # enable_managed_mode('wlan0')

if __name__ == "__main__" :
    main()

QUI I MIEI PENSIERI

Sono quasi sicuro di sapere QUANDO utilizzare una classe e le variabili membro. Guarda la mia seconda classe WirelessAccessPoint . Il perfetto bisogno di una classe secondo me.

  • Ho bisogno di più oggetti di questo tipo
  • Gestione più semplice dei dati associati a questo tipo

È grandioso, ma guarda la mia prima classe Handler . Ad essere onesti, l'ho creato principalmente per poter praticare OOP. È utile quando ho bisogno di accedere a wap_list . Tuttavia, lo inizializzo senza passare i parametri per il costruttore. E 'questo che sconfigge lo scopo? Sembra che potrei creare tutti i metodi di questa classe con solo il parametro self . Ad esempio (haha) potrei rendere packet_capture una variabile membro di Handler e il metodo process_packet_capture() prendere il parametro self .

A questo punto mi sento come se non fissassi alcune regole di base per me stesso, cercherò di rendere tutto una classe e ogni cosa una variabile membro e non passerò mai più un parametro oltre a self !

    
posta TT4M.C 26.07.2016 - 02:35
fonte

3 risposte

2

However, I initialize it without passing parameters for the constructor. Is that defeating the purpose?

No, assolutamente no. Gestore, forse erroneamente chiamato, ma in un certo senso rappresenta un oggetto di raccolta, che è perfettamente ragionevole senza parametri del costruttore. Un oggetto collection mantiene uno stato per la sua durata e molte collezioni vengono create con un set inizialmente vuoto.

Tuttavia, ciò che non mi piace necessariamente è l'uso di una variabile membro per lo stato di breve durata di TempWAP. Penso che una variabile locale e qualche parametro che passa sarebbe meglio qui, no?

Forse l'esempio non chiarisce che TempWAP è altrimenti usato nella tua implementazione più completa, o, in alternativa, potresti avere due classi qui che sono state fuse (una vita più breve e una vissuta più a lungo), ma sulla base di ciò che posso vedere nella domanda, andrei per la variabile locale invece della variabile membro qui.

Il punto è che la durata delle due variabili membro in Handler sembra incoerente. Quindi, questi membri dovrebbero essere differenziati, sia usando una variabile locale, sia in un'altra classe (overkill, anche se forse). Per ripetere, quando tutte le variabili membro nella stessa classe hanno la stessa durata utile, hai una classe migliore rispetto al contrario.

    
risposta data 26.07.2016 - 04:23
fonte
2

Non usare classi e / o variabili membro quando non sono necessarie. Non appena ne hai bisogno, bene, usali.

Sono serio.

    
risposta data 26.07.2016 - 06:51
fonte
2

Una variabile dovrebbe sempre avere l'ambito più piccolo e il tempo di vita più breve possibile. Pertanto un membro della classe è preferibile a una variabile globale e una variabile o parametro locale è preferibile a un membro della classe.

Nel tuo esempio, TempWAP è utilizzato solo nell'esecuzione di process_packet_capture() e potrebbe quindi essere modificato in locale e passato come parametro a check_for_duplicates() . Come variabile membro, è disponibile dopo l'esecuzione, ma non ha alcun valore utile. wap_list dall'altra parte è accessibile dopo l'esecuzione, quindi questo deve essere un membro.

Ma a seconda di come usi Handler potresti decidere di riscrivere process_packet_capture() in una funzione autonoma che restituisce wap_list . Ciò renderebbe più semplice l'uso a mio avviso, ma questo onestamente si riduce alle preferenze. Ad alcuni piace seguire un paradigma OO ovunque, mentre personalmente preferisco le funzioni autonome senza effetti collaterali quando possibile.

La variabile packet_capture è utilizzata solo come input per process_packet_capture() , quindi dato i principi di cui sopra non vedo alcun motivo per trasformarlo in un membro.

Vedo un leggero rischio di avere wap_list come membro piuttosto che un valore di ritorno. Significa che potresti accedere erroneamente a wap_list prima della chiamata di process_packet_capture() , e se chiami process_packet_capture() più volte, wap_list conterrà i risultati accumulati di tutte le chiamate. Questo potrebbe essere ciò che intendete, ma in caso contrario, quindi avendolo come valore di ritorno piuttosto che membro evita questo rischio di abuso. In alternativa, potresti avere un packet_capture come argomento per il costruttore e chiamare process_packet_capture(packet_capture) direttamente nel costruttore. In questo modo hai ancora wap_list come membro, ma evita il rischio di abuso.

    
risposta data 26.07.2016 - 10:36
fonte