Приведите пример использования интерфейсов

@polsok · Регистрация: 20.03.2011

Author24 — интернет-сервис помощи студентам

Любую задачу с интерфейсами, по моему мнению, гораздо проще решать используя статические классы или методы. Копирование классов решается тем, что вместо классов объявляем структуры.
А можете привести пример где интерфейсы действительно упрощают задачу в отличии от вышеназванных методов?

@Noob.net · 28.12.2012, 14:11

Сообщение от polsok

Любую задачу с интерфейсами, по моему мнению, гораздо проще решать используя статические классы или методы.

0_о
Реализуйте-ка мне множественное наследование с помощью классов.

Сообщение от polsok

Копирование классов решается тем

Не понимаю о каком копировании вы говорите? если объекты - то они передаются по ссылке..

@polsok · 28.12.2012, 14:14 **[ТС]**

1 на счет множественного наследования, можете привести пример, когда действительно необходимо множественное наследование

2 этим то структуры от классов и отличаются. С каждым вызовом появляется новая копия, а не ссылка на тот же самый объект.

@Noob.net · 28.12.2012, 14:24

Сообщение от polsok

на счет множественного наследования,

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

Простите за банальность примеров:

C#

interface IClickableButton
    {
        event Action Click;
    }
 
    interface IColorButton
    {
        Color Color { get; set; }
    }
 
    interface IButtonWithText
    {
        string Text { get; set; }
    }

Теперь когда создаем кнопку выбираем какие свойства мы должны реализовать.

У Троэлсена был пример с автомобилем.
Допустим есть интерфейс радио и автомобиль.
Создаем автобус и решаем нужно ли нам там радио.

//как-то плохо сейчас с реальными примерами,надеюсь логика понятна?

@polsok · 28.12.2012, 14:32 **[ТС]**

Сообщение от Noob.net

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

Простите за банальность примеров:

C#

interface IClickableButton
    {
        event Action Click;
    }
 
    interface IColorButton
    {
        Color Color { get; set; }
    }
 
    interface IButtonWithText
    {
        string Text { get; set; }
    }

Теперь когда создаем кнопку выбираем какие свойства мы должны реализовать.

Да но создавая класс наследующий эти интерфейсы мы должны описать все свойства и методы интерфейсов. Т. е. по сути мы те же самые методы и свойства описываем 2 раза: в интерфейсах и наследуемых классах. А если я создам класс без наследования, то мне надо будет эти методы и свойства описать только в этом классе. Нафига тогда интерфейсы спрашивается?

@Learx · 28.12.2012, 14:44

Имеем некоторый универсальный алгоритм для любых типов данных, но для его выполнения должны быть определена некоторая операция с этим типом данных.
Например, нам необходимо определить функцию, которая вычисляет сумму квадратов. Для простых чисел операцию квадрата вполне ясна, а если у нас более сложный тип данных?
Например, комплексные числа:

C#

class Complex
{
   public   double Re;
   public   double Im;
}

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

C#

interface ISqr<T>
        {
            T Sqr(T obj);
        }

И теперь реализуем интерфейс:

C#

class Complex: ISqr<Complex>
{
   public   double Re;
   public   double Im;
 Complex(double re, double im)
            {
                Re = re; Im = im;
            }
            public Complex Sqr()
            {
                return new Complex(Re * Re - Im * Im, 2 * Re * Im);
            }
}

И спокойно создаем нашу универсальную функцию:

C#

static void MyMethod<T> ( List<T> massiv) where T : ISqr
        {
              T res;
              foreach(T m in massiv)
              {
                   res+=m.Sqr();
              }
        }

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

Добавлено через 6 минут
Второй пример. Интерфейс определяет поведение объекта.
И вот человек говорит что создал новый некоторый класс, который реализует интерфейс SuperIntarface.

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

