Comments on Систематизация автоматизации: Хороший дизайн должен быть SOLID: TOP-5 архитектур...

Well, I can't fully agree with this opinion. I.e. ...

2009-11-12T13:15:12.235+02:00

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.

Seems like OOP languages themselves give us a good...

2009-11-10T23:42:56.026+02:00

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 :)

>>Я иммел ввиду, что предпочтительней использовать...

2008-11-17T10:14:00.000+02:00

>>Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости).
>> К тому же писать тесты к "интерфейсному коду" гораздо легче.

И в чем была бы разница? Мы же не далем гибкость ради гибкости. Если есть ситуации в которых абстраный луче (а в данном примере он действительно лучше), то зачем городить интерфейс, а потом еще абстракную реализацию?

Ну, если так, то в данном конкретном случае этот и...

2008-10-27T01:24:00.000+02:00

Ну, если так, то в данном конкретном случае этот интерфейс не не нес бы никакой смысловой нагрузки для примера.

По этой же причине реализации методов заменены тремя точками :)

Но в реальном коде в нем был бы смысл, безусловно.

"Или я что-то не понимаю, но если я просто вместо ...

2008-10-27T01:11:00.000+02:00

"Или я что-то не понимаю, но если я просто вместо abstract class напишу interface - то я получу ошибки в духе "'HttpServiceClient' does not implement interface member 'ServiceClient.ServiceUri'". Так что, наврерное, не оно :)"
- ну если не реализовать, то и не скомпилится.
Я иммел ввиду, что предпочтительней использовать интерфейсы (к вопросу о гибкости). К тому же писать тесты к "интерфейсному коду" гораздо легче.

А относительно TDD и спецификаций, то вы бы его по...

2008-10-27T01:06:00.000+02:00

А относительно TDD и спецификаций, то вы бы его получили на стадии рефакторинга в какой-то момоент времени, а певое приближение дейтсвительно было бы классом с кучей методов.

Но соглашусь, что все дейтсвительно зависит от ситуации и массы других предпослок. Посему стоит рассматривать вариант "стоит или не стоит городить спецификации" и рассуждать о сложности реализации тсключительно в конкретном контексте.

Или я что-то не понимаю, но если я просто вместо a...

2008-10-27T01:00:00.000+02:00

Или я что-то не понимаю, но если я просто вместо abstract class напишу interface - то я получу ошибки в духе "'HttpServiceClient' does not implement interface member 'ServiceClient.ServiceUri'". Так что, наврерное, не оно :)

public interface IServiceClient{ // Property de...

2008-10-27T00:46:00.000+02:00

public interface IServiceClient
{
// Property declaration:
string ServiceUri
{
get;
set;
}
}

- оно?

"Вы же не станете утверждать, например, что IoC нужен только для того, чтобы клиент имел возможность гибкой конфигурации приложения?"
- не стану. Зато стану утверждать, что для этого всегда обязательно внедрять в проект Spring.NET или еще что-то подобное.

Используя ТДД, я бы получил самое простое решение, которым Спецификация не является.

Дело не в гибкости для клиента. Вы же не станете у...

2008-10-27T00:35:00.000+02:00

Дело не в гибкости для клиента. Вы же не станете утверждать, например, что IoC нужен только для того, чтобы клиент имел возможность гибкой конфигурации приложения?

Да и по объему кода едва ли разница столь значима, чтобы говорить о значительных преимуществах одного из методов.

Кроме того, если вы будете использовать TDD, то у вас такое решение со спецификациями получиться само собой :)

А по поводу интерфейсов я не понял, к чему вы клоните. Лучше приведите код :)

Дело в деньгах клиента, который платит. Гибкое реш...

2008-10-27T00:13:00.000+02:00

Дело в деньгах клиента, который платит. Гибкое решение должно предполагать окупаемость.

http://msdn.microsoft.com/en-us/library/64syzecx.aspx - на счет интерфейсов

Дело не в количестве, а в качестве :)а abstract cl...

2008-10-26T23:55:00.000+02:00

Дело не в количестве, а в качестве :)

а abstract class ServiceClient, потому что там public string ServiceUri{ get; set; }

В случае с LogViewer - не факт, что для 3-5 методо...

2008-10-26T23:45:00.000+02:00

В случае с LogViewer - не факт, что для 3-5 методов выборки есть смысл городить спецификацию.

Почему
abstract class ServiceClient
а не
interface ISeviceClient?