Блог

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

• Декоратор
• Атрибут
• Аспект
• Признак

В разных языках эти слова и функциональные возможности используются по-разному. Например, в Python декораторы [согласно Python Wiki] (выделено мной):

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

Мне кажется, что это удивительно похоже на инструмент аспектно-ориентированного программирования, такой как PostSharp или DynamicProxy. т.е.:

    [Profile]
   private static void SleepSync()
   {
       Thread.Sleep(200);
   }
  

Источник: Примеры PostSharp

В C # и Java (а также во множестве других языков) атрибуты могут означать либо шаблон декоратора (C #), либо поле (Java).

А в C через boost или PhP через встроенное слово trait мы можем использовать признаки для расширения классов, как показано здесь: https://en.wikipedia.org/wiki/Trait_ (computer_programming)

Итак, с «чистой» точки зрения, каковы канонические определения того, чем все это на самом деле является? Есть ли лучший способ их определения?

Декоратор

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

Самый простой пример, который я могу придумать, — это функция декоратора. Функция

 int foo(int x)
  

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

 int bar(int x, int y) {
    return y*y   foo(x);
}
  

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

Другим распространенным примером являются классы ввода-вывода в Java. Существует базовый

 OutputStream s
  

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

 OutputStream s1 = new FileOutputStream("somefile.txt");
  

или

 OutputStream s2 = new ByteOutputStream("rawdata.hex");
  

Атрибут

Я бы склонялся к идее C # о том, что атрибут является правильным пониманием, потому что он отличается от декоратора. Атрибут присваивает семантическое значение, которое может варьироваться от одного использования к другому и даже между API, использующими один и тот же атрибут. Например, у меня может быть две функции:

 [Logging] private void a() { ... }
[Security] private void b() { ... }
  

Я могу назначить одному атрибут ведения журнала, а другому атрибут безопасности, и то, что означают эти атрибуты, может отличаться от клиентских API, которые проверяют эти атрибуты. Для реализации ведения журнала можно использовать log4j, а можно использовать другой API. Определение здесь гораздо более гибкое и открытое для интерпретации различными сторонами или пользователями моего кода. Конечно, можно использовать атрибут в качестве декоратора, но атрибуты можно использовать и для гораздо большего.

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

На мой взгляд, одним из определителей того, что это атрибут в том смысле, о котором мы говорим, является то, что он напрямую не изменяет поведение, только косвенно. Например, присвоение чему-либо атрибута [Logging] никоим образом не изменяет его код. Это похоже на прикрепление тега имени, который ищут другие. Когда другая программа или приложение видит тег name, оно делает определенные выводы и может соответствующим образом изменить свое поведение. Но (по крайней мере, в Java) аннотации или атрибуты напрямую ничего не изменяют — опять же, просто тег имени. Это может немного отличаться в C # или других языках, поддерживающих атрибуты, и в этом случае я бы рассматривал их как более продвинутый атрибут или что-то совсем другое.

Аспект

Аспект в смысле аспектно-ориентированного программирования (AOP) — это своего рода самоизменяющаяся или самообновляющаяся конструкция кода. Это определяет раздел кода как более гибкий (точечное сокращение) и позволяет переключать этот конкретный раздел между одним или несколькими возможными обновлениями, исправлениями или разными версиями одного и того же раздела кода.

Не могли бы вы выполнить некоторые из тех же действий, что и декораторы и атрибуты, используя аспекты? Конечно. Но зачем вам создавать себе такую головную боль? AOP — это как следующий шаг от ООП, только его следует использовать при необходимости. Когда это необходимо? Когда у конкретного приложения много «сквозных проблем», таких как безопасность или ведение журнала — например, банковское приложение. Эти проблемы носят сквозной характер; они выходят за традиционные границы, которые создают хорошо определенные классы и пакеты. Когда вы ведете журнал, от этого мало пользы, если вы не регистрируете все; следовательно, эта проблема носит сквозной характер. Итак, когда вы переходите к обновлению механизма ведения журнала одного класса, было бы сложно одновременно модифицировать все другие классы и API, но это также было бы необходимо. В противном случае ваше ведение журнала теперь будет непоследовательным и запутанным, и его будет сложнее использовать для устранения неполадок или мониторинга.

Чтобы сделать такого рода обновления менее головной болью, были введены аспектно-ориентированные языки, такие как AspectJ. Я не сталкивался с «аспектом», который означал бы что-либо иное, но могут быть некоторые, как указано ранее о декораторах. Определенный язык может называть что-то аспектом, но это может больше походить на одну из других вещей, которые мы уже обсуждали.

Признак

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

Интерфейс — это концепция ООП, которая объявляет поведение без его реализации. Создание этих ожидаемых поведений позволяет этим поведениям стать универсальными и вызываться в общем виде, не заботясь о специфике. Их реализация остается за подклассами.

Классическим примером ООП является Animal с двумя подклассами, Cat и Dog.

 public interface/trait Animal {
    public void speak();
}
public class Cat implements Animal {
    public void speak() {
        output("Meow.");
    }
}
public class Dog implements Animal {
    public void speak() {
         output("Bark!");
    }
}
  

Это также отличный пример полиморфизма — одного из тех слов, которые, как правило, заставляют людей, не занимающихся компьютерами, съеживаться. Это просто означает, что у кошки и собаки индивидуальное поведение, и если я объявляю объект Animal, мне все равно, какой тип вы мне присвоите. Вы можете подарить мне кошку или собаку. Поскольку оба являются животными, в любом случае все, что мне нужно сделать, это вызвать функцию speak () моего объекта Animal, и я могу быть уверен, что в любом случае будет получен правильный результат. Каждый отдельный подкласс знает, что ему нужно делать. В C вода здесь немного более мутная, но общая концепция та же (прочитайте ключевое слово «virtual», если хотите начать с кроличьей норы).

Подведение итогов

Я надеюсь, что это прояснит некоторую путаницу. Похоже, что, как вы сказали, многие разные языки имеют много разных значений для каждого из них, что, без сомнения, вносит свой вклад в путаницу. Я полагаю, что если вы изучите это подробнее, вы обнаружите, что по большому счету, это стандартные значения. Я программирую на многих языках (VB, C , C #, Java, Paschal, PHP, Perl) более 18 лет, и мне удобнее всего считать эти определения своего рода стандартом.

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