Добавлено через 4 минуты
Реальное применение очень широко в библиотеке .Net
Сходу перечислить можно очень много.
Для того чтоб сравнивать объекты по значению, а не по ссылке классы реализуют интерфейс IComparable
Для сериализации - ISerializable
Для привязки данных контрола к динамическим данным - ICustomTypeDescriptor
Для использования linq - IEnumarable
и так далее...

@Tessen · 28.12.2012, 15:16

Сообщение от polsok

Да но создавая класс наследующий эти интерфейсы мы должны описать все свойства и методы интерфейсов. Т. е. по сути мы те же самые методы и свойства описываем 2 раза: в интерфейсах и наследуемых классах. А если я создам класс без наследования, то мне надо будет эти методы и свойства описать только в этом классе. Нафига тогда интерфейсы спрашивается?

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

@Noob.net · 28.12.2012, 15:37

Сообщение от polsok

Нафига тогда интерфейсы спрашивается?

Да я и сам не знаю.. пойду дальше ишачить свои библиотеки на Си

@kravam · 28.12.2012, 16:09

Noob.net, Отбрехиваться нехорошо. Лучше уж промолчать; вопрос на самом деле архиважный.

Я так понимаю, все эти прибамбасы новоявленные никакого выигрыша ни в скорости ни в экономии памяти не дают, их цель- сделать программирование удобным для программиста. Что ж, цель благая.

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

Ну хорошо, интерфейс, то-сё. А вот так не проще было сделать:
(псевдокод):

переменная типа "квадрат комлексного числа"= <функция вычисляющая квадраты всего и вся> <а вот тут типа шаблона надо написать> (ну и параметр- само комплексное число);

А в теле функции лепи себе на здоровье квадраты разных переменных сколько душе угодно

Всё, то же самое. Но на одну сущность меньше, на интерфейс. Понятное дело, никакого выигрыша в скорости не будет, на уровне ассемблера всё едино. Но лишне единицей мышления меньше.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Но, допустим, мне возразят- наша политика это ООП, а не процедурное программирование. Типа универсализм и прочая. Ладно. Но! Самое-то главное:

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

ТАМ ГДЕ ЕСТЬ ОДНО, ЗАЧЕМ ПРИДУМЫВАТЬ ВТОРОЕ?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Да, а ведь надо ещё разобраться- как это метод возвращает тип интерфейса?! Для меня интерфейс это именно что абстрактная сущность. Его нет. Так, обёртка (пусть даже удобная) А оказывается мы можем некую эфемерность возвращать типа "интерфейс"

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Оно, конечно, всё равно чел (и я) поймём что за чем и всё равно в голове всё рано или поздно устаканится. Но можно было бы обойтись и без этого; только время сэкономилось бы.

Не по теме:

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

@Learx · 28.12.2012, 16:39

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

теперь ваша цитата.
Само собой что чем более универсальный инструмент, тем сложнее им пользоваться. Так было всегда так и будет. Я не могу сказать чем руководствовалась Microsoft создав интерфейсы и отменив множественное наследование. Но это и породило подобные вопросы. Хотя .. если глубже копнуть во множественное наследование, то там проблем больше чем подобных вопросов возникших из-за интерфейсов.

Сообщение от kravam

возвращает тип интерфейса

1. Это необходимо для использования подобных цепочек:

C#

1 2	List<int> i = new List<int>(); i.Where(...).Select(...).Concat(..).Distinct();

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

Сообщение от kravam

Но можно было бы обойтись и без этого

Да можно. можно вовсе вернутся к низкоуровнему программированию. Но какая тогда будет производительность?

@Tessen · 28.12.2012, 16:51

Сообщение от kravam

Да, а ведь надо ещё разобраться- как это метод возвращает тип интерфейса?! Для меня интерфейс это именно что абстрактная сущность. Его нет. Так, обёртка (пусть даже удобная) А оказывается мы можем некую эфемерность возвращать типа "интерфейс"

а возвращение абстрактного класса вас совсем-совсем не смущает?

@kravam · 28.12.2012, 17:30

