Приватные методы и свойства по сравнению с общедоступными относительно их следов памяти в C # (и других языках)

Question

Я помню дискуссию, которую я недавно проводил с коллегой-разработчиком по поводу использования памяти частными и общедоступными свойствами. Я заявил, что частные имеют меньше следа, чем публичные. Он утверждал, что это не имеет значения. Кстати, мы говорили о C #.

Кто прав и почему?

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

Answer 1

В контексте какого языка?

В большинстве языков изменение доступности метода с public на private или наоборот никак не повлияет на объем памяти . Это связано с тем, что фактическая реализация и фактический вызов метода не изменяются, а только способ, которым осуществляется доступ к нему (либо во время компиляции, либо во время выполнения, на основе рассматриваемого языка программирования.)

Что будет влиять на объем памяти, другие квалификаторы , такие как final в Java, virtual в C ++, static и т. Д. Эти квалификаторы могут либо напрямую влиять на объем памяти (наличие или отсутствие соответствующей записи в классе vtable), либо косвенно влиять на объем памяти из-за определенных предположений оптимизации, которые могут быть сделаны компилятором или средой выполнения (например, могут быть встроены не virtual, static и / или final методы, что, возможно, повышает производительность - и наиболее определенно увеличивает объем используемой памяти.)

---

Важнее, чем объем памяти , когда вы обсуждаете, как метод должен быть квалифицирован, то, что вы можете сделать, чтобы оба (1) проверяли компилятор (или время выполнения, в зависимости от языка) некоторые из ваших предположений и намерений, и (2) передать эти предположения и намерения программисту, который будет анализировать, перепроектировать, изменять, перефакторизовывать и т. д. код после вас:

• private: нужен ли другим классам или потомкам этого класса прямой доступ к этому методу? Если нет, сделайте это private.
• protected: потомки этого класса (или самого этого класса), но никакие другие классы (кроме, может быть, friend классов), нуждаются в прямом доступе к этому методу? Если так, сделайте это protected.
• static: метод требует доступа к переменным-членам или к this? Если нет, это должен быть static (например, служебный метод, который зависит исключительно от его аргументов)
• const: изменяет ли метод переменные-члены или вызывает не const методы-члены для this или переменных-членов? Если нет, то это должно быть const (например, получатель)
• virtual: метод должен быть переопределен? Если нет, то не будет virtual
• abstract (или чисто виртуальный): должен ли метод иметь реализацию в этом классе, если потомки этого класса переопределят его? Если нет, сделайте это abstract (или pure virtual)
• и т.д.

Существуют различные статьи, лекции и посты, посвященные лучшим практикам для вышеперечисленного, выходящим за границы многих языков программирования:

• права доступа и инкапсуляция
• Инкапсуляция
• частное или защищенное
• и т.д.

Answer 2

Это не имеет значения. Само свойство - это просто код и метаданные для него. И то, и другое необходимо, независимо от того, является ли собственность частной или общественной. Почему это имеет значение?

Answer 3

Создание свойства или метода private может повысить скорость выполнения, потому что компилятор может с большей вероятностью встроить код, но я не знаю ни одного случая, когда это уменьшает объем памяти (встраивание может фактически увеличить объем в пользу скорость).

Answer 4

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

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

Answer 5

Нет никакой разницы. И, даже если бы они были, это должно быть довольно жестоко, чтобы стоить менять аксессуары для них.