Что подразумевается под динамическим временем выполнения в шаблоне Designrator?
Изучая более одной статьи о шаблоне Design Decorator, я заметил, что все статьи рассказывают о Decorator, позволяющем нам динамически создавать дополнительные функции во время выполнения и динамически создавать объекты во время выполнения.
Я полностью понимаю шаблон Decorator, но не понимаю, что подразумевается под «динамически», и если он не создан во время выполнения, как он создается?
Мне нужен пример для иллюстрации.
Проблема, которую решает Decorator, заключается в том, что вы можете динамически добавлять и удалять обязанности из объекта, но делать это таким образом, чтобы он оставался совместимым с остальным кодом приложения.
Наследование — это первое решение, которое приходит на ум, когда вам нужно
расширить классовое поведение. Однако наследование статично. Вы можете
не добавлять новые подклассы в программу, когда она уже скомпилирована и
казнены.ссылка
Третий вопрос : Мне нужна статья или описание, например, это способ объекта, созданный во время выполнения или нет, и это способ, которым он создан динамически, и это не
Вопрос 4 : Как я могу различить, что этот код сделан во время выполнения или нет и динамически или нет?
Ссылки:
Решение
Я надеюсь, что смогу ответить на ваши 4 вопроса, просто продемонстрировав различие между оформлением (динамическим) и наследованием (статическим).
Наследование (статическое) = менее гибкое. Допустим, у вас есть класс B что наследует класс A, Затем во время выполнения, каждый экземпляр класса B будет использовать код класса A, Нет способа изменить это, когда программа работает. Чтобы изменить его, вы должны сделать это во время компиляции.
Украшение (Динамическое) = более гибкий. Учебный класс B не относится к классу A как родитель, но вместо этого рассматривает A как друг. Это часто достигается с помощью техники под названием Внедрение зависимости: конструктор B получает объект, принадлежащий к типу A, Когда вы хотите создать экземпляр B, вы должны сначала создать экземпляр A или любого подкласса Aи передать его конструктору B, Эта конструкция более гибкая, но и более сложная.
Другие решения
Я должен отметить, что шаблон Decorator не Decorationи я отредактировал текст соответственно.
Некоторые из классических шаблонов находят лучшие способы, чем наследование, для изменения поведения классов. Примеры Strategy, Composite, Chain of Responsibility и конечно Decorator, Фактически 3 из вышеперечисленного работают, создавая связанные списки объектов, которые сотрудничают, чтобы сделать что-то «сложное», что было бы трудно, неэффективно, используя наследование. Используя шаблоны, вы можете создавать коллекции объектов для выполнения сложного поведения во время выполнения, объединяя / внедряя несколько объектов.
Смысл всего этого в том, что вы можете не знать во время компиляции, какое сложное поведение необходимо, и это может зависеть от входных данных, конфигураций и т. Д. Это требует гибкого способа создания экземпляров и объединения классов во время выполнения таким образом, чтобы это было практически невозможно во время компиляции.
Авторы цитат в вашем вопросе высказывали одно и то же. то есть, что наследование не является гибким способом построения сложного поведения, которое может быть неизвестно до времени выполнения.