Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
Не для каких либо частных случаев, а именно как основной подход.

Итак — Вариант 1 (для каждого класса необходимо иметь не менее 1 интрефейса. Получаем полный контроль над видимостью)

public interface IAbc
{
 // пустой
}

public interface IAbcd:IAbc
{
  //часто всего один метод, что бы потом из интерфейсов можно было конструировать различные объекты
  void Method1(); 
}

.....

internal class Abc:IAbc
{
  public void F1() {...}
  public void Fn() {...}
}

internal class Abcd:Abc,IAbcd
{
  public void Method1() {...}
  public void Fx1() {...}
  public void Fxn() {...}
}
.....
void Xxxx()
{
  // доступ и работа только через интерфейсы, напрямую к объектами запрещено обращаться
  IAbcd t1 = new Abcd(); 
  t1.Method1(); // можно
  t1.F1(); // нельзя
}

Вариант 2 (интерфейсы только когда действительно необходимо, нефиг плодить лишнее)

internal class Abc
{
  protected void F1() {...}
  protected void Fn() {...}
  // можно было и в интерфейс выкинуть, если бы была необходимость обязательной имплементации
  public virtual Method1() {} 
}

internal class Abcd:Abc
{
  public override void Method1() {...}
  protected void Fx1() {...}
  protected void Fxn() {...}
}

void Xxxx()
{
  Abcd t1 = new Abcd();
  t1.Method1(); // можно
  t1.F1(); // нельзя
}

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

Здравствуйте, AlexNek, Вы писали:

AN>Итак — Вариант 1 (для каждого класса необходимо иметь не менее 1 интрефейса

Нафига?

AN>Получаем полный контроль над видимостью)

Какая то ерунда.

AN>Возможно информации маловато, но пока не хочу перегружать подробностями. Надеюсь различия подходов понятны.

Ответ на исходный вопрос простой и сложный одновременно. Интерфейсы в 99% случаев применяют там, где необходимо изолировать публичные контракты какой то подсистемы. Собственно, все.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AN>>Итак — Вариант 1 (для каждого класса необходимо иметь не менее 1 интрефейса

AVK>Нафига?
Ну концепт у человека такой. Пищит так как будто только что из Таиланда приехал
"Какой изумительный концепт". И я никак не могу врубится почему.

AN>>Получаем полный контроль над видимостью)

AVK>Какая то ерунда.
Ну не совсем полная, мне приводился где-то следующий пример (просто как принцип, а не как пример рабочего кода):

interface IText
{
  public string Text { get; set; }
}

class LabelEx:Label,IText
{
}

...
 Control ctl = new LabelEx();
 // имеем возможность пользоваться как обычным контролом "внутри пакета"
 ctl.BackgroundColor = Color.Blue;
 form.Add(ctl); 
...
 // наружу выдается только возможность прочитать/установить текст
 IText label = GetControl;   
 label.Text = "Sample";

Небольшие изменения и получаем универсальный "конструктор" нужных объектов "наружу".

interface IAllowed:IText,IBitmap
{

}

class LabelEx:Label,IAllowed
{
...
}

Я просто пока не могу сформулировать затыки такого подхода, хотя ж..ой чувствую что то должно быть.

Здравствуйте, AlexNek, Вы писали:

AVK>>Нафига?
AN>Ну концепт у человека такой.

Ну, альтернативно одаренных программистов в природе встречается достаточно, чтобы очередной сильно удивлял.

AN>Ну не совсем полная, мне приводился где-то следующий пример (просто как принцип, а не как пример рабочего кода):

Ну и? Ради такой ерунды плодить кучу интерфейсов? По мне так стандартный internal вполне себе покрывает основные потребности.
Интерфейсы нужны, когда ты хочешь явно задекларировать какие то контракты для внешнего кода. Вот там они незаменимы.

AN>Я просто пока не могу сформулировать затыки такого подхода, хотя ж..ой чувствую что то должно быть.

Да затык то очень простой — куча тупой работы программиста ради крайне незначительного бенефита.

Здравствуйте, AlexNek, Вы писали:

AN>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>Не для каких либо частных случаев, а именно как основной подход.

AN>void Xxxx()
AN>{
AN> // доступ и работа только через интерфейсы, напрямую к объектами запрещено обращаться
AN> IAbcd t1 = new Abcd();
AN> t1.Method1(); // можно
AN> t1.F1(); // нельзя
AN>}

"void Xxxx()" не должен сам создавать объекты, иначе теряется весь смысл

Здравствуйте, AlexNek, Вы писали:

AN>Возможно информации маловато, но пока не хочу перегружать подробностями. Надеюсь различия подходов понятны.

