Размышления о правильном программировании Опции

[Litkevich Yuriy]

Тут наткнулся на статью 10 уродских приёмов программирования — Алик Кириллович

Читаю, вроде пока с автором согласен.

[Kagami]

Я помню эту статью еще с хабра. С частью тезисов не согласен В основном претензии к призыву отказаться от сеттеров/геттеров. Плюс отказ от рекурсии. Ну и по мелочи кое-где. Больше всего мне не понравилась категоричность автора. Бывают моменты, когда красоту кода придется приносить в жертву производительности.

Сообщение отредактировал Kagami - 28.3.2010, 15:43

[Litkevich Yuriy]

Плюс отказ от рекурсии.

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

[kwisp]

В основном претензии к призыву отказаться от сеттеров/геттеров.

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

[Litkevich Yuriy]

я вот сейчас прочёл тоже согласен с тобой.

тут есть нюанс. В целом я согласен с автором, те кому приходилось писать на Делфи, перейдя на любой другой инструмент (Билдер не всчёт так как пытается пародировать Делфи) могли испытать чувство не Объектно-Ориентированности.
Дело в том, что в Делфи, есть понятие свойств, поддерживаемых компилятором. В Qt, например, тоже есть.
И когда в Делфи вы пишите:
value = object.sameProperty;
то вы получаете значение свойства объекта, но не напрямую, а через "геттер", а когда вы пишете
object.sameProperty = value;
то вы устанавливаете значение свойства объекта, но не напрямую, а через "сеттер". Т.е. у вас есть возможность определить и "геттер" и "сеттер".

Но форма записи в коде очень интуитивна, и на мой взгляд, по настоящему Объектно-Ориентирована.

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

Свойство — это интерфейс для красивого и безопасного доступа к данным объекта

[Iron Bug]

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

что касается "общих" вопросов, применимых ко всем языкам, то моё мнение такое:

про возвращаемое значение:
имхо - функция ВСЕГДА должна возвращать int с кодом ошибки и точка. результаты - в параметрах.

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

[Litkevich Yuriy]

про возвращаемое значение:
имхо - функция ВСЕГДА должна возвращать int с кодом ошибки и точка. результаты - в параметрах.

а я вот категорически с этим не согласен.
Сам термин "функция" обязывает к математическому поведению. Как и приведено у автора статьи

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

ну это опять же жёстко завязано на Си++. А в языках где есть свойства, в них нет нужды

[AD]

Я не согласен с функциями внутри функций. Если нужен какой-то логический блок, то лучше пользоваться пространствами имен.

[Litkevich Yuriy]

то лучше пользоваться пространствами имен

а пространства имён разве можно определить внутри функции?

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

[AD]

а пространства имён разве можно определить внутри функции?

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