Ich denke, dass Fee() und Fi() gleichermaßen zugänglich sind, da die gesamte Klasse bereits intern ist. Übersehe ich etwas? Gibt es einen Grund, in einem solchen Fall öffentlich oder intern für die Methoden zu wählen?öffentliche vs interne Methoden auf einer internen Klasse
Die internal class Foo Deklaration überschreibt die Erreichbarkeit der public void Fee() Methode und macht sie effektiv intern.
In diesem Fall hat die Verwendung von internal vs. public auf den Methoden den gleichen Effekt. Der einzige Grund, warum ich öffentliche Methoden und interne Methoden in einem Fall wie diesem wählen würde, wäre, den Übergang zu einer öffentlichen Klasse in einer zukünftigen Version zu erleichtern, sollten Sie sich dafür entscheiden.
+1 Meine Gedanken genau! – si618
Gemäß der msdn documentation ist Ihre Foo-Klasse außerhalb Ihrer Baugruppe nicht zugänglich, so dass es keinen Unterschied macht, die Methoden als intern oder öffentlich zu kennzeichnen; Es macht sogar keinen Unterschied durch die Verwendung des Attributs InternalsVisibleTo
Sie haben Recht, sowohl Fee und Fi werden gleichermaßen zugänglich sein.
Von der CSharp Language Specification 3.0, unter 3.5.2:
Die Zugriffsdomäne eines verschachtelten Mitglied M innerhalb eines Programm P in einem Typ T deklariert ist definiert als folgt (unter Hinweis darauf, dass M sich möglicherweise ein Typ) sein kann:
• Wenn das erklärte Zugänglichkeit von M öffentlich ist, die Zugriffsdomäne von M die Zugriffsdomäne von T.
Also, auch wenn Fee als öffentlich erklärt wird, wird es genauso zugänglich sein wie Foo (d. H. intern).
Eigentlich - es gibt einen großen Unterschied, wenn Sie Reflexion verwenden; Insbesondere kann Silverlight sehr verärgert sein, wenn Sie versuchen, über Reflektion auf interne Methoden zuzugreifen, selbst wenn Sie Zugriff gehabt hätten. Ich habe Gelegenheiten gesehen, bei denen ich eine Methode veröffentlichen musste, damit der Code in Silverlight funktioniert, obwohl er auf normalem .NET funktioniert.
Sie könnten das gleiche mit teilweisem Vertrauen in regulären .NET finden.
Das sind die schmutzigen Details, an denen ich immer interessiert bin. Obwohl, wenn jemand Reflektionen verwendet, um auf versteckte Mitglieder in meinen Klassen zuzugreifen, werde ich mir keine Sorgen machen, wenn es schwierig für sie ist. – ScottS
@ScottS - manchmal spiegeln Sie Ihre * eigenen * Typen wider - d. H. Wo Sie normalerweise Zugriff auf die interne Methode hätten, aber plötzlich nicht. –
Die einzige Sache, die hier in der Antwort fehlt, ist, warum würden Sie das tun?
Einige Bibliotheken haben viele Klassen, die nicht für den Benutzer der Bibliothek gedacht sind, die sie berühren müssen, aber sie müssen Schnittstellen erben, die als öffentlich markiert sind. Zum Beispiel habe ich eine Bibliothek mit einer Klasse, die die IComparer-Schnittstelle erbt, aber sie wird nur intern verwendet und ich möchte den öffentlichen Aspekt meiner Bibliothek nicht durcheinander bringen. Wenn ich die implementierte Compare-Funktion als intern markieren, beklagt der Compiler, dass ich die Schnittstelle IComparer nicht ergänze.
Wie kann ich die Schnittstelle erfolgreich implementieren und gleichzeitig verhindern, dass sie im öffentlichen Bereich meiner Bibliothek zugänglich ist? Markieren Sie die Klasse als intern, aber die implementierte Funktion als öffentlich.
ich mit nur internen Methoden gehen würde, wenn eine Klasse intern ist. Falls Sie Ihre Meinung ändern und die Klasse veröffentlichen, können Sie einfach einen Text ersetzen und Sie sind fertig.
Es würde einen Unterschied machen, wenn Ihre interne Klasse eine Schnittstelle implementieren soll. Die Methode, die eine Implementierung einer Schnittstelle ist, müsste öffentlich sein.
@EricLippert hat heute seine Meinung gebloggt. http://ericlippert.com/2014/09/15/internal-or-public/#more-2353 – ScottS