Как не смущать? Меня всё смущает, чего я не вижу, тут вопросы обучения идут уже. Я для себя в голове отмечаю- абстрактный класс это такой же класс, как и остальные потому, что в нём есть (или могут быть) РЕАЛИЗОВАННЫЕ методы. Ну и остальное пропускаю мимо ушей (не потому, что я ученик нерадивый, а потому что это "человеческое, слишком человеческое") до поры до времени.

А в интерфейсе методов нет, даже конструктора!

Вот эти-то отличия меня, как ученика и смущают.

Хотя на самом деле это наверное, вопросы обучения, а не программирования. Растолкать, разжевать, с десяток упражнений дать НА ИНТЕРФЕЙС- и всё устаканится. А тут все самоучки, учителей нет, всё сами. Помню в школе у меня возни вопрос- на хрена нужны отрицательные числа? Учитель объяснил, потому что он БЫЛ. А изучал бы сам- полгода бы доходил до ответа.

@Tessen · 28.12.2012, 17:43

понимаете вы передаете не интерфейс, а ссылку на объект, реализующий интерфейс
т.е.
если вы запишете

C#

1	IEnumerable<string> ilist=new List<string>();

то вы сможете вызывать любые интерфейсы IEnumerable<T> по этой ссылке, в этом случае будет вызываться вполне описанная в классе List реализация метода
если вы запишете вместо List что нибудь другое будет вызвана другая реализация методов
отсутствовать реализация не может т.к. вы не можете собственно создать интерфейс например

C#

1	new IEnumerable<string>()

таким образом
интерфейс это гарантия что данные методы там ЕСТЬ и они реализованы

Добавлено через 5 минут
к примеру вам нужно создать несколько коллекций и метод который будет выдавать кол-во элементов в них
вы можете создать интерфейс который будет предоставлять метод Count, написать что метод принимает объект, реализующий этот интерфейс и в этом методе просто вызывать Count для любого объекта
как это выглядит без интерфейсов:
а) вы наследуете ВСЕ от определенного класса в котором метод Count есть, довольно неудобно, да и не факт что вам не надо наследоваться еще от чего-нибудь (а наследоваться можно только от 1 класса напоминаю)
б) вы при помощи извращений и рефлексии выдергиваете информацию о наличии метода Count в каждом классе перед тем как вызывать ваш метод

@Learx · 28.12.2012, 17:46

kravam, как раз про абстрактный класс вы не правы. Абстрактный класс это тот класс, который имеет НЕ реализованные методы. И служат они как шаблон для классов наследников. И отличается от интерфейсов тем что МОЖЕТ реализовать методы а так же тем, что можно наследоваться только от одного класса и от множества интерфейсов.

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

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

@m0nax · 28.12.2012, 18:18

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

@kolorotur · 28.12.2012, 20:36

Сообщение от polsok

можете привести пример где интерфейсы действительно упрощают задачу в отличии от вышеназванных методов?

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

@Noob.net · 29.12.2012, 00:33

Сообщение от m0nax

сначала пишешь интерфейс
если видишь(пусть даже в уме) что у наследников одинаковый функционал переделываешь в абстрактный класс

А еще очень полезный совет,мне уж точно показался таковым при чтении книг :

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

@tm-team · 29.12.2012, 03:18

Интерфейсы дают возможность "полиморфизма"!!!!!

Ноги проблемы растут изза того, что C# не поддерживает множественное наследование.

Пример с утками: У нас есть 3 вида уток
Кряквы, Черки, Гоголи.

У них есть метод кряк: void KRAK_MOTHERFUCKER()

Логично - что базовый класс это "Абстрактная утка" которая умеет крякать. "Абстрактная утка" происходит от класса "абстрактной птицы", а та, в свою очередь от класса "абстрактного животного". А вот три наследника - по своему реализуют метод "КРЯЯЯЯ".

