Я сосредатачиваюсь на S. Остальное как-то само собой складывается. Я приводил в статье ссылку на другую, как раз об этом. habrahabr.ru/company/skbkontur/blog/260781
Особенно принцип Лисков. Я не наследую реальные обьекты. Только абстрактные.
В любых нормальных IDE есть функция Find Usages. Если мы применим ее для класса события OrderCreated, то мы найдем все участки кода, которые относятся к созданию заказа.
Нужно ли проверять, что SendEmail() вызывается ровно один раз (если ранее не было исключения)? Нет, это очевидно.
Помоему, вы не совсем понимаете смысл юнит-тестирования. Проверять это нужно обязательно. Юнит-тесты полезны не столько тем, что позволяют проверить что все работает нормально на момент написания теста. А тем, что смогут указать что последние изменения что-то сломали. Если код поменяется и отправка email при каких-то условиях может не произойти юнит-тест покажет это почти сразу как только неверный код будет написан.
Я эти термины всю статью фактически раскрываю. Но если вам нужно именно определение, то я действительно рассчитывал, что кому надо — загуглят. Зачем копипастить? :)
А жизнь, между прочим, гораздо сложнее. В автопарке могут быть и прицепы какие-нибудь. И чтобы знать может ли объект двигаться сам(или чтобы его переместить нужен какой-нибудь эвакуатор) нужен какой-нибудь ICanMoveMyself(не нашел хорошего названия). И это нормально. Этот способ понять умеет ли объект переместить сам себя, имхо, лучший. Интерфейсы не такие уж и страшные, если ими правильно пользоваться. Не надо расширять IUniverse. Она и сама по себе неплохо расширяется.
Нет конечно. Что дешевле — переписать или поддерживать старое — часто возникающий вопрос. Но если стараешься писать с учетом будущей поддержки, то вероятность, что код отправится на помойку, существенно ниже.
1) Забить на поддерживаемость кода. Надо просто быстро наваять MVP и запускать. А потом, если все взлетит — будут деньги и на переписывание кода.
2) В хорошо написанной системе эти изменения реализуются в разы легче и, соответсвенно, дешевле. Статья, кстати, как раз в об этом.
3) Пишите хороший код и задержки будут не по вине кода.
Это такой плохой менеджмент. Недавно была годная хабрастатья о тимлиде, который выбирал между «сжатыми сроками» и о том, чтобы просто сказать менеджеру, что мы не успеем. Не смог быстренько найти ссылку…
Есть такая проблема. Согласен. Все эти IoC не нужны Hello world проектам. Они там только делают дороже и написание и поддержку. Постараюсь написать P.S. к статье хороший на эту тему.
Так и я об этом же! Первый код был «спроектирован под SMTP». В последнем варианте OrderService вообще ничего не знает ни об SMTP, ни вообще о Mailer. Какие бы перемены не сотрясали проект в будущем — код OrderService будет меняться только в том случае, если поменяется бизнес-логика заказов. Single Responsibility принцип как раз об этом.
DeleteAllAndWriteAgain Development — хорошая методология. Но очень уж дорогая :) Может у кода, который вы выкидывали был тот самый фатальный недостаток?
Ну это стандартная проблема статей и книг. Реальные примеры, где станет понятно для чего нужно вводить все эти паттерны, просто не уместятся в тексте. Да и не будет читатель их читать. Разумеется, пример упрощен.
Ну по ссылке выше, там выбирали между java и scala. И да, пример неудачный. Там perfomance был главной причиной. Но мысли мои про языки не поменялись. Скорость разработки и стоимость поддержки коррелируются слабо.
habrahabr.ru/company/skbkontur/blog/260781
Особенно принцип Лисков. Я не наследую реальные обьекты. Только абстрактные.
Я сам-то не уверен, что умею :) Поэтому постеснялся писать это.
2) В хорошо написанной системе эти изменения реализуются в разы легче и, соответсвенно, дешевле. Статья, кстати, как раз в об этом.
3) Пишите хороший код и задержки будут не по вине кода.