Het is heel gewoon om classes in een library public te maken, maar eigenlijk is dit helemaal niet handig. Dat betekent namelijk dat de class vanuit alle code die de library gebruikt beschikbaar is. Met andere woorden de class maakt onderdeel uit van de interface van de library. Er zijn meerdere redenen waarom dit onwenselijk is:

1. De interface is onnodig groot en voor gebruiker van de library kan het daarom onduidelijk zijn welke classes gebruikt moeten worden.
2. Het is veel lastiger om te achterhalen welke verbindingen er bestaan tussen de library en eventuele clients. Dit is bijvoorbeeld lastig bij refactoring.
3. Het is in een client mogelijk om een sub-class te maken, terwijl dit wellicht niet de bedoeling is.

Veel beter is om classes internal te maken. Dit is ook standaard zo als je geen access modifier plaatst. Daarmee zijn classes alleen beschikbaar voor code binnen dezelfde assembly (tenzij men reflection gebruikt).

Het is verstandig om opo dezelfde manier even stil te staan bij class members. Die zijn standaard private, en als je dat verandert kun je ze protected (alleen beschikibaar voor de class zelf en sub-classes), internal, protected internal (protected of internal) of public maken. Als je dit consequent toepast kun je ook reflection tegengaan door de class te markeren met [ReflectionPermission(SecurityAction.Deny)]. Daarmee is de boel niet alleen veel handiger, maar ook veel veiliger.