tag:blogger.com,1999:blog-8864435396524375431.post1670039962737219947..comments2022-12-12T00:21:25.652+02:00Comments on Систематизация автоматизации: Хороший дизайн должен быть SOLID: TOP-5 архитектурных принциповIgorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-8864435396524375431.post-77222396159544076102019-06-10T20:21:30.940+03:002019-06-10T20:21:30.940+03:00Спасибо за статью. Хорошо если порекомендуете годн...Спасибо за статью. Хорошо если порекомендуете годные курсы по Solid, TDD, IoC- в виде ссылок на торрент трекеры. СпасибоAnonymoushttps://www.blogger.com/profile/13943058476606718120noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-17436976952678474302016-10-05T17:56:05.402+03:002016-10-05T17:56:05.402+03:00потому что бубль гум. классы екстендятся а интерфе...потому что бубль гум. классы екстендятся а интерфейсы - имплементируются (а Java). а вообще-т опринципы - language-awarefuncelothttps://www.blogger.com/profile/04669089836944604275noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-58437623936323761212016-09-07T10:51:26.088+03:002016-09-07T10:51:26.088+03:00Этот комментарий был удален автором.Anonymoushttps://www.blogger.com/profile/03594430773547117975noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-12214911663481023332016-09-07T10:50:28.087+03:002016-09-07T10:50:28.087+03:00Этот комментарий был удален автором.Anonymoushttps://www.blogger.com/profile/03594430773547117975noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-3990536526687763292016-07-10T11:11:05.973+03:002016-07-10T11:11:05.973+03:00Коллеги, подскажите, пожалуйста, менеджеру,
есть ...Коллеги, подскажите, пожалуйста, менеджеру, <br />есть ли тулза для контроля исполнения принципа DIP в проектах C# ?Nikolayhttps://www.blogger.com/profile/12463414323505610332noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-34986032288313076762016-01-19T00:29:33.616+02:002016-01-19T00:29:33.616+02:00Прочитав сатью испытал дежавю, ибо на все эти граб...Прочитав сатью испытал дежавю, ибо на все эти грабли можно наступить (и часто наступают) при проектировании БД. Корень зла - несоответсвие архитектуры и логики приложения физической сути вещей (сущностей), которые оно (приложение) описывет. Не вникая в предметную область (зачем? ведь есть ТЗ!) вы порешали, что "это" приватное свойство, а оказалось что "это" вовсе не приватное и даже не свойство, а отношение или хуже - другая сущность ... начало конца положено! <br />Любое серьезное и даже очень простое, на первый взгляд, дело должно начинаться с ER-диаграммы - мозг прочищает основательно ... особенно после пятой переделки, и вот только тогда вырисовыватся те самые "монолитные" кубики LEGO, которые идеально подходят друг к другу и их никогда (есть право на надежу!) не придется переписывать. Просто в ООП много "халявы", в которой легко можно запутаться и использовать не по назначению. Кому интересно - есть статьи-комменты PerformanceDBA на stackoverflow (на англ.) с реальными примерами очень детальных и стройных ER-диаграмм. Человек 32 года проектирует БД = возраст SQL! Anonymoushttps://www.blogger.com/profile/09498518113921375081noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-61736369776454528862013-07-03T20:51:25.910+03:002013-07-03T20:51:25.910+03:00"Классическим примером нарушения этого принци..."Классическим примером нарушения этого принципа является построение иерархии такого рода:" не понял где ошибка, и если есть ошибка то где пример правильного кода?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-91881813962447269392012-08-17T10:24:16.005+03:002012-08-17T10:24:16.005+03:00Спасибо за статью.Спасибо за статью.Henry Motuhttp://henry-motu.org.uanoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-10720078898534250392011-09-20T23:02:23.177+03:002011-09-20T23:02:23.177+03:00Ну и YAGNI конечноНу и YAGNI конечноIgorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-19579389119826462532011-09-20T23:01:09.927+03:002011-09-20T23:01:09.927+03:00Как учебный пример, может и нет. Но в качестве при...Как учебный пример, может и нет. Но в качестве примера боевого коде - why not, вполне. Главное, не забывать про DRY и KISS при этом :)Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-43145896012166970182011-09-20T18:33:08.227+03:002011-09-20T18:33:08.227+03:00Спасибо за ответ :)
Я понимаю, что нужно использов...Спасибо за ответ :)<br />Я понимаю, что нужно использовать эти принципы с самого начала проектирования системы. Я сейчас тренируюсь в agile-разработке, и, соответственно, применяю все этапы проектирования: диаграммы, потом тесты, а потом уже код. И это буквально "вынуждает" писать гибкий код, используя все эти архитектурные принципы.<br />Это я к тому, что часто бывает так: спроектированная поначалу бизнес-сущность выглядит как один модуль, а на этапе кодирования приходится разделять ее на несколько более мелких. Опять же, следуя принципу SRP. <br />Пример, который я приводил в комментарии выше, является хорошим приемом организации SRP на уровне кодирования?IFeelGoodhttp://alekseev74.runoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-51681157337491185612011-09-20T12:33:07.434+03:002011-09-20T12:33:07.434+03:00IFeelGood,
Слово "макстимально" тут лиш...IFeelGood,<br /><br />Слово "макстимально" тут лишнее. Что чрезмерно - то не здраво, и использование принципов ради принципов не дает хорошего результата. Добавление вороха лишних абстракций разделит обязанности, но привнесет дополнительную сложность, с которой вам придется бороться с куда большим усердием, чем с, о боже, реализацией active record :)<br /><br />Для оценки качества исполнения принципа SRP могу порекомендовать попытаться сформулировать обязанности класса обычным человеческим языком. Если если получается средних размеров повесть, значит все плохо :) В идеале все должно вписываться в одном предложение.<br /><br />Кроме того, никоим образом эти принципы не рулят правилами организации приватных внутренностей классов. Тут уже каждый сам для себя решает что и как делать, главное, чтобы снаружи все вело себя предсказуемо, а зависимая логика может быть и спрятана, и заведена снаружи в виде неких дополнительных компонентов. Подумайте о том, как бы будете тестировать эту логику - это тоже поможет все грамотно раздедить.<br /><br />Ну и последнее: штука в том, что сами по себе синтаксические конструкции со словом class в начале не всегда соответствуют логическому понятию класса объектов. Код - это достаточно низкий уровень дизайна системы из за бедности современных языков программирования. Классический пример - понятия agregate roots и entities в сравнениии с value objects в паттернах DDD: единственная точка входа в логику - это корень агрегата, который за собой может прятать с десяток других классов, но вместе образовывать тот самый единый класс в терминах теории ООП. Или взять тот же aggregate root, но реализованый в виде event source-а. Т.е. к этому агрегату добавляется еще пачка связанных событий и какой-то странный код по их обработке. В квадратиках все выглядит очень просто, но в коде получается куча синтаксического мусора. Кроме того, даже такие высокоуровневые логические понятия, как агрегаты тоже могут составлять конструкции еще более высоких уровней - домены логики, модули систем и т.д.<br /><br />Все это к тому, что не стоит рассматривать эти архитектурные принципы исключительно на уровне правил кодирования некой логики в виде каких-то конкретных языковых конструкций какого-то конкретного языка программирования, которые по странному стечению обстоятельств поддерживают понятие интерфейсов и прочих приватных методов. Пользуйтесь ими на всех уровнях дизайна вашей системы, и тогда в этом действительно будет смысл.Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-31213693367403566012011-09-20T11:33:29.842+03:002011-09-20T11:33:29.842+03:00Вопрос по принципу SRP (хочется уточнить, правильн...Вопрос по принципу SRP (хочется уточнить, правильно ли я понимаю принцип?):<br />Нужно максимально стремиться специализировать класс, например, отделить бизнес-логику от сохранения данных в БД.<br />Также следует специализировать все открытые методы класса, которые составляют его интерфейс. Например, метод: int CalculateDiscount(int price) - вычисляет скидку и ничего более.<br />Если же для успешной реализации такого метода требуется дополнительная бизнес-логика, то ее нужно вынести в отдельные вспомогательные private-методы, которые не являются открытым интерфейсом класса.IFeelGoodhttp://alekseev74.runoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-58285245320315435562010-12-01T11:33:36.471+02:002010-12-01T11:33:36.471+02:00Спасибо за статью.Спасибо за статью.Максhttps://www.blogger.com/profile/05019676306636366465noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-48406842482341470402010-04-20T16:11:13.880+03:002010-04-20T16:11:13.880+03:00Thanks! Good job.Thanks! Good job.Denishttps://www.blogger.com/profile/12932490740723886910noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-13115776825215451052010-04-12T13:27:59.999+03:002010-04-12T13:27:59.999+03:00Спасибо, поправил :)Спасибо, поправил :)Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-11858356118609406092010-04-12T13:11:54.155+03:002010-04-12T13:11:54.155+03:00Поправьте, пожалуйста:
Принцип замещения Лисков:
....Поправьте, пожалуйста:<br />Принцип замещения Лисков:<br />...поведение P не будет меняться, если o1 заменить на o2.<br />вы перепутали о1 и о2 местами, <br />и для понимания будет лучше, если, как в Википедии, объекты типа (Type) и подтипа (Subtype) обозначить oT и oS соответственно.Anatoly R.https://www.blogger.com/profile/13910100045749886568noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-24652546991524895622009-11-12T13:15:12.235+02:002009-11-12T13:15:12.235+02:00Well, I can't fully agree with this opinion. I...Well, I can't fully agree with this opinion. I.e. modern languages like C# can't check the behaviour aspects of the inheritance. Thats why the Design by contract approach with automated theormes proving is still on the very early stages of implementation.Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-51261730113654172272009-11-10T23:42:56.026+02:002009-11-10T23:42:56.026+02:00Seems like OOP languages themselves give us a good...Seems like OOP languages themselves give us a good examples of LSP-conforming system designs. This is why developers can simply upcast their objects without noticing LSP in this act :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-56802576662406979152008-11-17T10:14:00.000+02:002008-11-17T10:14:00.000+02:00>>Я иммел ввиду, что предпочтительней исполь...>>Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости). <BR/>>> К тому же писать тесты к "интерфейсному коду" гораздо легче.<BR/><BR/>И в чем была бы разница? Мы же не далем гибкость ради гибкости. Если есть ситуации в которых абстраный луче (а в данном примере он действительно лучше), то зачем городить интерфейс, а потом еще абстракную реализацию?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-66915036936207233782008-10-27T01:24:00.000+02:002008-10-27T01:24:00.000+02:00Ну, если так, то в данном конкретном случае этот и...Ну, если так, то в данном конкретном случае этот интерфейс не не нес бы никакой смысловой нагрузки для примера. <BR/><BR/>По этой же причине реализации методов заменены тремя точками :)<BR/><BR/>Но в реальном коде в нем был бы смысл, безусловно.Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-30700637208451143272008-10-27T01:11:00.000+02:002008-10-27T01:11:00.000+02:00"Или я что-то не понимаю, но если я просто вместо ..."Или я что-то не понимаю, но если я просто вместо abstract class напишу interface - то я получу ошибки в духе "'HttpServiceClient' does not implement interface member 'ServiceClient.ServiceUri'". Так что, наврерное, не оно :)"<BR/>- ну если не реализовать, то и не скомпилится.<BR/>Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости). К тому же писать тесты к "интерфейсному коду" гораздо легче.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-6558796222726663832008-10-27T01:06:00.000+02:002008-10-27T01:06:00.000+02:00А относительно TDD и спецификаций, то вы бы его по...А относительно TDD и спецификаций, то вы бы его получили на стадии рефакторинга в какой-то момоент времени, а певое приближение дейтсвительно было бы классом с кучей методов.<BR/><BR/>Но соглашусь, что все дейтсвительно зависит от ситуации и массы других предпослок. Посему стоит рассматривать вариант "стоит или не стоит городить спецификации" и рассуждать о сложности реализации тсключительно в конкретном контексте.Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-15035724837697935142008-10-27T01:00:00.000+02:002008-10-27T01:00:00.000+02:00Или я что-то не понимаю, но если я просто вместо a...Или я что-то не понимаю, но если я просто вместо abstract class напишу interface - то я получу ошибки в духе "'HttpServiceClient' does not implement interface member 'ServiceClient.ServiceUri'". Так что, наврерное, не оно :)Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-38988292007981591582008-10-27T00:46:00.000+02:002008-10-27T00:46:00.000+02:00public interface IServiceClient{ // Property de...public interface IServiceClient<BR/>{<BR/> // Property declaration:<BR/> string ServiceUri<BR/> {<BR/> get;<BR/> set;<BR/> }<BR/>}<BR/><BR/>- оно?<BR/><BR/>"Вы же не станете утверждать, например, что IoC нужен только для того, чтобы клиент имел возможность гибкой конфигурации приложения?"<BR/>- не стану. Зато стану утверждать, что для этого всегда обязательно внедрять в проект Spring.NET или еще что-то подобное.<BR/><BR/>Используя ТДД, я бы получил самое простое решение, которым Спецификация не является.Kigorwhttps://www.blogger.com/profile/09850913869781508736noreply@blogger.com