Есть ли когда-нибудь выравнивание для “антишаблона псевдоопределения типа”?
Единственная вещь, которую я изменил бы о той реализации Singleton (кроме не использования Singleton вообще) состоит в том, чтобы сделать финал поля экземпляра. Статическое поле будет инициализировано однажды на загрузке класса. Так как классы загружаются лениво, Вы эффективно получаете ленивое инстанцирование бесплатно.
, Конечно, если это загружается из отдельных загрузчиков класса, Вы получаете несколько "одиночных элементов", но это - ограничение каждой одноэлементной идиомы в Java.
РЕДАКТИРОВАНИЕ : новые () и doPreparations () биты действительно смотрят подозреваемый все же. Разве они не могут быть перемещены в конструктора одноэлементного экземпляра?
6 ответов
Настоящая проблема в том, что эта идиома создает сильную связь между вашим псевдотипом и вашим клиентским кодом. Однако , поскольку вы используете FooBarMap в частном порядке, реальных проблем связывания нет (это детали реализации).
NB
Современная Java IDE должна обязательно помочь в работе со сложными универсальными типами.
ИМО, проблема с анти-шаблонами Java в том, что они поощряют черно-белое мышление.
На самом деле, большинство анти-шаблонов имеют нюансы. Например, в связанной статье объясняется, как псевдотипы приводят к API-интерфейсам, сигнатуры типов которых слишком строгие, слишком привязаны к конкретным решениям реализации, вирусным и т. Д. Но это все в контексте общедоступных API. Если вы держите определения псевдотипов вне общедоступных API (т.е. ограничиваете их классом или, возможно, модулем), они, вероятно, не причинят реального вреда и могут сделать ваш код более читабельным.
Моя точка зрения заключается в том, что вам необходимо понять антишаблоны и сделать собственное обоснованное суждение о том, когда и где их избегать. Просто занимая позицию, что "
Для общедоступных интерфейсов мне не нравятся общие типы, потому что они не имеют значения. Мне кажется, что метод с аргументом HashMap
Без этого псевдотипа я бы предпочел написать
private Map<Long,Map<Integer,String>>[] maps;
, и если я когда-нибудь решу изменить реализующий класс с HashMap на TreeMap или Java7GreatEnhancedWonderfulMap :-) ничего не сломается. Но с этим вы застряли с HashMap. Что ж, вы можете сделать:
interface FooBarMap extends Map<Long,Map<Integer,String>> { };
class FooBarHashMap extends HashMap<Long,Map<Integer,String>> implements FooBarMap{ };
, но он становится все более громоздким.
Если вы используете его только в небольшом локализованном блоке кода, проблемы будут небольшими, правда.
Дело в том, что и выгоды тоже: ваша программа, вероятно, даже не получит текстовый меньше, пока вы не укажете pseudo-typedef 5+ раз, что означает, что область, в которой он виден, должна быть нетривиальной.
Я, вероятно, не стал бы переписывать код, который делал это, но это кажется плохой привычкой. .
У него есть хорошая точка зрения на это, когда дело доходит до размещения его в общедоступном интерфейсе. Эта идиома имитирует некую форму синтаксического сахара, она не должна влиять на то, что вы показываете своим клиентам.
Но я не вижу веских причин не использовать ее локально, при условии, что она облегчает вам жизнь и код более читабелен - и вы известно, что ты делаешь. Брайан может обобщать и категорически не рекомендовать это в любой ситуации, но это его чувство Гетца: p