Параметр против переменных-членов - PullRequest
22 голосов
/ 09 февраля 2009

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

  1. Переменная должна быть сохранена для последующего вызова.
  2. Данные, хранящиеся в переменной, используются глобально в классе.
  3. Когда переменная должна обрабатываться глобально (что-то определенно отличается от необходимости читать переменную каждым методом класса).
  4. Когда это существенно упростит программирование. (По общему признанию, расплывчато, но во многих обстоятельствах нужно быть осторожным, чтобы не загнать себя в угол).

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

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

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

edit2
Был задан пример для:

class foo
{
    private $_my_private_variable;

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        // This is the line I am wondering about,
        // there does not seem to be a need for storing it.
        $this->_my_private_variable = $variable; 
        $this->_doSometing();
    }

    private function _doSomething()
    {

        /*
          do something with $this->_my_private_variable.
        */
        // This is the only place _my_private_variable is used.
        echo $this->_my_private_variable;
    }
}

Вот как бы я это сделал:

class foo
{

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        $this->_doSometing( $variable );
    }

    private function _doSomething( $passed_variable )
    {
        /*
          do something with the parameter.
        */
        echo $passed_variable;
    }
}

Ответы [ 8 ]

31 голосов
/ 09 февраля 2009

Обычно члены класса должны представлять состояние объекта класса.

Они не являются временными местоположениями для параметров метода (вот для чего нужны параметры метода).

8 голосов
/ 09 февраля 2009

Наличие переменной-члена подразумевает, что она будет содержать состояние, которое необходимо удерживать между вызовами методов. Если значение не должно существовать между вызовами, у него нет причин существовать вне области одного вызова, и поэтому (если оно вообще существует) должна быть переменная внутри самого метода.

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

8 голосов
/ 09 февраля 2009

Я утверждаю, что это не проблема стиля, а проблема читаемости / удобства обслуживания. Одна переменная должна иметь одно использование и только одно использование. «Переработка» переменных для разных целей только потому, что они требуют одного и того же типа, не имеет никакого смысла.

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

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

4 голосов
/ 09 февраля 2009

Вы должны создавать переменные только тогда и там, где они нужны, и утилизировать их, когда закончите. Если классу не нужна переменная уровня класса для функционирования, тогда он просто не нужен. Создание переменных там, где они вам не нужны, очень плохая практика.

2 голосов
/ 30 октября 2016

Членами класса должно быть любое из следующих:

  • Зависимость класса
  • Переменная, которая представляет состояние класса
  • метод класса
0 голосов
/ 26 апреля 2012

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

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

Мне нравится сохранять гибкость, не думая об этом больше, чем нужно.

0 голосов
/ 09 февраля 2009

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

0 голосов
/ 09 февраля 2009

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

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

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

...