Всем, привет

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

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

Но возникли 2 проблемы

1)
допустим класс 1 собирается получить от класса 2 информацию, обращаясь через посредник, а класс 2 для решения указанной задачи обращается к классу 3 через посредник, который обращается к классу 1 опять через посредник =/ ...

короче говоря посредник запускается каждый раз, когда происходит поиск информации в соседних классах.

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


2) вторая проблема возникает если 1 класс предоставляет информацию
а 2 класс ее обрабатывает и это должно происходить в цикле

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

вообщем вопрос как реализовать взаимодействие?

Эля

class modul1{
   // функции select обращения к бд

  // функции insert, delete, update

}

class modul2{
   // функции select обращения к бд

  // функции insert, delete, update

}


class posrednik{

     var $modul1 =false;

     var $modul2 =false; 

   // функции обращения к классам


    function getModul1(){
        if($this->modul1 == false){
            $this->modul1 = new modul1;
         }
    }


    function getModul2(){
        if($this->modul2 == false){
            $this->modul2 = new modul2;
         }
    }

}

т.е. posrednik класс оболочка

Я, конечно дико извиняюсь, но а зачем вам этот посредник? Пока по коду не вижу в этом необходимости. Какие задачи выполняет проект?

Michael, ты говоришь о интерфейсах каких? Интерфейсе обращения к классу или о интерфейсе как о родительском классе для классов модулей?


Я, конечно дико извиняюсь, но а зачем вам этот посредник? Пока по коду не вижу в этом необходимости. Какие задачи выполняет проект?

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

Michael, по описанию похоже на паттерн "абстрактная фабрика" дай пожалуйста ссылку на статью

пока что нашел https://habr.com/post/276593/

описание дается, где к интерфейсам идет обращение все также через единую точку но задействован паттерн "фасад"


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


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

Michael
я понял что за DI вот на этом и застрял в итоге получается, что DI превращается в Service Locator

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

если вызов модуля 2 происходит из DI(управляющий класс) и DI предоставляет информацию модулю 2
кто должен выполнять ее валидацию?

предположим, что должен модуль2, и если информация некорректная возвращает false управляющему модулю, а тот в свою очередь должен повторно запросить у модуля 1 правильные даныные, и вот здесь уже получается цикл и цикл этот должен быть размещен в DI - другими словами в DI формируется управляющая конструкция. Взаимодействие, контроль выполняния а следовательно и бизнес логика делегируются DI. И по логике DI должен

1) иметь информацию о всех классах и их взаимодействиях

2) функционал для валидации данных т.к. это позволит сократить время обработки информации

3) управлять данными и корректировать работу модулей

другими словами DI превращается в управляющую структуру ядро (((

А модули становятся не самостоятельными единицами делегировав функционал валидации и управления ядру.

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

допустим у нас есть система которая раз в 3 минуты обновляет данные полученные из вне. Соответственно система представлена модулями "сбора информации" с источника и модулем "корректной обработки и сохранения информации" в бд 2 задачи - два модуля 1 ядро, и вот возникает новая задача при старте работы этих модулей сохранять метку времени в отделенную таблицу. По логике необходим отдельный модуль, но из-за 1 запроса писать отдельный модуль кажется просто бредом как быть?

DI просто позволяет разрулить зависимости.
Валидациями надо отдельно заниматься, начинать с того что делать это в том классе чьи данные валидируются.

знаю фреймы в html в php не знаю что это.


НУ давайте еще помучаю вопросами, singleton можно использовать, как общий репозиторий данных, корректно ли его использовать в классах логирования?

Michael
мм ясно, спасибо