POKA-YOKE проектирование: от «запаха» к благоуханию

[zloyusr]

Спасибо за отличную серию статей!

API, которые делают настолько сложным сделать что-либо неправильно, насколько это возможно.

Прекрасная фраза, надо обязательно взять на вооружение.

[EngineerSpock]

Спасибо. А вообще я после публикации этой серии статей 5 пунктов в карме уже потерял. Прикольно, да? Что самое интересное — никто, никак не объясняет своего срача в карму.

[deilux]

Я в карму не залазил, но лично мне очень не понравилось что статьи постоянно пропадали-появлялись. И язык чуть-чуть костноват.

Но темы, поднятые автором, довольно интересны и до сих пор актуальны. Хотя всё это счастье датировано по-моему 2011м годом…

[EngineerSpock]

Думаете легко перевести, залить и связать между собой 6 статей? И какая разница каким годом это датировано? Это «вечные» истины.

[EngineerSpock]

Ну и зря минусуете. Я хотел сохранить структуру статей. Залил первую — она ведёт на 5 других. Я хотел быстрее залить остальные, чтобы меня не слили за перевод отправной статьи (или одной отрывочной). Делать пришлось быстро. Какой-то косяк получился с одной из статей. Получился дубль. Пришлось одну убирать, потом другую добавлять. Это не жалоба, то, что это проблемно — это факт)))

Нельзя так ни к кому относиться. Будьте добрее.

[deilux]

Последний абзац в первую очередь относится к вам :)
Я просто высказал свои догадки, а вы сразу «думаете легко ...». Выглядит грубовато!

[Vladimir_Izotov]

Никакой информации, на самом деле, не сокрыто.

Насколько я понимаю, не сокрыто на текущий момент. А в дальнейшем реализация (поле name) может измениться, а интерфейс (get и set) останется прежним. И те кто так пишут как раз закладывают возможную инкапсуляцию в свой проект.

[deilux]

Дык и что, что когда-то реализация поля может измениться? Всё-равно и перекомпилировать придётся, с сериализацией могут быть проблемы, и после появления какой-либо инкапсулируемой логики наверняка может поменяться способ использования данного поля. Не понимаю, зачем сразу обещать, что там есть какие-то инварианты или логика, если это просто торчащие наружу кишки класса. Ведь по факту, поле vs свойство — это принципиальная разница. И если разработчик сделал AIP, то в 99% случаев только из-за мнимой красоты кода.

[Vladimir_Izotov]

По Вашему, в данном случае надо оставить public поле?

[deilux]

Скорее всего да. ИМХО, если есть такие вот тривиальные свойства, значит они хранят просто данные. И, скорее всего, весь объект — это какой-нибудь DTO. В таком случае да, пусть будут public поля. Потому что это реально public поля!

Если же здесь скрываются свойства, значит под ними есть какая-то логика. Ведь свойства объекта — это либо результат его внутреннего состояния (public Int32 Id { get; private set; } или вычисление значения на лету в get'ере), либо они умеют как-нибудь на него (состояние) влиять (т.е. в set'ере будет код).

[qw1]

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

Те же WPF, NHibernate и т.д.

Поэтому хорошим тоном считается весь public делать свойствами, чтобы потом не было проблем с какой-то внешней библиотекой.

[Vladimir_Izotov]

Вы говорите о том, что СЕЙЧАС, А я о том, что допускаю изменение системы в будущем. И не хочу бегать потом по использующим это поле и уговаривать их перейти на геттер.
Кроме того, важен принцип — отделение способа хранения данных от способа обращения к ним. Мало ли, может быть я это name захочу потом побитно хранить в десяти разных облачных сервисах. :-)
При этом снаружи всё тот же геттер. Это инкапсуляция и есть.

[VolCh]

Информация (состояние объекта) не сокрыта, а вот его реализация — уже да. Мы уже не можем делать предположений, что, например, после obj.Name = 'name', будет выполняться obj.Name == 'name'

[xakpc]

Зря вы разбили. Статьи не такие уж и большие, а сохранить себе их неудобно.

[Wertugo]

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

[EngineerSpock]

В серии статей есть примеры. Кто не видит — я не виноват :)