Ответы пользователя по тегу ООП
  • Как провести рефракторинг различающихся сигнатур методов в потомках (php7)?

    @maxtm
    Make money, not job
    Посему ломаю голову, как правильней проводить рефракторинг подобного кода.

    Просто проводить рефакторинг, чтобы таких нюансов не было. Приводите всех предков к единой сигнатуре.
    Ответ написан
    Комментировать
  • Подобие хуков в ООП для компонентов, как это сделать?

    @maxtm
    Make money, not job
    Делайте также, в чем проблема?

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

    вы думаете, что это благодаря процедурному стилю программирования?
    Ответ написан
  • Как лучше организовать классы с большим числом полей?

    @maxtm
    Make money, not job
    Если свойства известны заранее, то используйте "в лоб".
    Если свойства могут меняться (например, на основе справочника из БД) - то второй вариант.
    Ответ написан
    Комментировать
  • Чем является логика компонента?

    @maxtm
    Make money, not job
    Свойство text будет просто свойством текст. Это не бизнес-логика, это просто свойство (или объект).
    К MVC тут оно не имеет никакого отношения.
    Ответ написан
    Комментировать
  • Порекомендуйте источники по алгоритмам проектирования приложений?

    @maxtm
    Make money, not job
    К сожалению, материалов посоветовать не могу, но напишу небольшую заметку из своего опыта.

    Первое, ваше приложение/игра/сервис должен быть разбит на логические блоки.
    Метод дробления - бизнес-задачи, логически разные задачи, зоны ответственности.
    Эти блоки могут быть названы компонентами, модулями, и т.п.

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

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

    После, вы получаете некий список (на бумаге) модулей, сервисов, классов.
    Имея это Вы можете легко начать разработку фронтенда - будь-то контроллеры, обертка в виде REST-api и т.п.

    Как организовать морду - отдельный вопрос, и зависит от типа задачи.
    Ответ написан
    Комментировать