Есть ли обходной путь для интерфейсов композиции и маркеров?

Вот недавнее обсуждение списка рассылки Guava - мой ответ затрагивает этот довольно фундаментальный вопрос.

http://groups.google.com/group/guava-discuss/browse_thread/thread/2d422600e7f87367/1e6c6a7b41c87aac

Суть такова: Не используйте интерфейсы маркеров, если вы ожидаете, что ваши объекты будут заключены в оболочку . (Ну, это довольно общий вопрос - как сделать , что вы знаете, что ваш объект не будет упакован клиентом?)

Например, ArrayList . Очевидно, он реализует RandomAccess . Затем вы решаете создать оболочку для объектов List . Ой! Теперь, когда вы обертываете, вы должны проверить обернутый объект, и если это RandomAccess, созданная оболочка должна также реализовывать RandomAccess!

Это работает "отлично" ... если у вас только один интерфейс маркера! Но что, если обернутый объект может быть сериализуемым? Что, если он, скажем, «Неизменяемый» (при условии, что у вас есть тип для обозначения этого)? Или синхронно? (С таким же предположением).

Как я также отмечал в своем ответе на список рассылки, этот недостаток дизайна также проявляется в старом добром пакете java.io . Допустим, у вас есть метод, принимающий InputStream . Вы будете читать прямо с него? Что, если это дорогостоящий поток, и никто не позаботился обернуть его в BufferedInputStream за вас? О, это просто! Вы просто проверяете экземпляр потока BufferedInputStream , а если нет, вы обертываете его сами! Но нет. У потока может быть буферизация где-то ниже по цепочке, но вы можете получить ее обертку, , которая не является экземпляром BufferedInputStream . Таким образом, информация о том, что «этот поток буферизован», теряется (и вам, возможно, придется пессимистично тратить память, чтобы буферизовать ее снова).

Если вы хотите делать что-то правильно , просто моделируйте возможности как объекты. Рассмотрим:

interface YourType {
  Set<Capability> myCapabilities();
}

enum Capability {
  SERIALIAZABLE,
  SYNCHRONOUS,
  IMMUTABLE,
  BUFFERED //whatever - hey, this is just an example, 
           //don't throw everything in of course!
}

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

Таким образом, когда вы оборачиваете объект из них, вы получаете Набор возможностей, и вы можете легко решить , какие возможности сохранить, какие удалить, какие добавить .

У этого есть , очевидно, есть свои недостатки, поэтому его следует использовать только в тех случаях, когда вы действительно чувствуете боль от сокрытия возможностей оболочек, выраженных в виде интерфейсов маркеров. Например, предположим, что вы пишете фрагмент кода, который принимает список, но он должен иметь свойства RandomAccess И Serializable.При обычном подходе это легко выразить:

<T extends List<Integer> & RandomAccess & Serializable> void method(T list) { ... }

Но в подходе, который я описываю, все, что вы можете сделать, это:

void method(YourType object) {
  Preconditions.checkArgument(object.getCapabilities().contains(SERIALIZABLE));
  Preconditions.checkArgument(object.getCapabilities().contains(RANDOM_ACCESS));
  ...
}

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

Изменить: Другой недостаток заключается в том, что без явного типа для каждой возможности у нас нет естественного места для размещения методов, которые выражают то, что предлагает эта возможность. Это не слишком важно в данном обсуждении, поскольку мы говорим об интерфейсах marker , то есть о возможностях, которые не выражаются через дополнительные методы, но я упоминаю об этом для полноты.

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