Задать вопрос
Vapaamies

Freeman

Разработчик будущей ОС для ПК размером 250 МБ
Ответы пользователя по тегу ООП

  • Зачем нужен интерфейс, если есть абстрактный класс?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    Это казуистика.
    Ответ написан
    Комментировать
    Комментировать

  • Чем сервис отличается от объекта?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    Сервис — не про ООП.
    Ответ написан
    1 комментарий
    1 комментарий

  • Как избежать глаголов в наименовании классов?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    В комбинации CreateUserData — «данные о создании пользователя» — Create — не глагол, а причастие. Английский — язык аналитический, грамматические конструкции выражаются порядком слов. Переводите на русский для проверки, и будет вам счастье.
    Ответ написан
    Комментировать
    Комментировать

  • Надо делать наследование или нет?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    Наследование используется для инкапсуляции проверки isAdmin. Грубо говоря, все if-ы, выполняющие проверку, превращаются в записи VMT (или что там в PHP).

    Архитектура может зависеть от количества ролей. Одно дело -- проверять только на админа, и другое -- на кучу разных ролей. Код с кучей switch -- фактически эмуляция VMT, лучше разрешить эту задачу архитектурно, воспользовашись ООП.

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

  • Легкая задачка по ООП для архитектора. Как поступить?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    Если сверхурочный заказ отрабатывается так же, как основной, он относится к сущности "подзаказ". Тогда получается, что метазаказы агрегируют задачи, при этом метазаказ может быть заказом или подзаказом, который разделяет с родительским заказом ключевые свойства.

    А с учетом вашего комментария получается, что заказ агрегирует не только задачи, но и подзаказы. Тогда у него два агрегирующих атрибута: задачи и подзаказы.
    Ответ написан
    4 комментария
    4 комментария

  • Как формируется список отображения?

    Vapaamies
    @Vapaamies
    Разработчик будущей ОС для ПК размером 250 МБ
    Вот интересно... Я разрабатываю язык со встроенной поддержкой SOLID (в расширенном толковании), попробую ответить на ваш вопрос.

    Расширенное толкование звучит так: множественное наследование допустимо только от взаимно-абстрактных классов, -- то есть классов, не имеющих реализации одинаковых методов. Одинаковость методов в языке определяется совместимостью по присваиванию с учетом ООП.

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

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

    Данный ответ основывается на результатах оригинального исследования. :-)
    Ответ написан
    6 комментариев
    6 комментариев