Представьте, что вы директор театра и нанимаете на работу актера Пожарова. Будете ли вы в трудовом договоре с Ивановым писать, что именно он должен делать и говорить на сцене? Наверное, нет. Во-первых, сегодня у вас Пожаров, а завтра Иванов. Если договор с Пожаровым потеряется, как с Ивановым договариваться? Во-вторых, партнерша Пожарова по спектаклю актриса... мнэ... Петрова должна знать, что Пожаров будет делать и говорить, как ей иначе репетировать? А дать ей почитать договор с Пожаровым нельзя — там последним пунктом указана огромная зарплата Пожарова, чего Петрова не потерпит. В-третьих, зачем Пожарова заставлять читать набор реплик вплоть до "Домком — око недреманное", если роль Аллилуи известна всякому приличному театралу? Подумав, вы пишете в договоре: "...Пожаров принимается на следующие роли: Аллилуи, Лоханкина...".

Далее, вам надо принять на работу бабу Дусю, уборщицу. Ее обязанности не настолько жестко закреплены, чтобы каждое слово регламентировалось. К тому же, она, в отличие от предшественницы бабы Нюры, просит назначить ее убирать поздно по вечерам, а не рано утром. Следовательно, вы можете прямо в ее договоре написать: "вытирать пыль с одиннадцати до двенадцати ежевечерне". Эти детали никого не интересуют: ни Пожарова, ни Иванова, ни Петрову. Они к этому времени уже покидают театр. Будете ли вы писать роль уборщицы, вводить ее в спектакли и принимать бабу Дусю с указанием этой роли? Я — нет. Хотя еще и не такие режиссеры бывают. Особенно, когда первый раз прочитают про Сценические Паттерны ("...паттерн Вешалка был придуман еще Станиславским...").

Надеюсь, различия подходов понятны.

Здравствуйте, AndrewVK, Вы писали:


AVK>Ну и? Ради такой ерунды плодить кучу интерфейсов? По мне так стандартный internal вполне себе покрывает основные потребности.
AVK>Интерфейсы нужны, когда ты хочешь явно задекларировать какие то контракты для внешнего кода. Вот там они незаменимы.

а почему бы не задекларировать контракты для внутреннего кода?
с точки зрения конкретного класса, все остальные — "внешние" по отношению к нему

конечно если класс всегда и только всегда будет жить внутри своего модуля (сборки), то в этом действительно смысла нет
но если есть шанс что кто-то захочет реюзнуть класс, скопировав его в другой проект, и не хочет тянуть всю сборку?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AN>>Я просто пока не могу сформулировать затыки такого подхода, хотя ж..ой чувствую что то должно быть.

AVK>Да затык то очень простой — куча тупой работы программиста ради крайне незначительного бенефита.
Это парируется, зато хорошая ххх (вместо ххх могут подставлятся различные умные слова)
Нужны "технические" затыки. Пожалуй, попрошу у него пример для поиграться и попробую примерчик не нагло "убить".

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, AlexNek, Вы писали:

AN>>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>>Не для каких либо частных случаев, а именно как основной подход.

AN>>void Xxxx()
AN>>{
AN>> // доступ и работа только через интерфейсы, напрямую к объектами запрещено обращаться
AN>> IAbcd t1 = new Abcd();
AN>> t1.Method1(); // можно
AN>> t1.F1(); // нельзя
AN>>}

A>"void Xxxx()" не должен сам создавать объекты, иначе теряется весь смысл
Да не хотелось много текста писать, надо было строчки разделить многоточием.

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, AndrewVK, Вы писали:


AVK>>Ну и? Ради такой ерунды плодить кучу интерфейсов? По мне так стандартный internal вполне себе покрывает основные потребности.
AVK>>Интерфейсы нужны, когда ты хочешь явно задекларировать какие то контракты для внешнего кода. Вот там они незаменимы.

A>а почему бы не задекларировать контракты для внутреннего кода?
A>с точки зрения конкретного класса, все остальные — "внешние" по отношению к нему

A>конечно если класс всегда и только всегда будет жить внутри своего модуля (сборки), то в этом действительно смысла нет
A>но если есть шанс что кто-то захочет реюзнуть класс, скопировав его в другой проект, и не хочет тянуть всю сборку?
Копировать не собираются, просто хотят иметь ящик внутри которого можно делать все, а снаружи только то, что позволено, причем объекты и снаружи и внутри хочется иметь одинаковые.

Здравствуйте, Abyx, Вы писали:

A>а почему бы не задекларировать контракты для внутреннего кода?

Зачем?

A>с точки зрения конкретного класса, все остальные — "внешние" по отношению к нему

С точки зрения класса — вполне возможно. Но я говорил про точку зрения дизайна программы или модуля программы в целом.

