[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: PDIC - Property Dependency Injection Container
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
twin
Ох ща много напишу. Накипело.

Начнем снизу вверх. Насчет Остапа. Я конечно не крутой спец в ООП. К тому же уверен, что правильного ООП вообще не существует. Однако это не значит, что не существует не правильного. Твое ООП совершенно неправильное. Потому что ты посредством оверинжениринга завуалировал практически статический подход к реализации. Вот почему:

1. Вся твоя концепция строится на синглтонах. И хотя они не явны, но сейчас выяснилось, что основа твоего фреймворка - этот самый контейнер. А он не разрешает делать копию объекта. Фактически это синглтон и есть. Ты пользуешься объектами только по одному. Чем это отличается от статики?

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

2. Ты заведомо и сознательно убил возможность пользоваться конструкторами. А чем в первую очередь отличается объект от статического класса? Магией. Я, как любитель статики, тебе авторитетно скажу. Именно её мне больше всего нехватает. Особенно конструкторов.
А убив конструкторы, ты угробил кучу возмжностей. Самую главную - constructor dependency.

Кроме того, ты глобально использовал антипаттерн. Инъекции обязательных зависимостей через свойства. Это делает систему хрупкой, я уже показал, что будет при клонировании. И статьи показывал, где это описано. Фаулер в своей книге вообще не рассматривает такую возможность, так как это антипаттерн и есть. Ты нарушил принцип инкапсуляции. Кроме того, SOLID (второй принцип - Open/closed principle). Твои объекты повально открыты для изменения.

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

3. Вся твоя CMS - это френкин-дизайн. Ты увлекся зависимостями и напихал их везде и всюду. От того она стала непролазной дебрей, собранной из тысячи сильно связанных кусочков. В логике которой без бутылки не разобраться. От того у тебя и 150 классов для генерации любого нello world. Это совершенно неоправданный оверинжениринг, ты явный архитектурный астронавт. Всё, что можно решить двумя строчками, у тебя выливается в несколько классов. Как в примерах с фабрикой, медиатором и клонированием. А это плохая практика. И ты этому учишь людей.

Ладно, хватит пока. И этого достаточно.

Дальше.
Цитата (chee @ 12.04.2016 - 13:38)
Возможно да, а возможно и нет. Все субъективно.
Нет. Это не субъективно. Вот смотри. Ron недавно заявил:
Цитата (Ron @ 11.04.2016 - 23:03)
Зачем мне смотреть в чужой код? Описания преимуществ и хорошей доки по использованию более чем достаточно. =)

Вот он поверит твоей декларации, и применит в проекте. А ему потом, когда уже поздно будет, понадобится копия объекта, как мне. И всё. Ты его подставил, получается. Кроме того, чтобы не юзать конструктор, нужно идти по твоему пути. А он порочен. Так что не сбивай людей с толку. Этот контейнер простой - спору нет. Но он не мощный. Он нЕмощный. smile.gif А таким поделкам в паблике делать нечего.

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

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

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

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

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

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.