Каковы преимущества правильной оценки?

Question

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

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

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

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

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

EDIT: Большинство отметил, что это не приводит к увеличению производительности, и, оглядываясь назад, я даже не знаю, почему я так думал. Вероятно, нехватка кофе.

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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