Наследование и передача параметров

[KDVMan]

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

идет запрос страницы,
запускается скрипт index.php где прогружаются все нужные модули и прочее (у админки свой index.php, у самого сайта свой index.php),
далее загружается класс Index (у админки свой Index, у сайта свой Index), который наследуется от класса Base, который в свою очередь наследуется от SuperBase (имена для примера привел)
в классе SuperBase подгружаются нужные классы и переменные, которые используются на всем сайте,
а вот классы Base разные, у админки свой Base, у самого сайта (тот что видят люди) свой Base - соответственно в каждом Base подгружаются свои методы и переменные
в итогде в классе Index содержатся все необходимое для работы админки или сайта (в зависимости, где мы это дело вызываем)

так вот, на данный момент у меня все работает так как написано выше и вот так как напишу далее:
т.е. после того как в Index классе мы подгрузили все что нам надо, он (класс Index) загружает необходимый класс (в зависимости что мы запросили), ну например категории настроек в админке ссылка будет вида: index.php?module=settings&script=category (просто для примера)

т.е. будет вызван класс Category из пространства имен Settings (ну не суть), в свою очередь этот Category наследуется так же от Base (в данном случае Base относится к админке) и по сути проиходят двойные вызовы всего, что есть в Base и в SuperBase

так вот вопрос, я сейчас хочу переделать все это дело вот в таком варианте:
ссылка все так же ведет на index.php?module=settings&script=category (просто для примера)
подгружается как я написал выше Index класс, который в свою очередь наследуется и получает все необходимое и он вызывает класс Category из пространства имен Settings и передает в конструктор класса Category $this (пример: $class = new Category($this)) и в классе Category я уже в конструкторе делаю присвоение
function __construct($context)
{
$this->context = $context;
$this->db = $this->context->db;
и т.д
}

но получается тут происходит дублирование переменных
т.е. мне придется делать $this->что-то = $context->что-то для всех переменных, которые есть в Base и в SuperBase классах

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

т.е. задача, что бы все мои классы, которые вызывает Index имели доступ к методам, которые загружаются в Base и SuperBase (там помимо своих методов, в них инициализируются другие классы, например в которых просто полезные функции, так вот к ним так же доступ нужен)

заранее благодарю
если что непонятно написал, задавайте вопросы, постараюсь расписать более подробно

[Duncon]

Советую тебе пересмотреть подход к программированию в php, любая упаковка в структуры = замедление сценария, практически не использую классы, автоподгрузку не помню почему, но тож не использую, видимо так же с производительностью связано, куда проще указать в скрипте через include requere нужные файлы к открытию и не иметь проблем с тем что скрипт конкретно откроет и от куда.. Попробуй $this для передачи не использовать, слово всё же зарезервированное..

[KDVMan]

Советую тебе пересмотреть подход к программированию в php, любая упаковка в структуры = замедление сценария, практически не использую классы, автоподгрузку не помню почему, но тож не использую, видимо так же с производительностью связано, куда проще указать в скрипте через include requere нужные файлы к открытию и не иметь проблем с тем что скрипт конкретно откроет и от куда.. Попробуй $this для передачи не использовать, слово всё же зарезервированное..

Звучит как, не используй ООП :-)
все равно, спасибо за ответ, тем немения хотелось бы получить еще варианты от других участников

[Duncon]

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

[KDVMan]

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

Не соглашусь, ООП очень удобная вещь, у меня проекты все на ООП и работают годами (в том числе и высоконагруженные), яж не первый день программирую... (хотя в свое время и работал на чисто функциональном программировании без ООП, но это АД и УЖАС...)
компилировать ПХП это помоему вообще из другой стихии и не мое :-)

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

[Duncon]

Давай по ушам только не езди, годами на ООП и не можешь догнать что this перехватывается.. Если ты не смог без ООП, это не значит что это ад и ужас. Не осуждаю, просто не вижу в этом особого смысла в случае с php..
Высоконагруженные это сколько? У меня например на апаче(имею ввиду без спец. настроенного сервера) работает несколько магазинов в пики несколько тысяч одновременно сидят, сервер в среднем до 2 ядер загрузки даже не добирается и 3-х гигов оперативы.. А быдлокод классовый на соседнем таком же сервере ложится при наличие нескольких десятков запросов всего к 1 сайту..

