Автору спасибо огромное, куплю ближе к вечеру обязательно.
Играл на xbox, первый раз в темноте, была ночь, окна на распашку. После 1й и 2й главы, боялся каждого шороха на улице. Спал потом при включенном свете. Потрясающая вещь
Помимо этого полезно упомянуть еще системы для автоматического построения билдов. Без этого сейчас никуда, как минимум CI стоит внедрять. В команде из 3-4 человек это уже будет полезно.
Тулов очень много — TeamCity, Jenkins, Go, MSBuild и т.д. Вообще много работал с TeamCity для небольших коммерческих проектов в самый раз. Недавно решил еще заценить Go от ThoughtWorks
добавил бы еще 1 вариант:
— да, но только там, где это необходимо.
Если пояснить, то нет смысла писать тесты на простейшую логику трансляции одного объекта в другой, нет смысла писать тесты на простые геттеры и сеттеры в объектах.
На 100 процентов обязана быть покрыта доменная логика.
А почему, кстати, этот опрос в разделе .NET, а не в разделе TDD?
Конечно, я с этим полностью согласен. Применение ООП только ради ООП может привести к усложнению и самой системы, так еще и взаимоотношения с коллегами. Параноидального отношения вообще стоит избегать к любым вещам.
Но возвращаясь к вопросу о полиморфизме и абстракции, еще раз повторю — цели такой не было. Здесь описано именно то, что менялось в моем понимании. Понимание абстракции как было, так и осталось. С полиморфизмом та же штука
А я вроде нигде не говорил о том, что другие подходы не работают. Я пытался поделиться тем опытом, что у меня есть, и если хоть одному человеку он будет полезен, я буду рад
Как раз, чтобы программисту развиваться — ему надо совершать ошибки. Пусть лучше добавит лишней ответственности классу и потом на этом научится, чем будет просто писать сервисы.
В дополнение к минусам сервисов — неудобно писать тесты. Неизвестно, какие правила создания объектов и можно создать невалидный объект и подпихнуть его сервису. При богатом домене часто валидация происходит в момент создания.
На самом деле злоупотребление всякими сервисами превращает доменную модель в классы с набором геттеров и сеттеров. Она не несет в себе никакой смысл, ее трудно понимать, напрмер, нельзя сказать, что же можно сделать с этим объектом, а что нет. Есть даже термин такой — anemic domain model. У Фаулера есть интересная статейка об этом
Да, спасибо, про путаницу в процедурном и функциональном подходе мне уже объяснили. Дело в том, что я не большой специалист в области функционального программирования, поэтому и спутал. Изначально, наверное, не стоило подходить к сравнению таких вещей.
Есть в планах задачка, которую хочется попробовать сделать, применив функциональный подход. Тогда, наверное, и к ООП отношение поменяется вновь
а InRelease будет только в 2013й? в паре с 2012й его можно будет использовать? Выглядит он несколько тяжеловесно, если честно.
Играл на xbox, первый раз в темноте, была ночь, окна на распашку. После 1й и 2й главы, боялся каждого шороха на улице. Спал потом при включенном свете. Потрясающая вещь
Тулов очень много — TeamCity, Jenkins, Go, MSBuild и т.д. Вообще много работал с TeamCity для небольших коммерческих проектов в самый раз. Недавно решил еще заценить Go от ThoughtWorks
— да, но только там, где это необходимо.
Если пояснить, то нет смысла писать тесты на простейшую логику трансляции одного объекта в другой, нет смысла писать тесты на простые геттеры и сеттеры в объектах.
На 100 процентов обязана быть покрыта доменная логика.
А почему, кстати, этот опрос в разделе .NET, а не в разделе TDD?
Но возвращаясь к вопросу о полиморфизме и абстракции, еще раз повторю — цели такой не было. Здесь описано именно то, что менялось в моем понимании. Понимание абстракции как было, так и осталось. С полиморфизмом та же штука
В дополнение к минусам сервисов — неудобно писать тесты. Неизвестно, какие правила создания объектов и можно создать невалидный объект и подпихнуть его сервису. При богатом домене часто валидация происходит в момент создания.
В ответ на это есть статья с противоположным названием Objects have not failed
Есть в планах задачка, которую хочется попробовать сделать, применив функциональный подход. Тогда, наверное, и к ООП отношение поменяется вновь