Спустя 42 минуты, 53 секунды (11.11.2011 - 13:23) imbalance_hero написал(а):
m4a1fox
Думаю, ответы будут: "я применял там и там, для пафоса!"
Думаю, ответы будут: "я применял там и там, для пафоса!"
Спустя 2 минуты, 45 секунд (11.11.2011 - 13:26) m4a1fox написал(а):
imbalance_hero
| Цитата |
| "я применял там и там, для пафоса!" |
Да хоть бы такие услышать! Понять просто не могу! Вот стоит задача передо мной - нужно понять! Или, коли понял как они работают, нафиг еще больше знать переходить к фабрике?!.... а если они там используются, а я не в зуб ногой! Блин, напоминает школу, первые пары прогулял - все, больше вообще можно не ходить, ибо все равно въехать в тему - трудно, так как основ - нет!
Спустя 14 минут, 21 секунда (11.11.2011 - 13:40) linker написал(а):
Когда не хочется шибко заморачиваться с наследованием, ну и когда хочется, но нет возможности множественного наследования.
Спустя 15 минут, 6 секунд (11.11.2011 - 13:55) linker написал(а):
Ну это если не серьёзно. А так, например, который я уже не раз приводил. Есть сокеты, есть файлы и те и те являются частью системы ввода вывода, т.е. туда можно писать и от туда можно читать - write() и read() соответственно. Если с сокетами всё просто, то у файлов есть ещё более высокоуровневые методы: назначение прав, удаление, создание, определение типа, размера и т.д. Т.е. налицо множественность. Можно конечно создать абстрактный класс ввода-вывода, от него унаследовать ещё классы для работы с сокетами, файлами. Формально файлы являются элементом файловой системы, куда попадают директории. Кроме этого файлы могут разделяться по типу расширения и т.д. Тюею если заниматься наследованием, то получится ахриненная иерархия, а где-то будут ещё и костыльные элементы. Но можно просто определить интерфейсы и имплементить нужные тому или иному классу.
Спустя 56 минут, 23 секунды (11.11.2011 - 14:52) caballero написал(а):
m4a1fox
Например ты хочешь сделать классы валидаторов
для емейла, зипкода и т.д.
чтобы с ними можно было работать универсальным способом
объявляешь
interface validator
{
function validate($data);
}
в результате классы валидаторов имплементирующие жтот интерфейс будут иметь одинаковый метод
и можно будет например кнопить их к элементам формы единообразным способом
Почему не базовый класc?
потому что у валидаторов (в данном примере) нет никаких общих данных или методов которые можно вынести в базовый класс
Кроме того валидаторы уже могут быть отнаследованы от какого нибудь TMyFrameworkObject
Вообще нет смысла заморачиватся такими вопросами - это телега впереди лошади. Начнешь кодировать, возникнут архитектурные вопросы и тогда перебирая варианты решений сам поймешь где надо интерфейс а где нет.
Например ты хочешь сделать классы валидаторов
для емейла, зипкода и т.д.
чтобы с ними можно было работать универсальным способом
объявляешь
interface validator
{
function validate($data);
}
в результате классы валидаторов имплементирующие жтот интерфейс будут иметь одинаковый метод
и можно будет например кнопить их к элементам формы единообразным способом
Почему не базовый класc?
потому что у валидаторов (в данном примере) нет никаких общих данных или методов которые можно вынести в базовый класс
Кроме того валидаторы уже могут быть отнаследованы от какого нибудь TMyFrameworkObject
Вообще нет смысла заморачиватся такими вопросами - это телега впереди лошади. Начнешь кодировать, возникнут архитектурные вопросы и тогда перебирая варианты решений сам поймешь где надо интерфейс а где нет.
Спустя 3 минуты, 11 секунд (11.11.2011 - 14:55) m4a1fox написал(а):
caballero
Спасибо! Теперь понятнее....
Спасибо! Теперь понятнее....
Спустя 3 часа, 36 минут, 25 секунд (11.11.2011 - 18:31) Zerstoren написал(а):
| Цитата (linker @ 11.11.2011 - 10:40) |
| Когда не хочется шибко заморачиваться с наследованием, ну и когда хочется, но нет возможности множественного наследования. |
Линкер, а что вы имели ввиду под множественным наследованием?
Спустя 2 минуты, 36 секунд (11.11.2011 - 18:34) vital написал(а):
class a { function foo1()}
class b { function foo2()}
class c extends a,b { foo3 ()};
d=new c()l
d->foo1();
d->foo2();
d->foo3();
т.е. наследование сразу неск-х классов.
Пхп так не умеет.
class b { function foo2()}
class c extends a,b { foo3 ()};
d=new c()l
d->foo1();
d->foo2();
d->foo3();
т.е. наследование сразу неск-х классов.
Пхп так не умеет.
Спустя 5 часов, 41 минута, 28 секунд (12.11.2011 - 00:15) Greg1978 написал(а):
| Цитата (linker @ 11.11.2011 - 10:40) |
| но нет возможности множественного наследования. |
За это представители типизированных языков не погладили по голове Вас (применение множественного наследование в аспектах интерфейса)а если бы погладили голова была бы квадратной. Множественное наследование и так не ахти как воспринимается, а здесь ещё его в интерфейсы.
Спустя 6 минут, 23 секунды Greg1978 написал(а):
Интерфейсы задают всего лишь строгую обязанность классам, которые принимают на себя обязанность (извините за тавтологию) реализации определённых в них методах.То есть все последующие классы должны иметь такие же методы == интерфейсы, которые объявлены в рамках Interface. Это даёт разработчикам и другим классам (объектам) клиентам (использующим класс с определённым интерфейсом) уверенность в том что при обращении и вызове методы будут однозначно реализованы (а в типизированных языках ещё и будут определены типы аргументов к передаче, число их и возвращаемый тип из метода): иначе интерпретатор или компилятор вызовут ошибку в работе и укажут разработчику о ней.
Спустя 15 минут, 54 секунды Greg1978 написал(а):
| Цитата (m4a1fox @ 11.11.2011 - 09:40) |
| Доброго всем времени суток! Извечные вопросы в ООП мучают меня. Вот ответьте, кто-то же когда то же применял в своей практике интерфейсы... Как они работаю - я разобрался. Но вот когда их применяют мне не понятно! То есть, в каких конкретных случаях вы из применяли? Спасибо все кто ответит! Тему в принципе можно было и во Флейм засунуть, так как кода тут скорее не будет, а так, чистый диалог! |
Постоянно, так как архитектура без интерфейсов, так колышущийся лист. Изменил интерфейс у одного объекта или класса, и это повлекло за собой массу ошибок в других областях архитектуры. Если он будет заявлен в interface то даже IDE сможет проконтролировать Ваши изменения, не говоря что интерпретатор или компилятор поможет обнаружить ошибку более быстрее. Но и не в этом преимущества. Они в том что архитектор работая на уровне интерфейсов не обращает внимание на реализацию (классы - объекты), что даёт возможность к разделению труда, соответственно к повышению производительности и читабельности кода (на уровне концепции и на уровне реализации), то что разделение труда ведёт к повышению его же самого в этом не должно быть ни каких сомнений.
Спустя 1 час, 12 минут, 42 секунды (12.11.2011 - 01:28) m4a1fox написал(а):
То есть по сути интерфейсы только определяют какие точно методы должны быть в том или ином классе....
Спустя 44 минуты, 49 секунд (12.11.2011 - 02:13) Greg1978 написал(а):
| Цитата (m4a1fox @ 11.11.2011 - 22:28) |
| То есть по сути интерфейсы только определяют какие точно методы должны быть в том или ином классе.... |
совершенно верно, а в случае типизированных языков ещё и типы передаваемых аргументов и возвращаемых
Спустя 5 минут, 17 секунд (12.11.2011 - 02:18) caballero написал(а):
| Цитата |
| Интерфейсы задают всего лишь строгую обязанность дочерним классам реализации определённых в них методах. |
только не дочерним - классам реализующим (implementation) этот интерфейс
Спустя 26 минут, 35 секунд (12.11.2011 - 02:45) Greg1978 написал(а):
| Цитата (caballero @ 11.11.2011 - 23:18) | ||
только не дочерним - классам реализующим (implementation) этот интерфейс |
очень правильно!!! сейчас исправлю, это очень важный момент
Спустя 2 дня, 6 часов, 8 минут, 45 секунд (14.11.2011 - 08:54) linker написал(а):
| Цитата (Greg1978 @ 12.11.2011 - 00:15) |
| За это представители типизированных языков не погладили по голове Вас (применение множественного наследование в аспектах интерфейса)а если бы погладили голова была бы квадратной. Множественное наследование и так не ахти как воспринимается, а здесь ещё его в интерфейсы. |
Ну вот когда мы перейдём на типизированные языки, или PHP станет таковым, тогда и будем думать кого и как гладить по головке. А так, благодаря справедливому негодованию, PHP 5.4 имеет в себе трейтсы.