Область применения интерфейсов объектов.

[NOX]

1. А помоему просто красиво проверить так

 if($myObj instanceof Cacheable) ...

2. Если пишешь что-то за неделю - всё ок, но если работаешь со своим старым кодом или с чужим, приятно увидеть

class MyClass implements Cacheable, Counteable, ArrayAccess

в принципе зная что за интерфейсы - понятно какой функионал реализует класс. Для ознакомления с интерфейсами я бы рекомендовал позаморачиваться с SPL

 

[Gigahard]

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

 

[fixxxer]

ну оспорь =)

 

[dr-sm]

множественное наследование предпологает также наследование реализации, например mix-in в С++, и не всегда также какой-то интерфейс наследуется.

-~{}~ 03.08.08 16:05:

те интерфейсы это частный случай.

 

[Страшный Злодей]

И меня тот же вопрос уже давно занимает. Чем ООП лучше процедурного? И я также подозреваю, что чем-то лучше, коль так много о нём говорят и пишут профессионалы... но чем лучше не понимаю. Очевидно для понимания мне не хватает мозга.

Из того, что прочитал здесь, понял две вещи:
1) Использование ООП позволяет легче отлавливать ошибки
2) При ООП, код становится более читаемым

ИМХО и первое и второе звучит не очень убедительно... не могу согласиться ни с одним пунктом.

Может найдется добрый человек, который покажет на примере кода, преимущество ООП на процедурным стилем?

 

[zerkms]

Страшный Злодей
мало того, что он становится более читабельным (хоть ты и не согласишься - но это так), но при определённых навыках повышается его реюзабельность.

Может найдется добрый человек, который покажет на примере кода, преимущество ООП на процедурным стилем?

как такового преимущества не бывает - есть "удобнее абстрактному 'тебе' в данном конкретном случае".

 

[HraKK]

Страшный Злодей
Элементарно - процедурном коде на больших системах далеко не уедешь.
Все становится монолитным и фиг что потом изменишь добавишь нормально.

 

[флоппик]

Элементарно - процедурном коде на больших системах далеко не уедешь.
Все становится монолитным и фиг что потом изменишь добавишь нормально.

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

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

-~{}~ 04.08.08 15:01:

Камрад напарник прокомментировал:

[13:55] фоффко:
только это все метание жемчуга перед свиньями
[13:56] фоффко:
нельзя объяснить человеку схуяли это ООП лучше процедурного подхода
[13:56] фоффко:
он на любой твой пример приведет код, где «то же самое» сделано в процедурах и «проще»

 

[HraKK]

флоппик
Скорее соглашусь чем нет. Но у меня почему-то волосы встают дыбом если вижу большую систему не на ООП.

 

[флоппик]

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

 

[zerkms]

флоппик
какими "объектами" позволяет мыслить процедурный подход?

 

[флоппик]

zerkms, подход не связан с проектированием напрямую. Что тебе _технически_ мешает ввести условные абстракции, уровня обьекта, и отладить их, только на процедурах?
Вынести ряд функций и переменных в отдельный файл, дать им префиксы, как вид реализации области видимости? технически - ничего не мешает. Более того, в свое время так и реализовывалась «объектность» в языках, не имеющих ее поддержки.
Еще раз повторюсь, ООП - это в первую очередь уровень абстракции, метод _проектирования_ системы, а не код, классы, свойства, методы.
Я же надеюсь, вы не просто кодер, а еще и мыслить умеете?

 

[zerkms]

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

а еще и мыслить умеете

ути пути

 

[fixxxer]

нет, ну можно конечно, первым параметром передавать всегда $this, а все вызовы делать косвенно - то есть получится call_user_func($this['method'], $this....). только смысл?

 

[zerkms]

fixxxer
и что получится? а где наследование? а где полиморфизм? (ладно - инкапсуляцию ещё можно "представить" в виде функций)
;-)

 

[atv]

zerkms, флоппик уже не раз упомянул о разнице между Объктно-Ориентированным Программированием и Объектно-Ориентированным Проектированием, а ты продолжаешь её игнорировать в своих рассуждениях.

как вы без непосредственно классов/объектов/методов собираетесь этим концепциям следовать?

Классы/объекты/методы - это уже уровень реализации Объектно-Ориентированного Проектирования, причём не единственный.

ради чего собственно сыр бор с ООП затевался

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

 

[флоппик]

HraKK:
Но у меня почему-то волосы встают дыбом если вижу большую систему не на ООП.

Gnome ?

fixxxer:
нет, ну можно конечно, первым параметром передавать всегда $this, а все вызовы делать косвенно - то есть получится call_user_func($this['method'], $this....). только смысл?

смысл был ровно в том, что бы показать, что технически это вполне реализуемо. И что происходит смешивание понятий: проектирования и программирования. Потому что zerkms несомненно очень хороший специалист, но практик. А спор идет в плоскости _теории_. На самом деле, zerkms просто в силу свой практичности приписывает преимущества ООПроектирования — ООПрограмированию.

ООП — это всего лишь еще один уровень абстракции с пректировании приложения, позволяющий «подняться еще выше» и рассуждать на уровне взаимодействий законченых, целостных сущностей (объектов) и связей между ними, что упрощает проектирование больших систем.

-~{}~ 04.08.08 16:53:

Все тот же камрад-напарник подсказывает другой пример процедурной большой системы - winAPI

 

[fixxxer]

Автор оригинала: zerkms
fixxxer
и что получится? а где наследование? а где полиморфизм? (ладно - инкапсуляцию ещё можно "представить" в виде функций)
;-)

наследование - ну типа как в js - динамически добавляем.
полиморфизм - запросто

function user_authenticate($object) {.. }
function admin_authenticate($object) { .. }

$user['func_authenticate'] = 'user_authenticate']
$admin['func_authenticate'] = 'admin_authenticate';

...

call_user_func($user['func_authenticate'], $user);



смешно, да, но на чистом си примерно так и делают (только там есть указатель на функции, так что выглядит все приличнее). см., например, исходники nginx.

 

[Alexandre]

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

мэтры С++ как раз и не советуют увлекаться использованием множественного наследования.

 

[Angerslave]

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