Сверхбыстрая и компактная CMS Блоголёт - убийца WordPress

HraKK, как красиво вы расписали свое знание ооп... я уже сомневаюсь в вашем профессионализме, звучат заезженные нотки.

если бы я не знал ооп я бы молчал в тряпочку (теперь вы посоветуете мне так и сделать).

в вашем коде, даже с ооп 5-6 строк лишние

Chikey.ru, вы не аргументируете свои посты, что я напишу кроме общих фраз? Я например не понимаю что такое принципиальность ООП.

Аргументируйте, напишите мне код который там должен быть и напишите почему.

Крайне спорное заявление, 90% программистов ПХП считают что знают ООП. Но в действительности, хорошо если 10-20%.

HraKK, 1-2%

+1

10 символов

Аргументы? Почему нельзя писать распределенные системы на ФП? Особенно если брать предназначенные для подобного языки, например erlang.

Под принципиальность я понимаю постоянную проверку на инстансоф, максимальная приватность класса (да, это бывает неопраданно) ну и вообще полную об-ориентированность, которой не место в вебе!

protected $responseArray = array();

public function __construct( array $responseArray )

{

$this->responseArray = $responseArray;

}

Какой смысл проверять на array, это пустое?

if( class_exists( $responseClass ) )

ага, а если не нашли, промолчим?)

if( !$responseObject instanceof Core_Response_Interface )

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

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

zzeus, можно, но поддержка такого проекта - смерть. Понимаешь спроекты имеют свойство развиватся и изменятся. Архитектура построенная на ФП, имеет множество недостатков.

Почитай недостатки неудачной архитектуры на ООП и как это можно устранить. Эти же недостатки а то и в большей степени имеет архитектура на ФП, только там их нельзя устранить.

Chikey.ru,

Вот опять же это в тебе говорит то что ты не работал с нормальными системами, и работаешь в одиночку. Тут аррай служит для того чтоб когда ты решишь заюзать этот обьект нормальная IDE подсветит что этот обьект ожидает массив, а не что-то другое. А во вторых если кто-то эо просмотрит, то PHP сам ему об этом скажет. А не ты будешь искать в чем проблема.

Что такое максимальная приватность класса? Вообще private можно использовать только в final классах, в других надо protected. А во вторых, как бы тебе объяснить, это не моя прихоть, это архитектура на ооп. Когда ты отходишь от сборника функций собранных под эгидой класса, как это например используется тут или в джумле. Да практически везде. И когда уходим от излишней параметризации, так оно и выходит.

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

Это вообще лежит за плоскостью ООП. Это более базисный элемент.

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

В твоем случае передав например массив из 10 объектов и 1 не тот, класс сгенерирует fatal error необоснованно. Который, ты потом перехватишь. Но это из жопы. Прочитай на досуге что такое интерфейсы, для чего они служат. Если не делать проверки на интерфейсы - зачем тогда они вообще нужны.

Так что я бы советовал бы тебе сменить свое мнение о понимании тобой ООП. Но это так для тебя совет которым ты не воспользуешься :)

Зачем? На этом форуме 99.9% не знают ООП. Кому показывать? Что показывать?

Меня терзают смутные сомнения, что вы не умеете ФП. Или знакомы поверхностно. Грамотно написанный ФП код очень просто поддерживается, он изначально удовлетворят принципу Loose coupling, а если пишется с DRY - то там совсем все хорошо.

друзья, с чего такое бравирование соответствию E_STRICT ?

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

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

zzeus, сказать честно я бы хотел поработать с ФП не только в теории, но незнаю где это применить.

DeveloperRu, перегружать методы? мне всегда казалось что можно переопределять методы, а перегружать только операторы. нетак?