AB>>Я честно говоря у вашего решения плюсов не вижу. В плане реализации писать надо не меньше. Интуитивно не понятно. Какие у вас плюсы? Минусы — введение дополнительных сущностей Hub на какждый новый листенер, не прозрачная иерархия вызовов.

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

Т>вместо
Т>

Т>    public synchronized void addComponentListener(ComponentListener l)
Т>    public synchronized void removeComponentListener(ComponentListener l)
Т>    public synchronized ComponentListener[] getComponentListeners()
Т>

для демонстрации synchronized или надо было убирать, либо делать synchronized и свое api.

Т>будет в API объекта генерирующего события останется только
Т>

Т>    public ComponentListener.Hub onComponentEvent=....
Т>

Т>onComponentEvent — сущность, функцией которой является регистрация получателей собылтий.
Т>благодоря ей происходит очистка API объекта от утилитарных методов
Пожалуйста более подробнее. И ответьте в чем польза использования именно такого объекта. Где плюсы? Упомянутые мною минусы сохраняются и не объяснены. Ваша реализация непрозрачная. Как написать addComponentListener, removeComponentListener, getComponentListeners в 6-8 строк я знаю, а как писать ваш листенер?

  public interface ComponentListener extends EventListener
    {
        public void componentResized(ComponentEvent e);
        public void componentMoved(ComponentEvent e);
        public void componentShown(ComponentEvent e);
        public void componentHidden(ComponentEvent e);
        
        public class Hub
        {
            public void add(ComponentListener c){};
            public void del(ComponentListener c){};
            public ComponentListener get(){};
        }
        
    }

Насколько я понимаю меоды add,del,get реализуются в интерфейсе? а инкапсуляция? А если я закочу расширить этот компонент листенер, всюду делать свои hub'ы? Ни о чем этом вы похоже не думали.

Ссылки на то, что главное — это идея не принимаются. Идеи никакой тут нет, одна бессмыслица, набор необоснованных утверждений. Вы сами пробовали пользоваться тем, что написали? Хоть один реальный листенер покажите.

Т>причем тут архитектура? то о чем Вы говорите — это уже использование некоторой архитектуры.
Т>такую последовательность вызовов несможет предотвратить ни одна архитектура, ну, кроме разве той, согласно которой методу запрещено возвращать ссылку на объект. но это не идеология JAVA, вроди так
микроархитектура. Паттерны спасут.