Каковы преимущества правильного определения объема?

Question

Так что да, вопрос в основном говорит обо всем. Что вы получаете, когда вы гарантируете, что частные члены / методы / что-либо помечены как частные (или защищенные, или публичные, или внутренние, и т. Д.) Надлежащим образом?

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

Но давайте отложим хорошую практику программирования и просто посмотрим на это с точки зрения фактического количественного прироста. Что я получу за правильное определение моих методов, членов, классов и т. Д.?

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

(Для целей этого вопроса я больше думаю о C # .NET, но, эй, не стесняйтесь давать ответы на любом языке / структуре, которые вы считаете подходящими.)

РЕДАКТИРОВАТЬ : Большинство указывало, что это не приводит к увеличению производительности, и да, вспоминая, я даже не знаю, почему я так думал. Вероятно, нехватка кофе.

В любом случае любой хороший программист должен знать о том, как правильные области видимости (1) помогают обслуживанию вашего кода / (2) контролируют правильное использование вашей библиотеки / приложения / пакета; Мне было любопытно, была ли у вас какая-то другая выгода, которая явно не очевидна. Основываясь на ответах ниже, похоже, что в основном это сводится к двум наиболее важным вещам.

Answer 1

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

Даже языки, которые не имеют модификаторов видимости, такие как python, имеют соглашения для маркировки методов как внутренних и подлежащих изменению. Префикс метода _underscore () позволяет сигнализировать внешнему миру, что, если вы используете этот метод, вы делаете это на свой страх и риск, поскольку он может измениться в любое время.

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

Answer 2

Как я вижу, вы получаете две важные особенности от правильной оценки. Ваш API уменьшен в размерах и четко ориентирован на поставленную задачу.

Во-вторых, вы получаете менее хрупкую реализацию, поскольку можете свободно изменять детали реализации, не изменяя API.

Я не вижу, как модификаторы доступности каким-либо образом повлияют на производительность.

Answer 3

За счет лучшей инкапсуляции вы обеспечиваете лучший API. Доступны только те методы / свойства, которые представляют интерес для пользователя вашего класса: visible. Кроме того, вы гарантируете, что определенные переменные, которые не должны вызываться / изменяться, не могут вызываться / изменяться.

Это самое главное. Как вы думаете, почему это приведет к повышению производительности?

Answer 4

В программировании на C # помогает убедиться, что ваши API / классы / методы / члены "просты в использовании правильно и трудны в использовании неправильно" .

Answer 5

Существует в основном два типа методов / свойств.

1. , которые полезны для выполнения задачи тому, кто ее потребляет.(Рекомендуемая область действия: Public)
2. Это полезно для вышеуказанных методов, чтобы выполнить свою задачу.(Рекомендуемая область действия: Private или Protected) * Методы 1009 *

Type 1 являются единственными методами, которые требуются любому клиентскому коду и не требуют никаких других методов.Это позволяет избежать путаницы, делает вещи простыми и предотвращает неправильную работу клиентского кода. Методы

Type 2 - это методы, на которые делятся методы типа 1.Они помогают методам типа 1 выполнить свою задачу и при этом позволяют им быть простыми, лаконичными, менее сложными и более удобочитаемыми.Они на самом деле не нужны для клиентского кода, а только для самого класса / модуля.

Ярким примером может служить автомобиль.То, что у вас есть, это педаль газа, тормоза, коробка передач и т. Д. У вас нет интерфейса с мелкими деталями того, что находится под капотом.Это для механика.