tag:blogger.com,1999:blog-8864435396524375431.post1670039962737219947..comments2011-09-21T15:08:37.365+03:00Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-8864435396524375431.post-10720078898534250392011-09-20T23:02:23.177+03:002011-09-20T23:02:23.177+03:00Ну и YAGNI конечноIgorhttp://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 при этом :)Igorhttp://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-разработке, и, соответственно, применяю все этапы проектирования: диаграммы, потом тесты, а потом уже код. И это буквально &quot;вынуждает&quot; писать гибкий код, используя все эти архитектурные принципы.<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,<br /><br />Слово &quot;макстимально&quot; тут лишнее. Что чрезмерно - то не здраво, и использование принципов ради принципов не дает хорошего результата. Добавление вороха лишних абстракций разделит обязанности, но привнесет дополнительную сложность, с которой вам придется бороться с куда большим усердием, чем с, о боже, реализацией active record :)<br /><br />Для оценки качества исполнения принципа SRP могу порекомендовать попытаться сформулировать обязанности класса обычным человеческим языком. Если если получается средних размеров повесть, значит все плохо :) В идеале все должно вписываться в одном предложение.<br /><br />Кроме того, никоим образом эти принципы не рулят правилами организации приватных внутренностей классов. Тут уже каждый сам для себя решает что и как делать, главное, чтобы снаружи все вело себя предсказуемо, а зависимая логика может быть и спрятана, и заведена снаружи в виде неких дополнительных компонентов. Подумайте о том, как бы будете тестировать эту логику - это тоже поможет все грамотно раздедить.<br /><br />Ну и последнее: штука в том, что сами по себе синтаксические конструкции со словом class в начале не всегда соответствуют логическому понятию класса объектов. Код - это достаточно низкий уровень дизайна системы из за бедности современных языков программирования. Классический пример - понятия agregate roots и entities в сравнениии с value objects в паттернах DDD: единственная точка входа в логику - это корень агрегата, который за собой может прятать с десяток других классов, но вместе образовывать тот самый единый класс в терминах теории ООП. Или взять тот же aggregate root, но реализованый в виде event source-а. Т.е. к этому агрегату добавляется еще пачка связанных событий и какой-то странный код по их обработке. В квадратиках все выглядит очень просто, но в коде получается куча синтаксического мусора. Кроме того, даже такие высокоуровневые логические понятия, как агрегаты тоже могут составлять конструкции еще более высоких уровней - домены логики, модули систем и т.д.<br /><br />Все это к тому, что не стоит рассматривать эти архитектурные принципы исключительно на уровне правил кодирования некой логики в виде каких-то конкретных языковых конструкций какого-то конкретного языка программирования, которые по странному стечению обстоятельств поддерживают понятие интерфейсов и прочих приватных методов. Пользуйтесь ими на всех уровнях дизайна вашей системы, и тогда в этом действительно будет смысл.Igorhttp://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 (хочется уточнить, правильно ли я понимаю принцип?):<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Спасибо за статью.Максhttp://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.Denishttp://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Спасибо, поправил :)Igorhttp://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.http://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&#39;t fully agree with this opinion. I.e. modern languages like C# can&#39;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.Igorhttp://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 examples of LSP-conforming system designs. This is why developers can simply upcast their objects without noticing LSP in this act :)aarendarhttp://aarendar.wordpress.com/noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-56802576662406979152008-11-17T10:14:00.000+02:002008-11-17T10:14:00.000+02:00&gt;&gt;Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости). <BR/>&gt;&gt; К тому же писать тесты к &quot;интерфейсному коду&quot; гораздо легче.<BR/><BR/>И в чем была бы разница? Мы же не далем гибкость ради гибкости. Если есть ситуации в которых абстраный луче (а в данном примере он действительно лучше), то зачем городить интерфейс, а потом еще абстракную реализацию?Mike Chaliyhttp://dev.net.ua/blogs/mikechaliy/default.aspxnoreply@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/>Но в реальном коде в нем был бы смысл, безусловно.Igorhttp://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/>Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости). К тому же писать тесты к "интерфейсному коду" гораздо легче.Kigorwhttp://www.kigorw.comnoreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-6558796222726663832008-10-27T01:06:00.000+02:002008-10-27T01:06:00.000+02:00А относительно TDD и спецификаций, то вы бы его получили на стадии рефакторинга в какой-то момоент времени, а певое приближение дейтсвительно было бы классом с кучей методов.<BR/><BR/>Но соглашусь, что все дейтсвительно зависит от ситуации и массы других предпослок. Посему стоит рассматривать вариант "стоит или не стоит городить спецификации" и рассуждать о сложности реализации тсключительно в конкретном контексте.Igorhttp://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Или я что-то не понимаю, но если я просто вместо abstract class напишу interface - то я получу ошибки в духе "'HttpServiceClient' does not implement interface member 'ServiceClient.ServiceUri'". Так что, наврерное, не оно :)Igorhttp://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<BR/>{<BR/> // Property declaration:<BR/> string ServiceUri<BR/> {<BR/> get;<BR/> set;<BR/> }<BR/>}<BR/><BR/>- оно?<BR/><BR/>"Вы же не станете утверждать, например, что IoC нужен только для того, чтобы клиент имел возможность гибкой конфигурации приложения?"<BR/>- не стану. Зато стану утверждать, что для этого всегда обязательно внедрять в проект Spring.NET или еще что-то подобное.<BR/><BR/>Используя ТДД, я бы получил самое простое решение, которым Спецификация не является.Kigorwhttp://www.blogger.com/profile/09850913869781508736noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-34766004987312686052008-10-27T00:35:00.000+02:002008-10-27T00:35:00.000+02:00Дело не в гибкости для клиента. Вы же не станете утверждать, например, что IoC нужен только для того, чтобы клиент имел возможность гибкой конфигурации приложения?<BR/><BR/>Да и по объему кода едва ли разница столь значима, чтобы говорить о значительных преимуществах одного из методов.<BR/><BR/>Кроме того, если вы будете использовать TDD, то у вас такое решение со спецификациями получиться само собой :)<BR/><BR/>А по поводу интерфейсов я не понял, к чему вы клоните. Лучше приведите код :)Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-27135874280022000212008-10-27T00:13:00.000+02:002008-10-27T00:13:00.000+02:00Дело в деньгах клиента, который платит. Гибкое решение должно предполагать окупаемость.<BR/><BR/>http://msdn.microsoft.com/en-us/library/64syzecx.aspx - на счет интерфейсовKigorwhttp://www.blogger.com/profile/09850913869781508736noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-90250035474245761422008-10-26T23:55:00.000+02:002008-10-26T23:55:00.000+02:00Дело не в количестве, а в качестве :)<BR/><BR/>а abstract class ServiceClient, потому что там public string ServiceUri{ get; set; }Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-38529202534316929522008-10-26T23:45:00.000+02:002008-10-26T23:45:00.000+02:00В случае с LogViewer - не факт, что для 3-5 методов выборки есть смысл городить спецификацию.<BR/><BR/>Почему <BR/>abstract class ServiceClient <BR/>а не<BR/>interface ISeviceClient?Kigorwhttp://www.blogger.com/profile/09850913869781508736noreply@blogger.com