Здравствуйте, Airat Burganov, Вы писали:

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

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

вместо

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

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

    public ComponentListener.Hub onComponentEvent=....

onComponentEvent — сущность, функцией которой является регистрация получателей собылтий.
благодоря ей происходит очистка API объекта от утилитарных методов
AB>Но почему-то обычно когда я вижу в коде множество вызовов, например таких
AB>

AB>myFrame.myTable.getModel().getRow().getЧтонибудьеще()
AB>

AB>то вскоре оказывается, что микроархитектура этого кода очень кривая.

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