Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Общие вопросы по .NET и C# > Интерфейсы, в чем суть ? отличия от подмешиваний

Автор: fell 29.8.2012, 10:20

Всем привет Итак для чего используются интерфейсы. Например для решения такой задачи - использовать 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 Вопрос в чем суть интерфейсов тогда ? получается что они не равнозначны подмешиваниям и в данном случае подмешивания лучше справляются с задачей, чем интерфейс.

Автор: diadiavova 29.8.2012, 22:40

Цитата(fell @  29.8.2012,  11:20 )  Эта задача хорошо решается в руби, используя подмешивания. Подмешивания - это что-то типа такого? http://msdn.microsoft.com/ru-ru/library/bb383977%28VS.100%29.aspx Цитата(fell @  29.8.2012,  11:20 ) а хотелось бы сразу от двух, чтобы использовать методы AA и BB Если бы это делалось для того, чтобы использовать методы, то по всей видимости в интерфейсах была бы возможна реализация методов. Раз там этого нет, то очевидно же, что предназначены они не для этого. Цитата(fell @  29.8.2012,  11:20 ) Вопрос в чем суть интерфейсов тогда ? В первую очередь благодаря им пишется полиморфный код. Смысл как раз в том и есть, что с объектами всех типов, реализующих один интерфейс, можно работать единообразным способом, то есть у них гарантированно будут реализованы все члены задекларированные в интерфейсе и назначение их будет одинаковым, хотя реализация может отличаться в корне. Именно потому интерфейсы и не имеют реализации методов, что в разных типах реализация может коренным образом отличаться друг от друга, но с точки зрения обрабатывающего кода это будут одни и те же методы. Ну как-то так

Автор: fell 30.8.2012, 10:56

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

Автор: Экскалупатор 30.8.2012, 11:45

Цитата(fell @  30.8.2012,  09:56 ) применяют их не часто не соглашусь, применяют достаточно часто. вопрос в необходимости. мне к примеру этот подход не очень нравится, теряется какая то четкость. так что использую только если по другому никак. я может не совсем понял что ты хочешь сделать, но ты же можешь отнаследовать два интерфейса в одном классе, реализовать все методы обоих интерфейсов и дальше наследоваться уже от этого класса. и будет тебе счастье в виде всех имплементированных методов в одном наследнике. но сдается мне этот код начнет плохо пахнуть...

Автор: diadiavova 31.8.2012, 09:35

Цитата(fell @  30.8.2012,  11:56 ) extension методы похожи в принципе, в руби однако гибче подход, там можно и статические методы использовать и инстансовые.  А зачем нужны статические расширения? В шарпе расширение - это и так статический метод какого-то класса и ты его можешь так же вызвать, только зачем? Вся прелесть в том, чтобы вызывать его у объекта, уже содержащего какие-то данные, которые и будут обрабатываться, вместо того, чтобы передавать этот объект как аргумент. Цитата(fell @  30.8.2012,  11:56 ) Однако сдается мне применяют их не часто Во-первых, непонятно откуда дровишки. Во-вторых, если в шарпе даже и не делают как в рубях, то обычно причина в том, что для решения задачи есть более удобные средства. Ну и в-третьих, все-таки у каждого свой стиль, а то, что что-то используют меньше - вообще ни о чем не говорит, тебе предоставили такую возможность, а пользуешься ты ей или нет - дело твое. Цитата(Экскалупатор @  30.8.2012,  12:45 )  мне к примеру этот подход не очень нравится, теряется какая то четкость.  Да ладно, что уж там теряется? Наоборот есть возможность сделать код более лаконичным и читабельным. Кроме того, ну естественно ведь, когда методы для обработки строки скажем вызываются у объекта типа стринг, а не с помощью каких-нибудь хелперов. Цитата(Экскалупатор @  30.8.2012,  12:45 ) так что использую только если по другому никак. Всегда можно сделать по другому, просто иногда это оборачивается жутким геморроем   Цитата(Экскалупатор @  30.8.2012,  12:45 ) я может не совсем понял что ты хочешь сделать, но ты же можешь отнаследовать два интерфейса в одном классе, реализовать все методы обоих интерфейсов и дальше наследоваться уже от этого класса.  Он как раз и недоумевает по поводу того, что реализация интерфейсов ничего не дает в смысле добавления функциональности типу, поскольку методы все равно приходится реализовывать самому в каждом типе. А он хочет как при наследовании - реализовал и все уже есть. Цитата(Экскалупатор @  30.8.2012,  12:45 ) но сдается мне этот код начнет плохо пахнуть... Почему?   Это нормальная практика вообще-то.

Автор: Экскалупатор 31.8.2012, 22:48

Цитата(diadiavova @  31.8.2012,  08:35 ) Цитата(Экскалупатор @  30.8.2012,  12:45 Найти цитируемый пост) но сдается мне этот код начнет плохо пахнуть... Почему?  smile Это нормальная практика вообще-то.  )) ну я не настаиваю на абсолютности своего мнения. мне просто не очень нравится когда в проекте существует +100500 расширений, скажем, для string, и в итоге получается что мы можем вызвать этот метод для любой вообще строки в проекте. это единственное что мне не очень нравится в этом подходе. в остальном я только за. понятно, что все нужно применять с умом, но порой некоторые плюшки в кривых руках, становятся похожи на бензопилу в руках у макаки, и никто не может поручиться, что она решит вытворить в следующий момент

Автор: diadiavova 1.9.2012, 01:17

Цитата(Экскалупатор @  31.8.2012,  23:48 )  мне просто не очень нравится когда в проекте существует +100500 расширений, скажем, для string, и в итоге получается что мы можем вызвать этот метод для любой вообще строки в проекте. это единственное что мне не очень нравится в этом подходе. Кто мешает актуальные для конкретного круга задач расширения оформить в отдельном пространстве имен и импортировать это пространство именно (и только) там, где этот круг задач решается?  Цитата(Экскалупатор @  31.8.2012,  23:48 ) понятно, что все нужно применять с умом, но порой некоторые плюшки в кривых руках, становятся похожи на бензопилу в руках у макаки, и никто не может поручиться, что она решит вытворить в следующий момент В кривых руках все что угодно может иметь точно такой же эффект. Что до расширений, то при разумном использовании они дают огромные возможности и нет разумных причин, для того, чтобы ими не воспользоваться.

Автор: diadiavova 1.9.2012, 10:10

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

Автор: fell 1.9.2012, 10:35

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

Автор: diadiavova 1.9.2012, 10:59

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

Автор: fell 3.9.2012, 10:32

Модуль в руби это mix-in, что то вроде абстрактного класса, только с полной реализацией методов. То есть в классе указываем, какой модуль используем и можем пользоваться методами модуля. Код module B   def test     "test"   end  end class A include B   def moduletest      test   end end a = A.new a.moduletest => "test" Для большей наглядности. Код module B   def testb     "testB"   end end module C   def testc     "testC"   end end class A include B include C end a = A.new a.testb => "testB" a.testc => "testC" Код module B   def test     "test"   end   end class A  extend B end a = A.test => "test" в C# получается наиболее похожая тема extension методы. Хотя если подключить класс через using, то можно так же пользоваться методами подключенного класса.

Автор: diadiavova 3.9.2012, 10:59

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)