[KDVMan]

Давай по ушам только не езди, годами на ООП и не можешь догнать что this перехватывается.. Если ты не смог без ООП, это не значит что это ад и ужас. Не осуждаю, просто не вижу в этом особого смысла в случае с php..
Высоконагруженные это сколько? У меня например на апаче(имею ввиду без спец. настроенного сервера) работает несколько магазинов в пики несколько тысяч одновременно сидят, сервер в среднем до 2 ядер загрузки даже не добирается и 3-х гигов оперативы.. А быдлокод классовый на соседнем таком же сервере ложится при наличие нескольких десятков запросов всего к 1 сайту..

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

нагрузка это 50 запросов в секунду как минимум...

[Duncon]

Я не закоренелый, внимательней читай, я провёл эксперименты с производительностью в каждом случае и могу уверенно обосновать почему с классами лучше не частить в php.. У тебя же по ходу пьесы здравомыслие отсутствует в данном вопросе, когда/если дойдёшь до реальных нагрузок изменишь свою точку зрения..

[KDVMan]

Я не закоренелый, внимательней читай, я провёл эксперименты с производительностью в каждом случае и могу уверенно обосновать почему с классами лучше не частить в php.. У тебя же по ходу пьесы здравомыслие отсутствует в данном вопросе, когда/если дойдёшь до реальных нагрузок изменишь свою точку зрения..

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

по поводу производительности, ну сейчас не начало 2000-х когда разница между ' и " была существенна в строках и влияала на производительность и тем более как ты говоришь разница между ООП и функциями, она сейчас (эта разница) на столько не существенна (несколько тысячных доли секунд, особенно в PHP7) что это явно будет не самое узкое место (проблемы как правило с запросами к БД и прочим, вот тут узкие места, но никак не в разнице ООП и функции). Нагрузки у меня были и до несколько сот запросов в секунду и ничего нормал (узким местом в этом случае всегда были запросы к БД и тут всегда помогал кеш).

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

ругаться не хочу, я не для этого сюда пришел за помощью, поэтому данную дискуссия считаю бессмысленной по крайней мере для себя. спасибо.

P.S. по поводу "я провёл эксперименты с производительностью в каждом случае и могу уверенно обосновать" в таких случаях обычно показывают какие-то реальные бечмарки (не из 90-х годов, а на современных версиях PHP), тогда можно будет сказать, да реально все это быстрее чем ООП я согласен с тобой. (это конечно если не принимать в расчет то, что я с самого первого своего поста вопрос ставил об ООП, и помощи просил именно по ООП, но никак не переходить на функциональное программирование).

P.P.S а то это получается, что я например работаю на связках nginx + php-fpm и буду яростно доказывать, что это лучше чем apache и непонимать, почему до сих пор твои проекты на apache работают (это дело каждого и личное и поэтому я на этом не делают акцента) - это про разговор, почему я работаю на ООП, а не на функциях...

[Duncon]

Не агрессивный, просто у тебя вопрос из разряда азов ООП сформулированный на пол страницы (кто ясно мыслит - чётко излагает) и следом идёт впадание в отрицание того, что ООП путь к тормозам и зачастую запутыванию кода.

' и " - она и сейчас существенна в зависимости от строки.. Не испытываю проблем с запросами, место не узкое если нормально архитектуру БД выстраивать.. Мои последние наблюдения показывают, что сейчас порядка 100 000 селектов за секунд 10 проходят практически незаметно для работоспособности сайта/сервера, одно ядро только под 40-60% нагружает..

Последние бэнчи для себя делал пол года назад, ты заблуждаешься на этот счёт, могу сказать что картина практически не меняется..

nginx + php-fpm - когда у тебя на сервере десятки сайтов, то появляется проблема с .htaccess и аутистами программистами не способными конфиг переделать, к томуж ещё есть такие же разработчики пишущие киллометровые конфиги и раскидывающими их в каждую папку с движком.. Так что гораздо проще на апаче всё держать..