A>но если есть шанс что кто-то захочет реюзнуть класс, скопировав его в другой проект, и не хочет тянуть всю сборку?

Зависит от назначения этого класса. Если это просто набор хелперов, то смысла выносить контракты наружу никакого. А вот явно введенные слои абстракции — их контракты надо описывать интерфейсами практически всегда.

Здравствуйте, AlexNek, Вы писали:

AN>Это парируется, зато хорошая ххх (вместо ххх могут подставлятся различные умные слова)

Веру техническими аргументами не оспоришь.

AN>Нужны "технические" затыки.

Это вполне технический. Ну если хочешь — технологический затык. Потому что синтаксический мусор не только усложняет первоначальное написание, но и засоряет код при чтении ненужными сущностями.
Но если тебя таки интересуют чисто технические проблемы — есть несколько.
1) Вызов интерфейса в большинстве практических случаев — двойная косвенность. Т.е. вызов накладнее даже виртуального вызова, не говоря уж про раннесвязанный.
2) Особенность реализации interface table (аналог vmt для интерфейсов) в рантайме такова, что каждый загруженный в память интерфейс увеличивает потребную для загрузки всех последующих классов память (ЕМНИП на 4/8 байт в зависимости от разрядности). При большом количестве интерфейсов это обеспечивает вполне заметный оверхед по памяти. На это накладывается оверхед по хранению метаданных самих интерфейсов.
3) Создание делегата на метод интерфейса в некоторых ситуациях приводит к сильному замедлению этого конструирования.

Здравствуйте, AlexNek, Вы писали:

Как по мне:

(Все случае когда интерфейс напрашивается сам собой — опускаем).

Если вы делаете один единственный класс с уникальной функциональностью — то этот класс уже имеет свой публичный интерфейс — незачем городить лишнюю абстракцию, которую вдобавок ещё и нужно поддерживать.

Если вы делаете классы, которые имплементят какие-то уже известные интерфейсы — не ленитесь создавать интерфейсы, заодно с отсылками к первоисточниками.

Пример: это наличие хорошо задокументированных интерфейсов из W3C DOM (XML): Element, Node, Attribute и т.п. Весь вэб на них держится. И всё идеально укладывается в дотнетные интерфейсы. Что в реальности? System.Xml это набор классов "в себе" — подменить имплементацию невозможно, хотя это заложено изначально, там на правах internal даже есть DOMImplementation (нафига тока оно надо, если оно internal и не выполняет своих функций?). Правда в этом случае в большей степени — это перманентная проблема MS — всё время переизобретать колесо и погоня за призраками.

В этом же смысле XLinq — обратная сторона медали — в тыщу раз лучше, а код внутри — просто прелесть. Перестали копировать W3C DOM, — на все случаи не годиться, но покрывает 99% потребностей. А те, что не покрывает, например потребность быстрой навигации назад (previous sibling и т.п.) — благодаря annotations — решаема. В этом случае следовать интерфейсам — было бы вредно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Интерфейсы в 99% случаев применяют там, где необходимо изолировать публичные контракты какой то подсистемы.
И в 98% случаев для обеспечения ООП-шного полиморфизма.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AN>>Это парируется, зато хорошая ххх (вместо ххх могут подставлятся различные умные слова)

AVK>Веру техническими аргументами не оспоришь.
Я уже и не знаю какие аргументы использовать.
Просто боюсь подумать, что туда кому то другому может прийдется что то добавлять. Он еще туда MVP паттерн запиндрючил, получилось не менее 30 классов и интерфейсов без учета различных элементов отображения.
А основные классы создает через активатор по динамически создаваемым именам. Блин, и книги отобрать низзя

Здравствуйте, AlexNek, Вы писали:

AN>Просто боюсь подумать, что туда кому то другому может прийдется что то добавлять. Он еще туда MVP паттерн запиндрючил, получилось не менее 30 классов и интерфейсов без учета различных элементов отображения.
AN>А основные классы создает через активатор по динамически создаваемым именам. Блин, и книги отобрать низзя
У меня есть проект в котором используется куча интерфейсов. Достался в наследство.
Интерфейсы эти: для DataAccess, для BussinessRules, для фасадов. Проблема только в том, что ничего кроме головной боли они не добавляют, потому что, вместо того что бы написать новый метод в одном (трёх) местах — приходится рыскать и добавлять ещё и во всех интерфейсах (т.е. вместо трёх — шесть). При чём, как бы оно там ни было правильно — но реально, никаких DI или тестов — нет. Т.е. это живёт само в себе. Такое нужно давить, интерфейса на фасаде хватило бы. Интерфейс проще добавить, если он реально необходим, тем более в шарпе, с его способносятм к рефакторингу.

Здравствуйте, AlexNek, Вы писали:

AN>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>Не для каких либо частных случаев, а именно как основной подход.

В качестве основного подхода можно порекомендовать задавать себе почаще вопрос при принятии подобных решений — а какую конкретную проблему мы решаем. Если не конкретно, а сильно в общем, то интерфейсы и большинство паттернов, на них базирующиеся, позволяют рещать проблемы так или иначе связанные с гибкостью кода. Но как нам известно из закона сохранения сложности за всё нужно платить. Плата за интерфейсы — количественное усложнение кода и увеличение, порой весьма существенное, сложности восприятия кода. Тотальное использование интерфейсов скорее всего приведёт к тотальной потери восприятия кода, что в более менее сложном проекте неизбежно закончится полной или частичной потерей контроля над кодом. Там где на поиск и решение проблемы потребовалось бы пару минут будет уходить по нескольку часов, а там где нужно было бы несколько часов или дней, придётся тратить недели и месяцы.

В простонародье подобные решения называются overdesign/overarchitecture, когда фактическая получаемая выгода от принятых решений низка или полностью отсутсвует, а привнесённые существенные усложнения тупо не замечаются или старательно игнорируются. Но, к сожалению, сложность очень коварна. Если бы мы имели дело с одним, пусть даже большим, монолитным куском некой субстанции, то можно было бы напрячься и одним махом разрешить все проблемы, которые от неё исходят. Но сложность не монолит, а скорее куча мелкой крошки и песка, и с каждой крошкой и песчинкой приходтся иметь дело индивидуально. Лучше не нести весь этот мусор в код с самого начала. Голова она хоть и большая, но у программиста ей и без этого есть о чём болеть.

Здравствуйте, SV., Вы писали:

SV.>Представьте, что вы директор театра и нанимаете на работу актера Пожарова. Будете ли вы в трудовом договоре с Ивановым писать, что именно он должен делать и говорить на сцене? ...
Довольно абстрактно сказано, примерно так же, как и в случае с большим количеством ненужных интерфейсов.

AndrewVK всё верно говорил: всё должно согласовываться с принципом достаточности, необходимости и разумности и только. В каждом конкретном случае надо думать, просто думать... А не бездумно применять наугад тот или иной паттерн. Если речь идёт об интерфейсах — это всего лишь контракты для сокрытия реализации... а реализацию нужно скрывать только там, где это крайне необходимо, например: плагины, компоненты, модули, семейства сущностей, имеющих общие черты (фигуры, например)... Вот и всё. Ничего лишнего...

Здравствуйте, AlexNek, Вы писали:

AN>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>Не для каких либо частных случаев, а именно как основной подход.
Оказалось даже еще хуже чем предполагал

    public interface IDeviceModel :
        IBaseModel,
        IPropertyDataSummary,
        IPropertyModelInformation
    {
        IPropertyCommunicationEventsSummary Communication{get;    }

        IPropertyComPortSummary Port{get;}

        void SetExternalDeviceData(DeviceDataItemsSet collection);

        void SetExternalConfigData( DeviceDataItemsSet collection );
    }

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AlexNek, Вы писали:

IT>Но как нам известно из закона сохранения сложности за всё нужно платить.

Прям таки и сохранения? Как не крутись, а сложность будет одинаковая?

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, AlexNek, Вы писали:

AN>>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>>Не для каких либо частных случаев, а именно как основной подход.
AN>Оказалось даже еще хуже чем предполагал

Круто! Каждое свойство вывести в интерфейс.
Я правильно понимаю что интерфейсы используются (реализуются) однократно?

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, AlexNek, Вы писали:

AN>>>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>>>Не для каких либо частных случаев, а именно как основной подход.
AN>>Оказалось даже еще хуже чем предполагал

H>Круто! Каждое свойство вывести в интерфейс.
H>Я правильно понимаю что интерфейсы используются (реализуются) однократно?
Скорее всего да, до этого пока еще не дошел, пока просто "собираю информацию"
И это еще самая простая часть, все диаграмма "раздела" (не модуля!) не видна даже при 10% зуме.
Что делать не представляю, данная часть переписывается уже официально второй раз, но можно считать что это 3 попытка этого-же человека.
Первый раз было все просто, но катастрофически медленно было открытие формы. Сейчас по скорости претензий нет, но иметь такой кодо-монстр, брр.

Здравствуйте, AlexNek, Вы писали:

AN>Я уже и не знаю какие аргументы использовать.
AN>Просто боюсь подумать, что туда кому то другому может прийдется что то добавлять. Он еще туда MVP паттерн запиндрючил, получилось не менее 30 классов и интерфейсов без учета различных элементов отображения.
AN>А основные классы создает через активатор по динамически создаваемым именам. Блин, и книги отобрать низзя