Теперь есть ~~массив~~ стадо уток, и мы хотим заставить его крякать:

C#

1 2	Duck[] stado = //создаётся както наше стадо foreach(var duck in stado) duck.KRAK_MOTHERFUCKER();

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

И тут, программист пишет ЭТО:

C#

object[] stado = // создаётся както наше стадо
foreach(var d in stado)
{
    if(d is Duck) (d as Duck).KRAK_MOTHERFUCKER();
    else
    {
        //и вот тут начинается кровавая баня
        //ибо завтра появятся тысячи типов различных предметов
        //и обкуренные дизайнеры все как один будут считать их утками
    }
}

Заказчики не любят кровавых бань и программиста увольняют, а тот в свою очередь на последок говорит: "Это не я, это С#".
Заказчики чешут во лбах, открывают шилдта и обнаруживают.... дада - interface

Оставляем всё тоже самое, и пишем интерфейс:

C#

interface IKrakable //имеющий возможность както крякать...
{
    void KRAK_MOTHERFUCKER();
}

Теперь все кто реализует этот интерфейс, умеют крякать с точки зрения C#.

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

C#

1 2	IKrakable[] stado = //создаётся наше стадо foreach(var d in stado) d.KRAK_MOTHERFUCKER();

Добавлено через 15 минут

Сообщение от polsok

Любую задачу с интерфейсами, по моему мнению, гораздо проще решать используя статические классы или методы. Копирование классов решается тем, что вместо классов объявляем структуры.
А можете привести пример где интерфейсы действительно упрощают задачу в отличии от вышеназванных методов?

Ооп язык C# написан На С++, который написан на С, который написан на Assembler-е. ЛЮБАЯ ООП-прога может быть написана на асме, но ооп не просто так появилось. Слабосвязанность и повторное использование кода. Полиморфизм при сложных случаях итд... Те приёмы которые назвали вы, относятся к композиции(при грамотном использование) или к быдлокоду(при неграмотном). Однако композиция, во многих задачах будет давать очень много лишнего кода(а значит и ошибок) для связывания частей, описываемых различными объектами.

@polsok · 29.12.2012, 10:52 **[ТС]**

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

@Tessen · 29.12.2012, 11:14

нет не можем, интерфейс не может содержать реализацию методов никакую

@polsok 7 / 6 / 6 Регистрация: 20.03.2011 Сообщений: 350
	29.12.2012, 10:52 [ТС]	19
	спасибо за вразумительный ответ, только получается интерфейс выступает в роли своеобразной заглушки: любое существо реализующее данный интерфейс должно крякать, но мы не можем указать как оно будет крякать. Или все таки можем через интерфейс? 0

@Noob.net Темная сторона .Net 592 / 489 / 39 Регистрация: 21.07.2012 Сообщений: 1,668
	28.12.2012, 14:11	2
	Сообщение от polsok Любую задачу с интерфейсами, по моему мнению, гораздо проще решать используя статические классы или методы. 0_о Реализуйте-ка мне множественное наследование с помощью классов. Сообщение от polsok Копирование классов решается тем Не понимаю о каком копировании вы говорите? если объекты - то они передаются по ссылке.. 0

@polsok 7 / 6 / 6 Регистрация: 20.03.2011 Сообщений: 350
	28.12.2012, 14:14 [ТС]	3
	1 на счет множественного наследования, можете привести пример, когда действительно необходимо множественное наследование 2 этим то структуры от классов и отличаются. С каждым вызовом появляется новая копия, а не ссылка на тот же самый объект. 0

