2010-12-11 2 views
2

Возможно, мне что-то не хватает, но не должен ли C# иметь модификатор внешнего доступа для методов? Т.е. модификатор, который делает метод общедоступным, но только для других классов, т. Е. Метод не может быть вызван самим классом?Почему нет «внешнего» модификатора доступа?

Разве это не было бы полезно для таких вещей, как общедоступные методы, которые блокируют, чтобы гарантировать, что блокировка не будет возвращена из класса?

+0

Существует ключевое слово 'extern', но оно не используется для описания. http://msdn.microsoft.com/en-us/library/e59b22c5%28v=vs.80%29.aspx – Nobody

+9

Это полезно только для программистов с множественным расстройством личности. Если вы хотите, чтобы методы не были доступны классу, поместите их в другой класс. По дизайну класс oop должен иметь доступ и контроль над методами и данными, содержащимися в классе. – ja72

ответ

5

Методы взаимодействия с явной реализацией, вероятно, наиболее близки к тому, что вы хотите. Конечно, класс все равно мог бы называть их сам, если он вводит в тип интерфейса.

+0

На самом деле, я думаю, что другие ответы лучше. Я собирался рассказать о том, как вам не нужно это поведение, но приманка с умным решением была слишком велика. – siride

+0

[Прогресс] (http://msdn.microsoft.com/en-us/library/hh193692.aspx) и [IProgress] (http://msdn.microsoft.com/en-us/library/hh138298.aspx) - действительно хороший пример хорошего использования этого. 'IProgress .Report' является частным членом, поэтому любой, кто создает класс' Progress ', не видит метод' Report() ', но все потребители, которые принимают интерфейс' IProgress ', могут вызывать' Report() 'метод для обратного вызова. –

3

Я думаю, что это было бы бесполезно. Нет никакой парадигмы, которая бы определяла любую потребность в ней.

В вашем примере: даже если есть ключевое слово external, как вы гарантируете, что блокировка не может быть повторно введена извне, не отпуская ее?

Существуют контракты между классами, и класс всегда заключает договор с самим собой. Я думаю, что ни одно ключевое слово не поможет избежать таких ошибок программирования. В этом конкретном примере класс должен правильно реализовать блокировку в зависимости от уровня использования.

+0

Я не знаю, я думаю, синтаксис, который проясняет смысл кода и гарантирует, что определенное поведение, как правило, хорошо, поэтому у нас есть такие вещи, как ключевое слово readonly. Нет причин, по которым у класса не было бы «контракта» с самим собой – Homde

8

Нет необходимости в этом. Контроль доступа используется для ограничения доступа к членам от ненадежного кода клиента.

Помните, что в ООП класс представляет собой автономную автономную единицу кода и неявно предполагается, что он самосогласован.

Если вы не можете доверять коду своего класса, чтобы не вызывать повторное размещение, то чем вы можете доверять? Нецелесообразно защищать все возможные возможности с помощью языковых функций; иногда это зависит только от вас, как разработчика, чтобы убедиться, что ваш собственный код работает :)

Смежные вопросы