Re[2]: NET:Интерфейсы против классов
От: hardcase Пират http://nemerle.org
Дата: 16.11.11 08:25
Оценка: +1
Здравствуйте, AlexNek, Вы писали:

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


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

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

Круто! Каждое свойство вывести в интерфейс.
Я правильно понимаю что интерфейсы используются (реализуются) однократно?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 16.11.11 09:01
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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


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

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

H>Круто! Каждое свойство вывести в интерфейс.

H>Я правильно понимаю что интерфейсы используются (реализуются) однократно?
Скорее всего да, до этого пока еще не дошел, пока просто "собираю информацию"
И это еще самая простая часть, все диаграмма "раздела" (не модуля!) не видна даже при 10% зуме.
Что делать не представляю, данная часть переписывается уже официально второй раз, но можно считать что это 3 попытка этого-же человека.
Первый раз было все просто, но катастрофически медленно было открытие формы. Сейчас по скорости претензий нет, но иметь такой кодо-монстр, брр.
Re[7]: NET:Интерфейсы против классов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.11.11 10:23
Оценка:
Здравствуйте, AlexNek, Вы писали:

AN>Я уже и не знаю какие аргументы использовать.

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

В таких случаях не аргументы надо искать, а использовать административный ресурс тимлида.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[8]: NET:Интерфейсы против классов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.11.11 10:23
Оценка:
Здравствуйте, fddima, Вы писали:

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


Поставь решарпер.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[3]: NET:Интерфейсы против классов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.11.11 10:23
Оценка:
Здравствуйте, artelk, Вы писали:

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

A>И в 98% случаев для обеспечения ООП-шного полиморфизма.

Для полиморфизма в чистом виде, если не нужно МН, хватает и обычных виртуальных методов.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[9]: NET:Интерфейсы против классов
От: fddima  
Дата: 16.11.11 10:30
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

Лично мне он не нужен. Гораздо лучше заняться реальными проблемами кода, а не заниматься просто созданием тысячи интерфейсов, тем более, когда в моём конкретном случае — эти абстракции — чистая фикция.
Re[10]: NET:Интерфейсы против классов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.11.11 10:35
Оценка:
Здравствуйте, fddima, Вы писали:

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

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

А если интерфейс по делу применен? Тоже не нужен? Или ты считаешь, что интерфейсы в любой ситуации избыточны?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[11]: NET:Интерфейсы против классов
От: fddima  
Дата: 16.11.11 10:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

Конечно же интерфейсы нужны. Я считаю что применение интерфейсов в любой ситуации (т.е. без дела) — это реально избыточно.
Re[2]: NET:Интерфейсы против классов
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 16.11.11 10:41
Оценка:
Здравствуйте, AlexNek, Вы писали:

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


Есть ощущение, что Ваш коллега недозагружен работой. Ему делать нечего — вот он и придумывает себе работу. У меня был такой же коллега. Он как-то для системы скинов решил реализовать свой .NET (на C++). Получился монстр, который увеличил время компиляции всей системы раз в 10. Состоял он из множества бесполезных классов, одним из шедевров которых был класс по имени BoolConcept.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[8]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 16.11.11 11:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AN>>Я уже и не знаю какие аргументы использовать.

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

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

К сожалению, все не так просто. В данном конкретном случае проблему нужно решать только "мирным" путем.
Re[9]: NET:Интерфейсы против классов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.11.11 11:31
Оценка: +1
Здравствуйте, AlexNek, Вы писали:

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


Если твой коллега уперся рогом, мирным путем решить проблему не получится.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[3]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 16.11.11 11:42
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


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


КЛ>Есть ощущение, что Ваш коллега недозагружен работой. Ему делать нечего — вот он и придумывает себе работу.

Тут ситуация немного другая, мне кажется. Нафиг бы ему тогда еще и дома работать. У меня с ним абсолютно разные "стили мышления" и "сцепляемся" мы с ним относительно часто и по "мелочам", причем в результате часто удается найти гораздо лучшее решение. Данный пример я отношу уже к "крупной нестыковке". Пару лет назад, была тоже "крупная" никак с концептом не сходились, время только расставило все по местам.
Re: NET:Интерфейсы против классов
От: MaxRos  
Дата: 16.11.11 11:58
Оценка:
Здравствуйте, AlexNek, Вы писали:

здесь
Re[4]: NET:Интерфейсы против классов
От: artelk  
Дата: 16.11.11 11:58
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

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

Лучше так: для полиморфизма в чистом виде чаще всего хватает и обычных интерфейсов.
А наследование реализации следует по возможности избегать.
Re[10]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 16.11.11 19:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


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

Тут просто получается "конфликт" концептов. Причем, в каком либо конкретном случае, возможно другой концепт и был бы предпочтительней. Вероятно, если бы решение принял административно кто то третий, то это бы прокатило. Я просто не хочу публично расписывать все ньюансы по которым лучше "не выпедриваться" в данном случае. Но как я уже писал, предыдущий подобный "конфликт" удалось разрешить вполне мирно.
И вроде нашел источник вдохновения Interface-Based Programming
Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
Re[2]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 16.11.11 19:09
Оценка:
Здравствуйте, IT, Вы писали:

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


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

AN>>Не для каких либо частных случаев, а именно как основной подход.

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

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

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

На что отвечают, глянь на свой OOP код, он ничуть не проще, зато менее гибок.

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

В этом никак не получается убедить.
Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
Re[3]: NET:Интерфейсы против классов
От: IT Россия linq2db.com
Дата: 17.11.11 01:38
Оценка: +1
Здравствуйте, AlexNek, Вы писали:

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


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

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

AN>На что отвечают, глянь на свой OOP код, он ничуть не проще, зато менее гибок.

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

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

AN>В этом никак не получается убедить.

Если с головой всё в порядке, то жизнь переубедит. Иначе — очередная жертва абстракций с искалеченной интерфейсами судьбой.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: NET:Интерфейсы против классов
От: IT Россия linq2db.com
Дата: 17.11.11 01:39
Оценка:
Здравствуйте, VoidEx, Вы писали:

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

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

А подумать?
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: NET:Интерфейсы против классов
От: AlexNek  
Дата: 17.11.11 07:25
Оценка:
Здравствуйте, 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>Если с головой всё в порядке, то жизнь переубедит. Иначе — очередная жертва абстракций с искалеченной интерфейсами судьбой.

Ну так я поэтому и решил опять подождать, а пока представить прототип другого подхода.
Re[5]: NET:Интерфейсы против классов
От: IT Россия linq2db.com
Дата: 17.11.11 20:56
Оценка:
Здравствуйте, AlexNek, Вы писали:

IT>> А всё же какие практические задачи решаются?

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

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

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

AN>Тут проблема видимо кто автор. Если просто смотреть код, то будет также проблематично, если концепт не расскажут.

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

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

AN>Это если в отладчике знаешь где точку останова поставить. А так нужно найти вначале соответствующую команду.

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