@Tessen 713 / 680 / 126 Регистрация: 30.03.2012 Сообщений: 1,124
	28.12.2012, 15:16	7
	Сообщение от polsok Да но создавая класс наследующий эти интерфейсы мы должны описать все свойства и методы интерфейсов. Т. е. по сути мы те же самые методы и свойства описываем 2 раза: в интерфейсах и наследуемых классах. А если я создам класс без наследования, то мне надо будет эти методы и свойства описать только в этом классе. Нафига тогда интерфейсы спрашивается? предположим на секундочку что вам придется пройтись по всем цветным элементам и сменить их цвет (ну вот дали вы пользователю возможность цветовой гаммы) с интерфейсом вы это делаете в одном foreach, с вашими методами вы каждую кнопку будете ковырять рефлексией что ли? (усложним вопрос - что будет если в одном из 10 классов кнопок вы сделаете опечатку? реализация интерфейса просто вам об этом скажет в момент компиляции, а без них?) 1

@Noob.net Темная сторона .Net 592 / 489 / 39 Регистрация: 21.07.2012 Сообщений: 1,668
	28.12.2012, 15:37	8
	Сообщение от polsok Нафига тогда интерфейсы спрашивается? Да я и сам не знаю.. пойду дальше ишачить свои библиотеки на Си 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,679
	28.12.2012, 16:09	9
	Noob.net, Отбрехиваться нехорошо. Лучше уж промолчать; вопрос на самом деле архиважный. Я так понимаю, все эти прибамбасы новоявленные никакого выигрыша ни в скорости ни в экономии памяти не дают, их цель- сделать программирование удобным для программиста. Что ж, цель благая. А теперь обратимся к примеру Learx. И сразу вопрос. Я, честно говоря, в деталях не разобрался со всем этим делом, но что скажу, за то отвечаю Ну хорошо, интерфейс, то-сё. А вот так не проще было сделать: (псевдокод): переменная типа "квадрат комлексного числа"= <функция вычисляющая квадраты всего и вся> <а вот тут типа шаблона надо написать> (ну и параметр- само комплексное число); А в теле функции лепи себе на здоровье квадраты разных переменных сколько душе угодно Всё, то же самое. Но на одну сущность меньше, на интерфейс. Понятное дело, никакого выигрыша в скорости не будет, на уровне ассемблера всё едино. Но лишне единицей мышления меньше. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Но, допустим, мне возразят- наша политика это ООП, а не процедурное программирование. Типа универсализм и прочая. Ладно. Но! Самое-то главное: "Одна из самых больших трудностей программирования на С# состоит в правильном выборе между интерфейсом и абстрактным классом в тех случаях, когда требуется описать функциональные возможности, но не реализацию. В подобных случаях рекомендуется придерживаться следующего общего правила: если какое-то понятие можно описать с точки зрения функционального назначения, не уточняя конкретные детали реализации, то следует использовать интерфейс. А если требуются некоторые детали реализации, то данное понятие следует представить абстрактным классом. " ТАМ ГДЕ ЕСТЬ ОДНО, ЗАЧЕМ ПРИДУМЫВАТЬ ВТОРОЕ? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Да, а ведь надо ещё разобраться- как это метод возвращает тип интерфейса?! Для меня интерфейс это именно что абстрактная сущность. Его нет. Так, обёртка (пусть даже удобная) А оказывается мы можем некую эфемерность возвращать типа "интерфейс" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Оно, конечно, всё равно чел (и я) поймём что за чем и всё равно в голове всё рано или поздно устаканится. Но можно было бы обойтись и без этого; только время сэкономилось бы. Не по теме: Начинал я кодить на Pascal, наблюдал там - функции, процедуры (две разные вещи!) параметры- значения. параметры- переменные; казалось круто и необходимо. А потом перешёл на Си поразился насколько всё просто может быть с этими функциями если обойтись безо всей этой мишуры. 0

