Comments 16
Спасибо за отличную серию статей!
API, которые делают настолько сложным сделать что-либо неправильно, насколько это возможно.Прекрасная фраза, надо обязательно взять на вооружение.
Спасибо. А вообще я после публикации этой серии статей 5 пунктов в карме уже потерял. Прикольно, да? Что самое интересное — никто, никак не объясняет своего срача в карму.
Я в карму не залазил, но лично мне очень не понравилось что статьи постоянно пропадали-появлялись. И язык чуть-чуть костноват.
Но темы, поднятые автором, довольно интересны и до сих пор актуальны. Хотя всё это счастье датировано по-моему 2011м годом…
Но темы, поднятые автором, довольно интересны и до сих пор актуальны. Хотя всё это счастье датировано по-моему 2011м годом…
Думаете легко перевести, залить и связать между собой 6 статей? И какая разница каким годом это датировано? Это «вечные» истины.
Ну и зря минусуете. Я хотел сохранить структуру статей. Залил первую — она ведёт на 5 других. Я хотел быстрее залить остальные, чтобы меня не слили за перевод отправной статьи (или одной отрывочной). Делать пришлось быстро. Какой-то косяк получился с одной из статей. Получился дубль. Пришлось одну убирать, потом другую добавлять. Это не жалоба, то, что это проблемно — это факт)))
Нельзя так ни к кому относиться. Будьте добрее.
Нельзя так ни к кому относиться. Будьте добрее.
Никакой информации, на самом деле, не сокрыто.
Насколько я понимаю, не сокрыто на текущий момент. А в дальнейшем реализация (поле name) может измениться, а интерфейс (get и set) останется прежним. И те кто так пишут как раз закладывают возможную инкапсуляцию в свой проект.
Дык и что, что когда-то реализация поля может измениться? Всё-равно и перекомпилировать придётся, с сериализацией могут быть проблемы, и после появления какой-либо инкапсулируемой логики наверняка может поменяться способ использования данного поля. Не понимаю, зачем сразу обещать, что там есть какие-то инварианты или логика, если это просто торчащие наружу кишки класса. Ведь по факту, поле vs свойство — это принципиальная разница. И если разработчик сделал AIP, то в 99% случаев только из-за мнимой красоты кода.
По Вашему, в данном случае надо оставить public поле?
Скорее всего да. ИМХО, если есть такие вот тривиальные свойства, значит они хранят просто данные. И, скорее всего, весь объект — это какой-нибудь DTO. В таком случае да, пусть будут public поля. Потому что это реально public поля!
Если же здесь скрываются свойства, значит под ними есть какая-то логика. Ведь свойства объекта — это либо результат его внутреннего состояния (public Int32 Id { get; private set; } или вычисление значения на лету в get'ере), либо они умеют как-нибудь на него (состояние) влиять (т.е. в set'ере будет код).
Если же здесь скрываются свойства, значит под ними есть какая-то логика. Ведь свойства объекта — это либо результат его внутреннего состояния (public Int32 Id { get; private set; } или вычисление значения на лету в get'ере), либо они умеют как-нибудь на него (состояние) влиять (т.е. в set'ере будет код).
Лепят свойства не от хорошей жизни, а потому что некоторые фрейворки ради упрощения работают лишь со свойствами (чтобы дополнительно не реализовывать и работу с полями, ведь в крайнем случае всё можно переделать на свойства, а для пользователя авто-свойство не отличается от поля).
Те же WPF, NHibernate и т.д.
Поэтому хорошим тоном считается весь public делать свойствами, чтобы потом не было проблем с какой-то внешней библиотекой.
Те же WPF, NHibernate и т.д.
Поэтому хорошим тоном считается весь public делать свойствами, чтобы потом не было проблем с какой-то внешней библиотекой.
Вы говорите о том, что СЕЙЧАС, А я о том, что допускаю изменение системы в будущем. И не хочу бегать потом по использующим это поле и уговаривать их перейти на геттер.
Кроме того, важен принцип — отделение способа хранения данных от способа обращения к ним. Мало ли, может быть я это name захочу потом побитно хранить в десяти разных облачных сервисах. :-)
При этом снаружи всё тот же геттер. Это инкапсуляция и есть.
Кроме того, важен принцип — отделение способа хранения данных от способа обращения к ним. Мало ли, может быть я это name захочу потом побитно хранить в десяти разных облачных сервисах. :-)
При этом снаружи всё тот же геттер. Это инкапсуляция и есть.
Информация (состояние объекта) не сокрыта, а вот его реализация — уже да. Мы уже не можем делать предположений, что, например, после obj.Name = 'name', будет выполняться obj.Name == 'name'
Зря вы разбили. Статьи не такие уж и большие, а сохранить себе их неудобно.
В статье приведены правильные тезисы о хорошо спроектированных классов, тут верно подмечено. А вот про свойство можно прокоментировать, также как коментировали автора оригинала на его блоге: рассуждения, а конкретики нет. Покажите пример хорошей инкапсуляции свойства и плохой. Все-таки это зависит от контекста.
Sign up to leave a comment.
POKA-YOKE проектирование: от «запаха» к благоуханию