Antologiko ha scritto:
Per una di queste classi però sarebbe opportuno per motivi di coerenza interna, che l'accesso ai membri che costituiscono l'implementazione dell'interfaccia detta, sia limitato al solo codice della libreria.
In tal caso, quei membri non dovrebbero appartenere all'interfaccia ma solo alla classe, oppure andrebbero isolati dall'interfaccia che attualmente è
Public per essere
inseriti in un'altra interfaccia separata con visibilità minore, e fare in modo che la classe implementi entrambe le interfacce, quella pubblica e quella con visibilità ridotta.
Antologiko ha scritto:
Detto in parole grezze, per tale classe bisognerebbe impedire che dall'esterno della libreria 'si sappia' che essa implementa l'interfaccia detta.
Nel mondo .NET, anche grazie alla presenza della
Reflection e della possibilità per il CLR di "visitare" la struttura dei tipi, in generale non si può impedire nulla. Tutto ciò che si può fare è sfruttare le regole della OOP. Questo per dire che, sebbene sia possibile rendere un codice compilabile, se l'utente vuole a tutti i costi invocare un metodo, non esiste un modo per impedirglielo in assoluto.
Antologiko ha scritto:
Sto commettendo un errore di fondo?
E' un problema noto con soluzione 'canonica' già esistente?
Si potrebbe dire che forse è stato violato l'
Interface Segregation Principle (parte dei principi SOLID), ossia
l'interfaccia include troppi metodi di cui l'utilità è dubbia e costringe le implementazioni a definirli tutti, oltre a consentire ai client di invocarli pur essendo questi metodi "di dettaglio", quindi
non dovrebbero trovarsi nell'interfaccia.
Per un approfondimento, bisognerebbe vedere di cosa si tratta e analizzare il design delle classi nello specifico.
Ciao!