В таких случаях не аргументы надо искать, а использовать административный ресурс тимлида.

Здравствуйте, fddima, Вы писали:

F> Интерфейсы эти: для DataAccess, для BussinessRules, для фасадов. Проблема только в том, что ничего кроме головной боли они не добавляют, потому что, вместо того что бы написать новый метод в одном (трёх) местах — приходится рыскать и добавлять ещё и во всех интерфейсах (т.е. вместо трёх — шесть).

Поставь решарпер.

Здравствуйте, artelk, Вы писали:

AVK>>Интерфейсы в 99% случаев применяют там, где необходимо изолировать публичные контракты какой то подсистемы.
A>И в 98% случаев для обеспечения ООП-шного полиморфизма.

Для полиморфизма в чистом виде, если не нужно МН, хватает и обычных виртуальных методов.

Здравствуйте, AndrewVK, Вы писали:

AVK>Поставь решарпер.
Лично мне он не нужен. Гораздо лучше заняться реальными проблемами кода, а не заниматься просто созданием тысячи интерфейсов, тем более, когда в моём конкретном случае — эти абстракции — чистая фикция.

Здравствуйте, fddima, Вы писали:

AVK>>Поставь решарпер.
F> Лично мне он не нужен. Гораздо лучше заняться реальными проблемами кода, а не заниматься просто созданием тысячи интерфейсов, тем более, когда в моём конкретном случае — эти абстракции — чистая фикция.

А если интерфейс по делу применен? Тоже не нужен? Или ты считаешь, что интерфейсы в любой ситуации избыточны?

Здравствуйте, AndrewVK, Вы писали:

AVK>А если интерфейс по делу применен? Тоже не нужен? Или ты считаешь, что интерфейсы в любой ситуации избыточны?
Конечно же интерфейсы нужны. Я считаю что применение интерфейсов в любой ситуации (т.е. без дела) — это реально избыточно.

Здравствуйте, AlexNek, Вы писали:

AN>Оказалось даже еще хуже чем предполагал

Есть ощущение, что Ваш коллега недозагружен работой. Ему делать нечего — вот он и придумывает себе работу. У меня был такой же коллега. Он как-то для системы скинов решил реализовать свой .NET (на C++). Получился монстр, который увеличил время компиляции всей системы раз в 10. Состоял он из множества бесполезных классов, одним из шедевров которых был класс по имени BoolConcept.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AN>>Я уже и не знаю какие аргументы использовать.
AN>>Просто боюсь подумать, что туда кому то другому может прийдется что то добавлять. Он еще туда MVP паттерн запиндрючил, получилось не менее 30 классов и интерфейсов без учета различных элементов отображения.
AN>>А основные классы создает через активатор по динамически создаваемым именам. Блин, и книги отобрать низзя

AVK>В таких случаях не аргументы надо искать, а использовать административный ресурс тимлида.
К сожалению, все не так просто. В данном конкретном случае проблему нужно решать только "мирным" путем.

Здравствуйте, AlexNek, Вы писали:

AN>К сожалению, все не так просто. В данном конкретном случае проблему нужно решать только "мирным" путем.

Если твой коллега уперся рогом, мирным путем решить проблему не получится.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, AlexNek, Вы писали:

AN>>Оказалось даже еще хуже чем предполагал

КЛ>Есть ощущение, что Ваш коллега недозагружен работой. Ему делать нечего — вот он и придумывает себе работу.
Тут ситуация немного другая, мне кажется. Нафиг бы ему тогда еще и дома работать. У меня с ним абсолютно разные "стили мышления" и "сцепляемся" мы с ним относительно часто и по "мелочам", причем в результате часто удается найти гораздо лучшее решение. Данный пример я отношу уже к "крупной нестыковке". Пару лет назад, была тоже "крупная" никак с концептом не сходились, время только расставило все по местам.

Здравствуйте, AlexNek, Вы писали:

здесь

Здравствуйте, AndrewVK, Вы писали:

AVK>Для полиморфизма в чистом виде, если не нужно МН, хватает и обычных виртуальных методов.
Лучше так: для полиморфизма в чистом виде чаще всего хватает и обычных интерфейсов.
А наследование реализации следует по возможности избегать.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AN>>К сожалению, все не так просто. В данном конкретном случае проблему нужно решать только "мирным" путем.

AVK>Если твой коллега уперся рогом, мирным путем решить проблему не получится.
Тут просто получается "конфликт" концептов. Причем, в каком либо конкретном случае, возможно другой концепт и был бы предпочтительней. Вероятно, если бы решение принял административно кто то третий, то это бы прокатило. Я просто не хочу публично расписывать все ньюансы по которым лучше "не выпедриваться" в данном случае. Но как я уже писал, предыдущий подобный "конфликт" удалось разрешить вполне мирно.
И вроде нашел источник вдохновения Interface-Based Programming

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AlexNek, Вы писали:

