Меню
Что нового?

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

1. А помоему просто красиво проверить так
PHP: 
 if($myObj instanceof Cacheable) ...
2. Если пишешь что-то за неделю - всё ок, но если работаешь со своим старым кодом или с чужим, приятно увидеть
PHP: 
class MyClass implements Cacheable, Counteable, ArrayAccess
в принципе зная что за интерфейсы - понятно какой функионал реализует класс. Для ознакомления с интерфейсами я бы рекомендовал позаморачиваться с SPL
 
fixxxer
множественное наследование абстрактных классов - это как раз костыль, используемый при отсутствии интерфейсов
Очень спорное утверждение...
 
множественное наследование предпологает также наследование реализации, например mix-in в С++, и не всегда также какой-то интерфейс наследуется.

-~{}~ 03.08.08 16:05:

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

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

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

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

Может найдется добрый человек, который покажет на примере кода, преимущество ООП на процедурным стилем?
Нажмите для раскрытия...
как такового преимущества не бывает - есть "удобнее абстрактному 'тебе' в данном конкретном случае".
 
Страшный Злодей
Элементарно - процедурном коде на больших системах далеко не уедешь.
Все становится монолитным и фиг что потом изменишь добавишь нормально.
 
Элементарно - процедурном коде на больших системах далеко не уедешь.
Все становится монолитным и фиг что потом изменишь добавишь нормально.
Нажмите для раскрытия...
Ничто не мешает разделять процедуры по файлам, ввести систему именований, и получить эквалиент обьекто-ориентированного программирования.

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

-~{}~ 04.08.08 15:01:

Камрад напарник прокомментировал:
[13:55] фоффко:
только это все метание жемчуга перед свиньями
[13:56] фоффко:
нельзя объяснить человеку схуяли это ООП лучше процедурного подхода
[13:56] фоффко:
он на любой твой пример приведет код, где «то же самое» сделано в процедурах и «проще»
Нажмите для раскрытия...
 
флоппик
Скорее соглашусь чем нет. Но у меня почему-то волосы встают дыбом если вижу большую систему не на ООП.
 
HraKK, это как раз тот случай, когда ОПП заставляет думать обьектно, а процедурный стиль - позволяет. Поэтому то, имхо, выбор очевиден.
 
флоппик
какими "объектами" позволяет мыслить процедурный подход?
 
zerkms, подход не связан с проектированием напрямую. Что тебе _технически_ мешает ввести условные абстракции, уровня обьекта, и отладить их, только на процедурах?
Вынести ряд функций и переменных в отдельный файл, дать им префиксы, как вид реализации области видимости? технически - ничего не мешает. Более того, в свое время так и реализовывалась «объектность» в языках, не имеющих ее поддержки.
Еще раз повторюсь, ООП - это в первую очередь уровень абстракции, метод _проектирования_ системы, а не код, классы, свойства, методы.
Я же надеюсь, вы не просто кодер, а еще и мыслить умеете?
 
флоппик
что тогда будет отождествлять объект предметной области в коде? массив?
ООП это парадигма, да, имеющая в основе три концепции. и как вы без непосредственно классов/объектов/методов собираетесь этим концепциям следовать? или вы так ловко всё, ради чего собственно сыр бор с ООП затевался, взяли и отодвинули на второй план?

а еще и мыслить умеете
Нажмите для раскрытия...
ути пути :-)
 
нет, ну можно конечно, первым параметром передавать всегда $this, а все вызовы делать косвенно - то есть получится call_user_func($this['method'], $this....). только смысл? :)
 
fixxxer
и что получится? а где наследование? а где полиморфизм? (ладно - инкапсуляцию ещё можно "представить" в виде функций)
;-)
 
zerkms, флоппик уже не раз упомянул о разнице между Объктно-Ориентированным Программированием и Объектно-Ориентированным Проектированием, а ты продолжаешь её игнорировать в своих рассуждениях.

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

ради чего собственно сыр бор с ООП затевался
Нажмите для раскрытия...
"Сыр бор" с ООП как раз и затевается каждый раз из-за непонимания разницы между Объектно-Ориентированным Программированием и Объектно-Ориентированным Проектированием. Поэтому флоппик правильно перевёл "сыр бор" в другую плоскость. Чтобы понять и объяснить Объектно-Ориентированное Программирование, нужно начинать с Объектно-Ориентированного Проектирования. И никакой пример кода не позволит объяснить преимущества ОО Программирования перед процедурным подходом.
 
HraKK:
Но у меня почему-то волосы встают дыбом если вижу большую систему не на ООП.
Нажмите для раскрытия...
Gnome ?
fixxxer:
нет, ну можно конечно, первым параметром передавать всегда $this, а все вызовы делать косвенно - то есть получится call_user_func($this['method'], $this....). только смысл?
Нажмите для раскрытия...
смысл был ровно в том, что бы показать, что технически это вполне реализуемо. И что происходит смешивание понятий: проектирования и программирования. Потому что zerkms несомненно очень хороший специалист, но практик. А спор идет в плоскости _теории_. На самом деле, zerkms просто в силу свой практичности приписывает преимущества ООПроектирования — ООПрограмированию. ;)

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

-~{}~ 04.08.08 16:53:

Все тот же камрад-напарник подсказывает другой пример процедурной большой системы - winAPI
 
Автор оригинала: 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);

:D

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