Стандарты для использования внутренних классов для GUI?
Сделайте часть своего продукта компонентом онлайн, который требует соединения и аутентификации. Вот некоторые примеры:
- Онлайн-игры
- Антивирусная защита
- Защита от спама
- программное обеспечение отслеживания Ноутбука
Эта парадигма только идет до сих пор, хотя и может выключить некоторых потребителей.
4 ответа
Я думаю, что это несколько произвольно, как вы это делаете (как прокомментировал Том Хотин, стандарты графического интерфейса = грязь), поскольку вы ' re компромисс между сложностью количества классов и сложностью одного класса. Если вы хотите создать код просто для демонстрации, проще всего использовать один файл. Если вам нужен код, который вы собираетесь вводить в производство и изменять / поддерживать с течением времени, абстрагирование в разные классы почти наверняка будет тем способом, которым вы хотите пойти.
Например, если вы встраиваете MapPanel как внутренний класс в ControllerWindow, а затем позже вы захотите заменить его на другой тип MapPanel, у вас есть массивное обновление ControllerWindow, а не просто замена MapPanel на другой тип компонента.
С MouseListener я был бы склонен включить его в MapPanel, если он обрабатывает события специально для этого компонента (то есть, если только MapPanel «знает», что означает щелчок, он должен обрабатывать этот щелчок). Я бы определенно не стал помещать его в ControllerWindow, поскольку тогда вы «утекаете» детали реализации из MapPanel. (Единственный случай, который я могу придумать: в дополнение к вашей MapPanel, у вас есть несколько типов панелей, которые все должны одинаково реагировать на щелчки, поэтому вместо реализации на каждой панели вы можете сделать это с помощью ControllerWindow. Но даже тогда , Я
Внутренний класс был бы лучше, если бы у него был более простой синтаксис.
button1.click( function(event){ do something x... } );
button2.click( function(event){ do something y... } );
radio2.check ( function(event){ do something z... } );
java 7 может дать нам нечто подобное и изменить всю ситуацию. как и сейчас, использование множества анонимных внутренних классов может испортить код и сделать его невозможным для чтения. вам следует выбрать тот стиль, который сделает ваш код красивым и разборчивым.
Обычно анонимные внутренние классы используются в качестве прослушивателей событий, потому что код обычно довольно прост (поэтому отдельный класс может быть излишним) и код обработчика сохраняется «близко» к коду, который регистрирует слушатель может улучшить читаемость для людей, пытающихся понять ваш код, поскольку весь код, связанный с событием, находится в одном месте.
РЕДАКТИРОВАТЬ: Это особенно верно для классов, которые реализуют только один метод слушателя. Возможно, это менее верно для интерфейсов с несколькими методами, таких как MouseListener, поскольку класс, реализующий полный интерфейс, будет более подробным.
Because of multiple event handling requirement anonymous inner classes are required. Anonymous class can be written anywhere like in a class, in a method, in the argument. Therefore to abstain from creating many classes for each listener anonymous is preferred.