Incapsulamento VS Ereditarietà - Come utilizzare una funzione protetta?

Question

In linguaggi OOP come C # o VB.NET, se creo le proprietà o i metodi in un supercodice protetto non riesco ad accedervi nel mio modulo - sono accessibili solo nella mia classe che eredita da quella super classe.

Per accedere a tali proprietà o metodi devo renderli pubblici , che sconfigge l'incapsulamento o riscriverli nella mia classe, che sconfigge l'eredità.

Qual è il modo giusto per farlo?

Answer 1

" devono renderli pubblici che sconfiggono l'incapsulamento "

Non confondere il buon design con le regole di visibilità icky. Le regole di visibilità sono confuse. Esistono davvero due tipi di visibilità ortogonale: sottoclasse e client. Non è perfettamente chiaro perché avremmo mai nascosto qualcosa dalle nostre sottoclassi. Ma possiamo, con private .

Ecco cosa è importante. Incapsulamento non significa nascondersi. Protetto e privato non sono una parte essenziale di un buon incapsulamento. Puoi fare un buon design con tutto ciò che è pubblico (è così che funziona Python, per esempio).

Le cose protette / private riguardano - principalmente - la gestione della proprietà intellettuale: sei disposto a impegnarti (in modo legalmente vincolante, "ci vediamo in tribunale se non funziona"); modo) a un'interfaccia? Se lo sviluppo del tuo software coinvolge avvocati, ti preoccupi di aggiungere protezione e riservatezza alle cose a cui non sei impegnato.

Se non devi fare i conti con gli avvocati, considera di fare l'incapsulamento giusto ma lascia tutto pubblico.

Answer 2

Se hai un codice che deve richiedere a una Classe di eseguire un'operazione specifica ma la classe non presenta il tuo codice con un mezzo per farlo, la Classe non soddisfa i requisiti del tuo codice.

È un po 'come dire che ho un'auto (automobile) con un volante protetto, quindi non posso accedervi. L'auto non mi serve.

Rendi pubblici quei membri (o almeno interni) e usali o elimina la classe e usa quella che fornisce al tuo codice di consumo le funzionalità di cui ha bisogno.

Forse quello che stai davvero cercando è un'interfaccia. L'interfaccia contiene i membri di cui il tuo codice ha bisogno e tu implementi quell'interfaccia sulla tua classe. Il vantaggio qui è che la tua classe può determinare l'accesso ai membri tramite questa interfaccia piuttosto che una sottoclasse ereditaria.

Answer 3

Siamo spiacenti, non è chiaro cosa intendi per " nel mio modulo " - qual è la relazione tra il tuo modulo e le tue due classi? Se le tue classi sono controlli nello stesso progetto e desideri accedere alle proprietà dal modulo, devi utilizzare la parola chiave "interna".

Answer 4

Esistono almeno tre modi in cui è possibile limitare chi può utilizzare un particolare metodo di istanza di particolari istanze di classe:

1. Definisce il metodo come `protetto`,` interno` o `privato`. Nel primo caso, un metodo di istanza sarà utilizzabile solo all'interno dei metodi di classe derivata della stessa istanza; nel secondo caso, tutte le classi all'interno dell'assembly avranno accesso a quei metodi, ma le classi esterne no; nel terzo caso, nessuna classe esterna, neppure derivata nello stesso assembly, avrà accesso, a meno che il loro codice non sia nidificato all'interno della classe dichiarante.
2. Definisci il metodo come `pubblico`, ma le classi che creano istanze le mantengono private e non le espongono mai al mondo esterno. Chiunque desideri invocare un metodo di istanza su un oggetto deve avere un'istanza su cui invocarlo. Se una classe contiene istanze ma non espone mai riferimenti diretti a esse, gli unici metodi di istanza che potranno mai essere utilizzati su tali istanze saranno quelli che le classi di mantenimento usano se stesse.
3. Definisce il metodo come `pubblico`, ma ha un costruttore che accetta una posizione in cui possono essere memorizzati uno o più delegati a metodi privati. Il codice con accesso a tali delegati sarà in grado di richiamare i metodi a cui si fa riferimento in tal modo, ma altri codici non lo faranno (tranne utilizzando Reflection in modi che ritengo siano utilizzabili solo in scenari di piena fiducia).

Se la riflessione in scenari non completamente attendibili consentirebbe ai delegati non associati di essere vincolati a istanze di oggetti arbitrari, si potrebbero usare le classi nidificate per rinforzare il n. 3 in modo da poter accedere ai campi private per ottenere l'accesso illegittimo alle funzioni private ; sarebbe assolutamente vietato al di fuori degli scenari di piena fiducia.