1. Структура метаданных усложнена;
2. Нету циклического заполнения зависимостей;
3. Хоть у меня в контейнере и невозможно создать разные экземпляры, но за пределами с помощью клонирование, второй экземпляр класс получить можно.

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

Разве? Один в один как у тебя делал:

$container = new Cheevauva\Container(array(
    'App\Field\StringField' => array(
        'someDependency' => 'App\SomeClass',
    ),
    'App\FieldFactory' => array(
        'container' => 'Cheevauva\Container',
    ),
));

Синтаксис не тот, а структура та же, помоему. У меня алиасы просто, но можно и без них сделать. Это не суть.

Как нету? А это что:

        foreach($dependency as $property => $value)
        {  
            $class::$$property = $value;
        }

Или что ты ввиду имеешь?

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

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

Мне про конструкторы больше интересно. Чего ты на них так обиделся?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Уже не актуально, сейчас get у меня отдает не shared объекты. Он готовит эти объекты как shared, но потом просто из хранилища их удаляет. Спасибо bestxp за хороший довод о клонирование объектов.

Также обновил у себя в системе контейнер. Кстати, я думал, что память просядет, а фиг там, потребление наоборот упало (незначительно). Хотя может всё потому, что я веду разработку под версией php7

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

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

Вот это я имею ввиду, то что если у зависимости есть свои зависимости, то зависимость настроит свои зависимости (короче рекурсивное построение зависимостей).

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

"почти"

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

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

Ну вот, уже интереснее.

Ну поделись опытом. Может наоборот, я передумаю. Не могу представить себе, чем они могут навредить. Как не пыжился.

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

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



А шаблоны... Я писал уже про них целую статью. Одними шаблонами сыт не будешь. И вот такое ещё может получиться:

(с) Фаулер.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Кто нравится? Фаулер? Чё? ООП? Высоцкий?

_____________
Свои мозги еще никто не отменял.
Телепатов нету.

контейнер

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

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

3. Шаблон "фабрика", на сколько я понял, у тебя задействован для создания практически всех объектов системы. Раз они все в контейнере. А это уже выросли уши антипаттерна Gas Factory.

4. Использование метаданных для настройки зависимостей на грани фола с антиаттерном "мягкое кодирование". Я не берусь судить, но даже в этом топике я не одинок по этому поводу. Так что тоже показательно.

5. Ну и само то, что ты этот ущербный контейнер вытащил в паблик, да еще и с такой пафосной анотцией, это = антипатерн "золотой молоток"

Кроме того, на мой субъективный взгляд еще два: "ненужная сложность" и "дефакторинг" Это касается твоего последнего решения со звездочкой. Вместо нормального метода share(), который говорит сам за себя, ты вводишь новый синтаксис. Правда ты этот антипаттерн использовал наполовину. Доки то нет.
Плюс паровозом "фактор невероятности". Это что касается бесконечного цикла.

И это только касаемо контейнера. Да там наверное просто кладезь знаний!

Не, ты не подумай, я не предъявляю. Я вообще очень предвзято отношусь к паттернам. Это известно. Но за учебное пособие реально спасибо. В теории не так просто понять антипаттерны. Сами паттерны куда проще.

Антипаттерны здесь.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Это единственный правильно замечаный антипаттерн. Но его уже нет, отрефаторил 4 дня назад.
Текущая ветка разработки - form, ты смотрел для examplecms.

Работу с фабриками (а точнее с получение компонентов из бандла) я недавно пересмотрел в сторону упрощения, перекинув всю ответственность в сам бандл, объеденив в нём все эти фабрки

И может, уже оффтоп с обливанием говном мой системы, вынесем в отдельную тему?

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

Почему демагогией... Ничего не тоже самое. Нет там таких кривых контейнеров.

Так я только касаемо применения контейнера рассматривал. А где еще рассмотреть, как не в твоей системе. Ты вытащи еще чего-нибудь на обсуждение, тогда и будет отдельная тема. Целиком разбирать - много времени нужно на разбор твоей логики.

Да и не обливал я ничего говном. Как ты не поймешь, я на твоей стороне больше чем ты сам. Вот себя же процитирую:

Нравится так - делай. Кто посмеет запретить. Просто теперь я знаю, где показать иллюстрацию.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Хорошо. Давай первый разберем. Название красивое))) Он кстати до сих пор у тебя до сих пор присутствует по умолчанию.

По сути твой контейнер, это паттерн "пул объектов". В PHP его сложно применить, потому что тут принцип "отработал - умри". Однако ты умудрился не только применить, но и применить неправильно. Не важно, что объект инициализируется в момент обращения к нему. Важно, что все они собраны в хранилище объектов. Причем по принципу синглтона.

Вот для избежания этого антипаттерна Пимпл и использует callable и constructor dependency. А так же not shared по умолчанию. Там применить анитипаттерн можно только сознательно, а не по умолчанию.

Раз синглтон, значит ты сам нарушил закон пула

Вот иллюстрация клоаки в твоем коде. Это же очевидно.

    $container = new Container(array(
'ExampleA' => array(
'exampleB' => 'ExampleB'
)
));


    $objA = $container->get('ExampleA');
    var_dump($objA->getStatus()); // true
    
    // Здесь в процессе меняется состояние объекта
    $objA->exampleB->status = false;

// Другой край географии. Я понятия не имею, где что творилось с объектом.
// Хочу из контейнера (пула) чистый объект, без состояния. 
    $objA = $container->get('ExampleA');
    var_dump($objA->getStatus()); // И что? КЛОАКА!

И ты всех, кто привык работать по паттернам, считай подставил. Потому что твой контейнер один прет против общих правил. А он в паблике, так, на секундочку.

Кстати, еще один антипаттерн. Самый знаменитый: костыль. :D Ты решаешь проблему звездочкой, на месте, без редизайна.

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.