Подтвердить что ты не робот

Методы и методы расширения Decorator в С#

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

Прилагайте дополнительные обязанности к объекту динамически. Декораторы обеспечивают гибкую альтернативу подклассу для расширения функциональности

Метод расширения

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

У меня есть следующий фрагмент кода в С#

public interface IMyInterface
{
    void Print();
}

public static class Extension
{
    public static void PrintInt(this IMyInterface myInterface, int i)
    {
        Console.WriteLine
            ("Extension.PrintInt(this IMyInterface myInterface, int i)");
    }

    public static void PrintString(this IMyInterface myInterface, string s)
    {
        Console.WriteLine
            ("Extension.PrintString(this IMyInterface myInterface, string s)");
    }
}

public class Imp : IMyInterface
{
    #region IMyInterface Members

    public void Print()
    {
        Console.WriteLine("Imp");
    }

    #endregion
}

class Program
{
    static void Main(string[] args)
    {
        Imp obj = new Imp();
        obj.Print();
        obj.PrintInt(10);
    }
}

В приведенном выше коде я расширяю интерфейс без изменения существующего кода, и эти два метода доступны для производного класса. Поэтому мой вопрос заключается в следующем: Является ли метод расширения заменой шаблона декоратора?

4b9b3361

Ответ 1

Метод расширения - это действительно просто синтаксический сахар для вызова статического метода.

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

Рисунок декоратора фактически определяется как использование обертки для изменения поведения, которое метод расширения явно не делает.

Ответ 2

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

Ответ 3

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

Это отличается от традиционной реализации шаблоном декоратора. Шаблон декоратора позволяет динамически обеспечивать множественное поведение объекта во время выполнения без необходимости создания нового подкласса для каждой комбинации этих поведений.

Ответ 4

Метод расширения - шаблон декоратора или шаблон посетителя? После прочтения я бы сказал, что он более схож с посетителем.

Цитируя величие, которое является википедией, pedia, которая никогда не имеет ошибок: P

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

Ответ 5

Это объяснение Эриха Гамма (GoF) кажется лучшим... http://www.mif.vu.lt/~plukas/resources/Extension%20Objects/ExtensionObjectsPattern%20Gamma96.pdf

По существу, заявив, что

a) Объединяя все операции и состояние, которое разные клиенты (настоящие и будущие) нуждаются в одном интерфейсе, приводит к раздутому интерфейсу

b) Желаемые операции (известные и неизвестные) можно разделить на компоненты. Из которого можно определить один (или более) компонентный интерфейс) (расширенные интерфейсы). Они могут или не могут быть реализованы объектами (текущими и будущими). ​​

c) Клиенты, которые хотят использовать этот расширенный интерфейс, могут запросить, поддерживает ли компонент его

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

Используется, когда:

1 Если вашим существующим классам может нужны дополнительные и непредвиденные интерфейсы (т.е. новые, в настоящее время неизвестные шаблоны поведения).

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

3 Вы хотите расширить без подкласса

Он похож на следующие шаблоны

Посетитель, который нуждается в стабильной иерархии классов и вводит цикл зависимостей

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

Адаптер, который поддерживает СУЩЕСТВУЮЩИЕ интерфейсы