Tijden veranderen
[Java] OOP Gedachte
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
package h02a5;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class BalPaneel extends JPanel implements ActionListener {
private JTextField grootte; // invoerbox veldgrootte
private JButton teken; // Teken button
private Color balKleur; // kleur
// afmetingen
private int buitenLijn = 50;
private int binnenLijn = buitenLijn / 2;
public BalPaneel() {
teken = new JButton("teken bal");
teken.addActionListener(this);
grootte = new JTextField(3);
grootte.addActionListener(this);
add(grootte);
add(teken);
}
public void actionPerformed(ActionEvent e) {
}
}
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class BalPaneel extends JPanel implements ActionListener {
private JTextField grootte; // invoerbox veldgrootte
private JButton teken; // Teken button
private Color balKleur; // kleur
// afmetingen
private int buitenLijn = 50;
private int binnenLijn = buitenLijn / 2;
public BalPaneel() {
teken = new JButton("teken bal");
teken.addActionListener(this);
grootte = new JTextField(3);
grootte.addActionListener(this);
add(grootte);
add(teken);
}
public void actionPerformed(ActionEvent e) {
}
}
is dit goed OOP in dit geval? en dan bedoel ik meer het aanmaken van de panel objecten en de acties bepalen? of moet ook dit gescheiden?
Gewijzigd op 17/09/2012 19:10:00 door Reshad F
Quote:
A couple points:
Extending a JFrame is probably a wrong approach
Implementing an ActionListener on an JFrame probably will lead to non-OOP code.
Wrong Approach?
If the idea is that an GUI application is being made, then, one is not making an extension of a JFrame, but actually writing an application.
Therefore, the JFrame would be part of an application, not the application itself. Hence, the JFrame should be an object in the class.
Implementing an ActionListener on an JFrame probably will lead to non-OOP code
Consider the following case -- as the GUI application is starting to get large, and we're starting to add lots of buttons and menus which give rise to ActionEvents.
If the JFrame itself were to get the events, then what would the actionPerformed method look like?
Probably something like this:
public void actionPerformed(ActionEvent e) {
Object source = e.getSource();
// Find out which component fired the event
if (source == masterButton) {
// ... do something
} else if (source == anotherButton) {
// ... do something else
} else if (...)
// ... and so on ...
} else if (...)
// ... and so on ...
}
}
Yikes.
We're going to start getting code that's tightly coupled to all the components in the application, and maintainability will be out the window in no time.
If, for example, the GUI application had instances of ActionListers which responded to each component, then we'd be able to break up the actions and the coupling of the actionPerformed method with all the components in the GUI.
For example:
JButton masterButton = new JButton();
masterButton.addActionListener(new MasterButtonActionListener());
JButton anotherButton = new JButton();
anotherButton.addActionListener(new AnotherButtonActionListener());
This way, there will be ActionListeners for each button which presumably have different functionality. The responsibility of the MasterButtonActionListener would be to handle events from the masterButton -- it doesn't have to know about other buttons in the application.
Also, this would promote reusability of the components in other applications or other part of the application without having to copy-and=paste parts of the monolithic if-else statement in the actionPerformed method.
Extending a JFrame is probably a wrong approach
Implementing an ActionListener on an JFrame probably will lead to non-OOP code.
Wrong Approach?
If the idea is that an GUI application is being made, then, one is not making an extension of a JFrame, but actually writing an application.
Therefore, the JFrame would be part of an application, not the application itself. Hence, the JFrame should be an object in the class.
Implementing an ActionListener on an JFrame probably will lead to non-OOP code
Consider the following case -- as the GUI application is starting to get large, and we're starting to add lots of buttons and menus which give rise to ActionEvents.
If the JFrame itself were to get the events, then what would the actionPerformed method look like?
Probably something like this:
public void actionPerformed(ActionEvent e) {
Object source = e.getSource();
// Find out which component fired the event
if (source == masterButton) {
// ... do something
} else if (source == anotherButton) {
// ... do something else
} else if (...)
// ... and so on ...
} else if (...)
// ... and so on ...
}
}
Yikes.
We're going to start getting code that's tightly coupled to all the components in the application, and maintainability will be out the window in no time.
If, for example, the GUI application had instances of ActionListers which responded to each component, then we'd be able to break up the actions and the coupling of the actionPerformed method with all the components in the GUI.
For example:
JButton masterButton = new JButton();
masterButton.addActionListener(new MasterButtonActionListener());
JButton anotherButton = new JButton();
anotherButton.addActionListener(new AnotherButtonActionListener());
This way, there will be ActionListeners for each button which presumably have different functionality. The responsibility of the MasterButtonActionListener would be to handle events from the masterButton -- it doesn't have to know about other buttons in the application.
Also, this would promote reusability of the components in other applications or other part of the application without having to copy-and=paste parts of the monolithic if-else statement in the actionPerformed method.