2010년 11월 29일 월요일
2010년 11월 25일 목요일
2010년 11월 21일 일요일
A listener is called when the user does something to the user interface that causes an event. Altho these events usually come from the user interface, they can have other sources (eg, a Timer).
Button listener example
After a button is created, you will add a listener to it. Eg,
When the button is clicked, a call is made to the
actionPerformed() method defined in the class of the listener object. An ActionEvent object is passed as a parameter to it
The listener method must be called
There is (unfortunately) no way to use any given method as a listener -- the listener must be called
One per class. Because there can only be one
actionPerformed method in a class, a new class is needed for every separate listener, or you have to share an
actionPerformed method and use the ugly technique of figuring out who caused the call.
Incidental note. To address this awkward situation C# has delegates, which allow any method to be a listener, provided it has the correct return type and parameters. This doesn't provide any additional functionality, but it is more convenient.
You need to create an instance of the class which defines the
actionPerformed method for the button, and it is this instance that becomes the button listener.
Common Listener Strategies
Here are common ways to write listeners:
- Named Inner Class Listeners are one of the most common ways to write small programs. They are convenient to write and and be shared with several components.
- Anonymous Inner Class Listeners are sometimes used to associate a different listener with each button or other control. This is a little quicker to write, but lacks some of the flexibility of inner class listeners.
- Top-level Listeners (this) are commonly used where there is only one source of an event. For example, if you are defining a subclass of JPanel to use for drawing with a mouse, an instance of this new class will typically also be the mouse event listener. Similarly with a JPanel used for animation -- the panel itself may serve as the ActionListener for the Timer. Do not use "this" as a listener for buttons, menus, etc. because all controls must then share that one action listener.
- Action and AbstractAction objects are action listeners. In some ways they are more powerful than other action listener strategies in that they can easily be used to enable or disable multiple controls. An action object can be shared with many controls; eg, the same action is sometimes accomplished with a menu item and a button or toolbar tool. They encapsulate the name, description, enabled status, listener, and icon information. This is a good choice for large interfaces, and quite compatible with the MVC pattern (see below).
- External Listeners - To implement the Model-View-Controller pattern, all listeners will effectively be in the Controller module. There are a number of ways to split the controller actions from the View part of the interface. One example is in Model-View-Controller (MVC) Structure.
- Subclassing a component and overriding processActionEvent(). This peculiar scheme certainly isn't general, and I've never seen it done in a serious program. Do not do this.
The examples in these notes use named inner class listeners most often, anonymous inner class listeners in a few examples, and top-level listeners for mouse listeners for graphics panels.
2010년 11월 20일 토요일
2010년 11월 13일 토요일
2010년 11월 9일 화요일
equals 메소드 재정의은 간단해 보이지만 잘못 될 여지가 많다.
equals 메소드 재정의가 필요 없는 경우
equals 메소드 재정의가 필요한 경우
equals를 재정의할 때 따라야 하는 일반적인 계약(JavaSE6 Object 스펙)
규칙을 어기면 다른 객체가 어떻게 동작할지 예측하기 힘들다.
고품질 equals 메소드 레서피