Всем привет
Итак для чего используются интерфейсы. Например для решения такой задачи - использовать 2 разных метода в двух разных классах. 
class A method AA
class B method BB
Создав класс С мы можем наследоваться только либо от класса А либо от класса B, а хотелось бы сразу от двух, чтобы использовать методы AA и BB.
Для этого есть интерфейсы, создаем интерфейсы
interface A method AA
interface B method BB
Однако далее следует непонятный момент. В интерфейсах мы фактически определяем только названия и сигнатуры методов и имплиментируем их уже в классе, а хотелось бы использовать полностью имплементированные методы. Эта задача хорошо решается в руби, используя подмешивания.

Module A method AA
Module B method BB

class A
 include A
 include B
  method AA
  method BB
Вопрос в чем суть интерфейсов тогда ? получается что они не равнозначны подмешиваниям и в данном случае подмешивания лучше справляются с задачей, чем интерфейс.

Подмешивания - это что-то типа такого?
http://msdn.microsoft.com/ru-ru/library/bb...8VS.100%29.aspx


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

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

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

не соглашусь, применяют достаточно часто. вопрос в необходимости. мне к примеру этот подход не очень нравится, теряется какая то четкость. так что использую только если по другому никак.

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

А зачем нужны статические расширения? В шарпе расширение - это и так статический метод какого-то класса и ты его можешь так же вызвать, только зачем? Вся прелесть в том, чтобы вызывать его у объекта, уже содержащего какие-то данные, которые и будут обрабатываться, вместо того, чтобы передавать этот объект как аргумент.

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


Да ладно, что уж там теряется? Наоборот есть возможность сделать код более лаконичным и читабельным. Кроме того, ну естественно ведь, когда методы для обработки строки скажем вызываются у объекта типа стринг, а не с помощью каких-нибудь хелперов.

Всегда можно сделать по другому, просто иногда это оборачивается жутким геморроем  

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

Почему?   Это нормальная практика вообще-то.

)) ну я не настаиваю на абсолютности своего мнения. мне просто не очень нравится когда в проекте существует +100500 расширений, скажем, для string, и в итоге получается что мы можем вызвать этот метод для любой вообще строки в проекте. это единственное что мне не очень нравится в этом подходе. в остальном я только за.
понятно, что все нужно применять с умом, но порой некоторые плюшки в кривых руках, становятся похожи на бензопилу в руках у макаки, и никто не может поручиться, что она решит вытворить в следующий момент

Это сообщение отредактировал(а) Экскалупатор - 31.8.2012, 22:52

Кто мешает актуальные для конкретного круга задач расширения оформить в отдельном пространстве имен и импортировать это пространство именно (и только) там, где этот круг задач решается? 

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

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

В понимании интерфейсов я немного продвинулся после заметки от доктора ) Просто где то слышал фразу, что мол проблему множественного наследования в С# и некоторых других языках решают интерфейсы. По факту это оказалось немного не так.
По поводу использовать методы нескольких классов через инстансы, подход очевидный, но почему тогда применяют модули в руби, а не работают с инстансами. Можно даже не через инстансы, а просто объявить класс статическим типа Concole.Write() и пользоваться методами класса без создания экземпляров.

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

Фактически интерфейс - это инструмент, с помощью которого разные классы могут между собой взаимодействовать, не накладывая дополнительных ограничений, которые есть, если использовать класс. Простой пример: ты создаешь библиотеку, которой будут пользоваться другие программы. Есть в ней какой-то метод, выполняющий некоторую обработку передаваемого ему объекта. Если ты определишь тип аргумента, указав класс, то ограничишь круг обрабатываемых объектов этим классом и его подклассами. В то же самое время, в этом методе ты можешь вызывать пару-тройку простых методов аргумента и наличия этих методов в аргументе вполне достаточно, чтобы объект можно было обработать. Так вот вопрос в том, какой смысл ограничивать круг возможных аргументов одним классом, когда можно типизировать его интерфейсом, в котором объявлены именно те методы и с той сигнатурой, которые требуются для данного случая? Далее, если кому-то надо будет обработать собственный объект твоим методом, ему достаточно будет реализовать в своем классе этот интерфейс(без ограничений по наследованию) и твой метод спокойно проглотит этот объект. То есть с помощью интерфейса создатель класса показывает другим классам как нужно работать с этим объектом.

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

Модуль в руби это mix-in, что то вроде абстрактного класса, только с полной реализацией методов. То есть в классе указываем, какой модуль используем и можем пользоваться методами модуля.


Для большей наглядности.



в C# получается наиболее похожая тема extension методы. Хотя если подключить класс через using, то можно так же пользоваться методами подключенного класса.

Это сообщение отредактировал(а) fell - 3.9.2012, 10:40

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