Классы на базе TList...

← →
Игорь Шевченко © (2007-04-28 13:54) [40]

Ega23 © (28.04.07 13:49) [39]

> может - значение по-умолчанию присваивать.

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

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

Проще надо быть, как Эрик Реймонд советует.

← →
vovnuke © (2007-04-28 14:08) [41]

> [38] Игорь Шевченко © (28.04.07 13:45)

Вызывающему коду как раз и не следует видеть разницу в релизации объекта, для него он всего лишь структура отвечающая за выолнение определенных обязательств, и изменение в работе этой структуры не должны сказываться на работе клиента. А при изменении требований к ПО (а требования к ПО меняются всегда), придется поправить только реализацию механизма чтения/записи свойтсва, а не рыскать по коду и искать места которые могут сломаться или отлавливать ошибки.
Или этого мало?

← →
Игорь Шевченко © (2007-04-28 14:33) [42]

vovnuke © (28.04.07 14:08) [41]

Требвания меняются, никто не спорит. Но вот что странно - за много лет программирования я лично не часто сталкивался с необходимостью менять именно реализацию механизма чтения/записи свойства так, чтобы не затрагивать вызывающий код. Гораздо чаще вызывающий код тоже затрагивался и довольно значительно. Вот такая вот практика.
Можно считать, что мне не повезло, раз не сталкивался, но за опять же много лет программирования я пришел к одной простой истине - чем меньше в коде строчек, тем он лучше, разумеется, при условии, что код функционален и понятен визуально, без привлечение дополнительных средств, в том числе IDE

← →
ANB © (2007-04-28 15:03) [43]

> Можно считать, что мне не повезло, раз не сталкивался, но
> за опять же много лет программирования я пришел к одной
> простой истине - чем меньше в коде строчек, тем он лучше,
> разумеется, при условии, что код функционален и понятен
> визуально, без привлечение дополнительных средств, в том
> числе IDE

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

> [42] Игорь Шевченко © (28.04.07 14:33)

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

> [43] ANB © (28.04.07 15:03)

По большому счету, согласен.

Игорь Шевченко
[35]
ситуации могут быть разные, отдельно взятый пример описывает лишь отдельно взятую ситуацию, это не повод для обобщений

а так рекомендуют по очень простой причине - когда всё делаешь через get/set ты никогда не проиграешь(в худшем случае просто будешь иметь никому не мешающую избыточность), а вот если этого правила иногда придерживаться, а иногда нет и делать это не очень дальновидно, то можно получить проблем, которых совсем не ждёшь, зачем идти на риск?впрочем, вольному воля

Классы на базе TList... Найти похожие ветки