@Tessen 713 / 680 / 126 Регистрация: 30.03.2012 Сообщений: 1,124
	28.12.2012, 16:51	11
	Сообщение от kravam Да, а ведь надо ещё разобраться- как это метод возвращает тип интерфейса?! Для меня интерфейс это именно что абстрактная сущность. Его нет. Так, обёртка (пусть даже удобная) А оказывается мы можем некую эфемерность возвращать типа "интерфейс" а возвращение абстрактного класса вас совсем-совсем не смущает? 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,679
	28.12.2012, 17:30	12
	Как не смущать? Меня всё смущает, чего я не вижу, тут вопросы обучения идут уже. Я для себя в голове отмечаю- абстрактный класс это такой же класс, как и остальные потому, что в нём есть (или могут быть) РЕАЛИЗОВАННЫЕ методы. Ну и остальное пропускаю мимо ушей (не потому, что я ученик нерадивый, а потому что это "человеческое, слишком человеческое") до поры до времени. А в интерфейсе методов нет, даже конструктора! Вот эти-то отличия меня, как ученика и смущают. Хотя на самом деле это наверное, вопросы обучения, а не программирования. Растолкать, разжевать, с десяток упражнений дать НА ИНТЕРФЕЙС- и всё устаканится. А тут все самоучки, учителей нет, всё сами. Помню в школе у меня возни вопрос- на хрена нужны отрицательные числа? Учитель объяснил, потому что он БЫЛ. А изучал бы сам- полгода бы доходил до ответа. 0

@Learx 1057 / 864 / 195 Регистрация: 31.03.2010 Сообщений: 2,521
	28.12.2012, 17:46	14
	kravam, как раз про абстрактный класс вы не правы. Абстрактный класс это тот класс, который имеет НЕ реализованные методы. И служат они как шаблон для классов наследников. И отличается от интерфейсов тем что МОЖЕТ реализовать методы а так же тем, что можно наследоваться только от одного класса и от множества интерфейсов. И вы совершенно правы, что самому учиться оочень сложно. Надо уметь выделить из всего потока информации ключевые факты и практическое применение. К сожалению, система обучения больше заостряет внимание на самих знаниях и теории, чем на смысле и применении. Я постарался объяснить и смысл и применение. Если что-то непонятно попробуйте сформировать четкий вопрос. Во-первых правильный вопрос это уже половина ответа, во-вторых чтоб его сформировать вы должны уже что-то понять. 0

@m0nax 1274 / 975 / 113 Регистрация: 12.01.2010 Сообщений: 1,971
	28.12.2012, 18:18	15
	все это намного проще чем кажется, на реальных примерах выбор очевиден сначала пишешь интерфейс если видишь(пусть даже в уме) что у наследников одинаковый функционал переделываешь в абстрактный класс общего кода нет - значит отставляешь как есть интерфейс 0

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	28.12.2012, 20:36	16
	Сообщение от polsok можете привести пример где интерфейсы действительно упрощают задачу в отличии от вышеназванных методов? Интерфейс - это формализация паттерна "Стратегия" на уровне спецификации языка. Паттерн - это устоявшееся и хорошо себя зарекомендовавшее решение определенной категории проблем. Если хотите узнать, где хорошо использовать интерфейсы, поищите примеры использования паттерна "стратегия" - именно для облегчения его реализации интерфейсы и были внедрены в языки программирования. 1

@Noob.net Темная сторона .Net 592 / 489 / 39 Регистрация: 21.07.2012 Сообщений: 1,668
	29.12.2012, 00:33	17
	Сообщение от m0nax сначала пишешь интерфейс если видишь(пусть даже в уме) что у наследников одинаковый функционал переделываешь в абстрактный класс А еще очень полезный совет,мне уж точно показался таковым при чтении книг : Делаем в точности да наоборот. Пишем классы,потом перечитываем,ищем общий функционал, - вырезаем его и кидаем в абстрактный. А вдруг и не нужна реализация методов в абстрактном классе,а вдруг и классов таких нужно больше - больно громадный функционал - и тут оп "в сиянии света солнечного,который отбивается от луны" на помощь приходит капитан "Интерфейс" 0

@Tessen 713 / 680 / 126 Регистрация: 30.03.2012 Сообщений: 1,124
	29.12.2012, 11:14	20
	нет не можем, интерфейс не может содержать реализацию методов никакую 1