AN>>Завязался тут у нас спор с коллегой по поводу "философии программирования". Интересно какие еще мнения будут относительно плюсов и минусов?
AN>>Не для каких либо частных случаев, а именно как основной подход.

IT>В качестве основного подхода можно порекомендовать задавать себе почаще вопрос при принятии подобных решений — а какую конкретную проблему мы решаем.
Удалось узнать, что основное что хотелось сделать — это спрятать от себя же "лишние" свойства стандартного контрола, а ткже добится большей расширяемости и универсальности.
Например его доводы:
1. Есть класс Label, он него наследуем свой и затем отдаем на растерзание только текст или только цвет или оба вместе, но не больше. Композицию не используем по причине того, что свои объекты хотелось без проблем добавлять в стандартный контейнер.
2. Предположим вначале, объект имел возможность издавать звуки, летать и плавать, от него наследованы различные другие. Теперь появилась необходимость создать объект который может только летать и издавать звуки. Нужно переделывать иерархию. А вот если сделать интерфейсы — издавать звуки, летать и плавать, то создавать различные объекты будет нефиг делать, делай любую нужную комбинацию и все. К тому — же одна и таже операция будет называться везде одиннаково (Для IBark будет всегда Bark(), а не в одном месте RunSound(),в другом StartSound(), в третьем Sound() )

IT>Если не конкретно, а сильно в общем, то интерфейсы и большинство паттернов, на них базирующиеся, позволяют рещать проблемы так или иначе связанные с гибкостью кода. Но как нам известно из закона сохранения сложности за всё нужно платить. Плата за интерфейсы — количественное усложнение кода и увеличение, порой весьма существенное, сложности восприятия кода.
На что отвечают, глянь на свой OOP код, он ничуть не проще, зато менее гибок.

IT>Тотальное использование интерфейсов скорее всего приведёт к тотальной потери восприятия кода, что в более менее сложном проекте неизбежно закончится полной или частичной потерей контроля над кодом.
В этом никак не получается убедить.

Здравствуйте, AlexNek, Вы писали:

AN>2. Предположим вначале, объект имел возможность издавать звуки, летать и плавать, от него наследованы различные другие. Теперь появилась необходимость создать объект который может только летать и издавать звуки. Нужно переделывать иерархию. А вот если сделать интерфейсы — издавать звуки, летать и плавать, то создавать различные объекты будет нефиг делать, делай любую нужную комбинацию и все. К тому — же одна и таже операция будет называться везде одиннаково (Для IBark будет всегда Bark(), а не в одном месте RunSound(),в другом StartSound(), в третьем Sound() )

А всё же какие практические задачи решаются? И ещё, только не говори своему другу о существовании dynamic/duck typing, иначе будет полный капец.

IT>>Если не конкретно, а сильно в общем, то интерфейсы и большинство паттернов, на них базирующиеся, позволяют рещать проблемы так или иначе связанные с гибкостью кода. Но как нам известно из закона сохранения сложности за всё нужно платить. Плата за интерфейсы — количественное усложнение кода и увеличение, порой весьма существенное, сложности восприятия кода.
AN>На что отвечают, глянь на свой OOP код, он ничуть не проще, зато менее гибок.

Он проще в мильён раз. Но это становится понятно только если о нём рассуждать не теоретически, а работать с ним практически. Например, при работе с моим ООП кодом мне достаточно одного нажатия кнопки F12, чтобы от вызова функции перейти к её реализации и посмотреть что там и как. Если же это метод интерфейса, то я попадаю на объявление метода интерфейса и дальше начинаю заниматься поисками того что же у меня вызывается в действительности в моём конкретном окружении. Т.е. там где я трачу доли секунды, я вынужен тратить минуты, и чаще всего, после того как найдётся то, что нужно, я уже забуду зачем я всё это искал.

IT>>Тотальное использование интерфейсов скорее всего приведёт к тотальной потери восприятия кода, что в более менее сложном проекте неизбежно закончится полной или частичной потерей контроля над кодом.
AN>В этом никак не получается убедить.

Если с головой всё в порядке, то жизнь переубедит. Иначе — очередная жертва абстракций с искалеченной интерфейсами судьбой.

Здравствуйте, VoidEx, Вы писали:

IT>>Но как нам известно из закона сохранения сложности за всё нужно платить.
VE>Прям таки и сохранения? Как не крутись, а сложность будет одинаковая?

А подумать?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AlexNek, Вы писали:

