Независимые методы получения/сеттера или комбинированные?

Во время работы над проектом я делал некоторые изменения и просматривал существующие документы API фреймворка для понимания.

При изучении документов Kohana я заметил, что геттеры/сеттеры любого заданного класса обычно объединяются:

public function someProperty($value = null){
    if(is_null($value){
        return $this->_someProperty;
    }
    $this->_someProperty = $value;
    return $this;
}

Вместо

public function setSomeProperty($value){
    $this->_someProperty = $value;
    return $this;
}

public function getSomeProperty(){
    return $this->_someProperty;
}

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

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

Ответ 1

Я рассматриваю эту плохую практику, потому что она нарушает CommandQuerySeparation. Установка значения изменяет состояние (команда). Получение значения запрашивает состояние (запрос). Метод не должен делать оба, но только одно.

Кроме того, не совсем очевидно, что делает метод, когда он только что назвал имя пользователя, например. не имеет глагола, например get или set. Это становится еще хуже в вашем примере, потому что возвращаемое значение является либо самим объектом, либо значением свойства, поэтому оно несовместимо.

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

Ответ 2

jQuery идет так же, как Kohana. Однако я считаю, что лучше создавать отдельные методы настройки и получения. Это более очевидно, что делает метод, и я думаю, что это более практично в кодо-завершении в вашей идее. Например, вы вводите set и получаете список всех свойств, которые вы можете установить.

Другим недостатком является: что, если вы хотите действительно установить значение null? Это не сработает, так как null является идентификатором для возврата в значение, вы ограничены в настройке определенных значений...

Итак, это приятно, так как вам придется писать меньше, но каковы три буквы (set/get) перед вашими методами?

Ответ 3

Несмотря на то, что Kohana использует такую необычную технику для ООП, я думаю, вам следует сначала следовать правилам кодирования. Но, конечно, лучше использовать отдельные геттеры и сеттеры для каждой собственности в ваших классах. Итак, если можно использовать их, не нарушая условностей - просто сделайте это, и вы не ошибетесь;). Вы также можете прочитать здесь о хороших привычках в PHP OOP - http://www.ibm.com/developerworks/opensource/library/os-php-7oohabits/, если вы сомневаетесь в использовании какой-либо техники ООП. Надеюсь, что это поможет:)

Ответ 4

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

Чтобы ответить на ваш вопрос, да, я сжимаю, когда вижу первый метод. Идет против принципов ООП.

Ответ 5

Почему бы не сделать это так?

public function someProperty($value = null)
{
    if (func_num_args() === 1) {
        $this->someProperty = $value;
        return $this;
    } else {
        return $this->someProperty;
    }
}

Это было бы единственным правильным способом реализации комбинированного getter/setter

Ответ 6

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

Однако это смутило бы меня

Для настройки и получения я всегда использую сеттеры и геттеры:

   public function __set($key, $value) {
      // assign value $value to $this->key
   }

   public function __get($key) {
      // return value of this->key
   }

Ответ 7

Для аргументации

Комбинированный подход дает некоторые преимущества:

Предотвращает __get и __set магию, все еще эмулируя публичное свойство. (Я бы никогда не рекомендовал использовать магию для этих ситуаций)
Использование thing() менее подробное, чем использование getThing() setThing().
Несмотря на то, что методы будут делать больше, их все равно можно считать "одним нажатием thing()", который обрабатывает thing(). Свойства также делают больше, чем одно. Они позволяют устанавливать и получать значения.
Он утверждал, что thing() не дает глагола. Однако мы можем предположить, что a thing() без глагола означает, что мы используем его как свойство (мы получаем и устанавливаем его). Для интерфейсов можно сказать, что a thing() без аргумента readonly, а thing($arg) с аргументом - чтение/запись. Почему мы должны стесняться принимать это? В какой-то момент мы приняли идею добавления геттеров и сеттеров, не так ли?
Если вы используете веб-язык (например, PHP), то, скорее всего, вы можете использовать jQuery. JQuery уже делает этот тип thing(), и он хорошо работает.
Использование func_num_args(), как уже упоминалось, помогает идеально достичь этого подхода.

Лично я уже принимал значительную долю рисков в своих текущих приложениях на данный момент, поэтому я, вероятно, собираюсь со старыми проверенными и готовыми геттерами и сеттерами (см. раздел "Поиск баланса" позиции Джимми Богарда в отношении геттеров/сеттеров для операций с данными). И я полагаю, что мы уже обучены искать эти префиксы get/set (а также наши IDE), чтобы увидеть, с какими свойствами мы можем работать в классе. Это обсуждение, на которое я мог бы вернуться в какой-то момент.