AN>>2. Предположим вначале, объект имел возможность издавать звуки, летать и плавать, от него наследованы различные другие. Теперь появилась необходимость создать объект который может только летать и издавать звуки. Нужно переделывать иерархию. А вот если сделать интерфейсы — издавать звуки, летать и плавать, то создавать различные объекты будет нефиг делать, делай любую нужную комбинацию и все. К тому — же одна и таже операция будет называться везде одиннаково (Для IBark будет всегда Bark(), а не в одном месте RunSound(),в другом StartSound(), в третьем Sound() )

IT> А всё же какие практические задачи решаются?
Относительно простые задачи "с ньюансами". Есть MDI окошко и есть набор комманд, которые запускаются по выбору пользователя (типа прочитать/записать данные), при выполнении комманд требуется отобразить прогресс бар и текущий/конечный статус, а также отобразить прочитанные данные. Может приходить различный набор данных и каждый элемент данных имеет свой статус. При этом данные могут считываться с различных источников при этом отображение будет несколько разным. Ну так вроде, вкратце.

IT>И ещё, только не говори своему другу о существовании dynamic/duck typing, иначе будет полный капец.
Разрешено пользоваться только 2.0 да и он сам нашел бы.

IT>>>Если не конкретно, а сильно в общем, то интерфейсы и большинство паттернов, на них базирующиеся, позволяют рещать проблемы так или иначе связанные с гибкостью кода. Но как нам известно из закона сохранения сложности за всё нужно платить. Плата за интерфейсы — количественное усложнение кода и увеличение, порой весьма существенное, сложности восприятия кода.
AN>>На что отвечают, глянь на свой OOP код, он ничуть не проще, зато менее гибок.

IT>Он проще в мильён раз. Но это становится понятно только если о нём рассуждать не теоретически, а работать с ним практически.
Тут проблема видимо кто автор. Если просто смотреть код, то будет также проблематично, если концепт не расскажут.

IT>Например, при работе с моим ООП кодом мне достаточно одного нажатия кнопки F12, чтобы от вызова функции перейти к её реализации и посмотреть что там и как.
Это если в отладчике знаешь где точку останова поставить. А так нужно найти вначале соответствующую команду.

IT>>>Тотальное использование интерфейсов скорее всего приведёт к тотальной потери восприятия кода, что в более менее сложном проекте неизбежно закончится полной или частичной потерей контроля над кодом.
AN>>В этом никак не получается убедить.

IT>Если с головой всё в порядке, то жизнь переубедит. Иначе — очередная жертва абстракций с искалеченной интерфейсами судьбой.
Ну так я поэтому и решил опять подождать, а пока представить прототип другого подхода.

Здравствуйте, AlexNek, Вы писали:

IT>> А всё же какие практические задачи решаются?
AN>Относительно простые задачи "с ньюансами". Есть MDI окошко и есть набор комманд, которые запускаются по выбору пользователя (типа прочитать/записать данные), при выполнении комманд требуется отобразить прогресс бар и текущий/конечный статус, а также отобразить прочитанные данные. Может приходить различный набор данных и каждый элемент данных имеет свой статус. При этом данные могут считываться с различных источников при этом отображение будет несколько разным. Ну так вроде, вкратце.

Это описание задачи в целом. Здесь не видны конкретные проблемы и решения именно этих проблем посредством интерфейсов. А может таких проблем и нет вовсе? Тогда зачем нужны все эти интерфейсы?

IT>>Он проще в мильён раз. Но это становится понятно только если о нём рассуждать не теоретически, а работать с ним практически.
AN>Тут проблема видимо кто автор. Если просто смотреть код, то будет также проблематично, если концепт не расскажут.

Это очень легко проверяется при изменении функциональности и фиксе всяких багов. Например, чтобы сделать какое-нибудь мелкое изменение, вроде протяжки дополнительного поля на форму никаких особых концептов знать не нужно. Нужно просто сесть и разобраться что откуда берётся и куда девается. С нормальным дизайном с этой работой справится любой вменяемый разработчик за разумное время. При таком переусложнённом дизайне это может оказаться проблемой для самого автора.

IT>>Например, при работе с моим ООП кодом мне достаточно одного нажатия кнопки F12, чтобы от вызова функции перейти к её реализации и посмотреть что там и как.
AN>Это если в отладчике знаешь где точку останова поставить. А так нужно найти вначале соответствующую команду.

Это как раз можно делать без отладчика. Изучая код я обычно смотрю не только на текущий метод, но и на то, что он вызывает. И вот тут могут быть определённые проблемы.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AlexNek, Вы писали:

IT>>> А всё же какие практические задачи решаются?
AN>>Относительно простые задачи "с ньюансами". Есть MDI окошко и есть набор комманд, которые запускаются по выбору пользователя (типа прочитать/записать данные), при выполнении комманд требуется отобразить прогресс бар и текущий/конечный статус, а также отобразить прочитанные данные. Может приходить различный набор данных и каждый элемент данных имеет свой статус. При этом данные могут считываться с различных источников при этом отображение будет несколько разным. Ну так вроде, вкратце.

IT>Это описание задачи в целом. Здесь не видны конкретные проблемы и решения именно этих проблем посредством интерфейсов.
Всю конкретику будет тяжело перечислить. Попробую просто немного подробней рассказать, что именно сделано с точки зрения "картинки" и только "отображения"
Есть МДИ форма. На ней панелька с кнопочками (как бы Таб элемент) для выбора 6 суб-панелей.
На каждой суб-панели располагается некоторое количество строк (текст-название, текст-значение, картинка-состояние данных). Количество строк может менятся в зависимости от входных данных, некоторые строки могут объединятся в группы с дополнительным заголовком. Все три части: название, значение и состояние "вычисляются" в зависимости от конкретных данных. Строк может быть больше чем помещается на высоту экрана.
Чел просто взял Лабел, Едит и Картинку ну и повставлял их динамически на панель по строкам. От каждого контрола наследовался свой класс с дополнительной функциональностью. (Для доп. функциональности вполне можно было взять интерфейс), но ему еще хотелось, что-бы множество методов стандартного контрола не "было видно", а были видны только те что разрешено иметь данной части строки, ну допустим, фоновый цвет разрешено иметь только текст-значению. Эти же объекты он хотел и напрямую закидывать в панель.
Попутно было еще решено существенно "усовершенствовать" interface-based-programming.

IT>А может таких проблем и нет вовсе? Тогда зачем нужны все эти интерфейсы?
В том то и дело, что нужность именно надуманная, по моему мнению. Дело еще в том что грид в его первозданном виде было запрещено использовать (пользователи компьютеров можно сказать не видели) и он не позволял сделать все что хотелось. Мне только удалось отстоять проперти грид для ввода данных и то только из-за сроков.
IT>>>Он проще в мильён раз. Но это становится понятно только если о нём рассуждать не теоретически, а работать с ним практически.
AN>>Тут проблема видимо кто автор. Если просто смотреть код, то будет также проблематично, если концепт не расскажут.

IT>Это очень легко проверяется при изменении функциональности и фиксе всяких багов. Например, чтобы сделать какое-нибудь мелкое изменение, вроде протяжки дополнительного поля на форму никаких особых концептов знать не нужно.
В данном случае нужно разобраться как вообще у него все работает, все поля закидываются динамически. Нужно найти где они создаются, как им передаются данные и как они эти данные могут обрабатывать. Причем если "спросить решарпера" где используется данный конкретный класс в большинстве случаев получится "нигде", так как многие классы создаются через Активатор.
IT>Нужно просто сесть и разобраться что откуда берётся и куда девается. С нормальным дизайном с этой работой справится любой вменяемый разработчик за разумное время. При таком переусложнённом дизайне это может оказаться проблемой для самого автора.
Вот именно это мне и не удалось доказать. Говорилось — нефиг делать. Можно выполнить практически любой чих и именно из-за наличия интерфейсов на все случаи жизни.
IT>>>Например, при работе с моим ООП кодом мне достаточно одного нажатия кнопки F12, чтобы от вызова функции перейти к её реализации и посмотреть что там и как.
AN>>Это если в отладчике знаешь где точку останова поставить. А так нужно найти вначале соответствующую команду.

IT>Это как раз можно делать без отладчика. Изучая код я обычно смотрю не только на текущий метод, но и на то, что он вызывает. И вот тут могут быть определённые проблемы.
Скорее всего будут проблемы, когда количество строк переваливает за сотни тысяч и вызывается виртуальный метод. И только часами отладки можно найти, что допустим, впереди числа не отображается нолик только из-за того что в параметрах атрибута поля в базовом классе "3-мя уровнями ниже" не так задали маску отображения.

Здравствуйте, AndrewVK, Вы писали:

AVK>...
AVK>Ответ на исходный вопрос простой и сложный одновременно. Интерфейсы в 99% случаев применяют там, где необходимо изолировать публичные контракты какой то подсистемы. Собственно, все.

Ну пожалуй можно добавить —
1. при чтении кода пожалуй чуть проще разобраться если сущность, с которой работаешь представлена через интерфейс, и перейдя на определение интерфейса видишь аккуратное определение нескольких публичных методов без реализации.
2. подобный подход позволяет легче замокировать(застабить) предоставляемою функциональность (например через EasyMock на java).

Конечно такой подход — явный перебор, если применять бездумно для всего. Доменные сущности, например, я бы не стал описывать через интерфейсы.