Zasada pojedynczej odpowiedzialności

0

Witam
chciałbym spytać o zagadnienie w tytule. Otoz odkad sie dowiedzialem ze jest taka zasada, staram sie jej trzymac.
Pytanie tylko brzmi jak skrupulatnie do niej podchodzić? jeśli jest np klasa A rozszerzajaca JPanel - wyswietlam na nim obrazek - i teraz za pomocą myszki chciałbym wychwytywać punkty klikniecia na obrazie itd - musze zaimplemenotwać międzyinnymi MouseListenera.

I teraz pytanie, czy robic osobno klase, która bedzie od obsługi myszy i działała na jpanelu, czy Od razu do tego panelu A dac implements MouseListener, dodac jego metody tworzyc funkcjonalność?
Wtedy jakby klasa A wyswietla obrazek i zarazem używa myszki < ma 2 funkcjonalnosci - wiec 2 powody do modyfikacji.

Kiedys mi poradzono, ze klasy maja byc krótkie, nie robic bóg wie ile rzeczy na raz. Tak sie staram pisac własnie stąd moje wątpliwości ;)

0

Najważniejsze tutaj jest to co napisałeś - że klasy mają być krótkie. Jeśli panel ma dwa zdarzenia na krzyż to nie ma sensu dobudowywać klasy do każdego zdarzenia. Jeśli natomiast panel jest głównym panelem aplikacji i dzieje się na nim mnóstwo rzeczy, to takie klasy rozszerzające będą ułatwieniem.

0

czyli rozumiem, ze w wypadku gdyby panel był tym głównym, dużym "mózgiem" całego programu, mam tworzyc klasy ktore rozszerzaja ten główny panel, a nie posiadają obiekt tego głownego panelu?

moje zastanowienia wzięły się z tego, że myśle jak podejsc do tego problemu:
posiadam 3 klasy: GUI - rozszerzajaca JFrame, ScreenWindow - rozszerza JDialog oraz FullScreenPanel - roszerza JPanel. Sa one w sobie po kolei zawarte (tzn. w GUI jest przycisk ktory wlacza ScreenWindow na ktorym umieszczony jest FullScreenPanel ;) )

Chodzi o to, ze chce zamknąć ScreenWindow za pośrednictwem tego panelu FullScreenPanel. FullScreenPanel implementuje mouselistenera i kiedy przycisk myszy zwolnie, ScreenWindow ma sie zamknąć.
Obiekt ScreenWindow jest stworzony w GUI - w klasie anonimowej przycisku(actionlistener).

I nie wiem jak moge z poziomu panelu FullScreenPanel zmieniac setVisible(t/f) na obiekcie ScreenWindow stworzonym właśnie w GUI w klasie anonimowej.
Troche pogmatwane, ale dam kod na wszelki wypadek ;)

 public class GUI extends JFrame
{
	private JButton zrobScreen;
	private ScreenWindow scwin;

	public GUI()
	{
		zrobScreen = new JButton("KLIKNIJ");
		zrobScreen.setBounds(10, 10, 120, 40);
		zrobScreen.addActionListener(new ActionListener(){

			@Override
			public void actionPerformed(ActionEvent arg0) 
			{
				if(scwin == null)
					scwin = new ScreenWindow(GUI.this);
				scwin.setVisible(true);
			}
			
		});
		add(zrobScreen);

nastepna klasa:

 public class ScreenWindow extends JDialog
{
	
	public ScreenWindow(){}
	
	
	public ScreenWindow(JFrame owner)
	{
		setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
		setUndecorated(true);
		
		JPanel fs = new FullScreenPanel();
		fs.setVisible(true);
		add(fs);
		
		setVisible(false);
		setLayout(null);
	}

}

oraz ostatni, panel FullScreenPanel:

public class FullScreenPanel extends JPanel implements MouseListener
{

	private GUI gui;
	private Screen sc;
	
	public FullScreenPanel()
	{
          [...]
		try {
			if(robot==null)
			robot = new Robot();
		} catch (AWTException e) {
			e.printStackTrace();
		}
		sc = new Screen();
		gui = new GUI();
	}

	@Override
	public void mouseReleased(MouseEvent e1)
	{
                [..]
                       // nie wiem jak w tym miejscu zamknac ten JDialog- ScreenWindow ktory sie otworzyl po kliknieciu buttona w gui
		gui.setVisible(true);
		JOptionPane.showMessageDialog(this, "Sialala!");
	}

} 

Nie wstawialem pełnych klas bo to by tylko utrudniło rozwiazanie mojego zapytania ;p

licze na odp :D

0

W sumie wydaje mi sie ze troche zly przyklad / framework wybrales, bo Swing czesciowo sam nie uzywa SRP (single responsibility principle). Np. delegaty sa odpowiedzialne zarowno za wyglad jak i 'dynamike', albo JComponent sa zarowno view i controllerem (kontrolerem jest rowniez po trochu taki delegat ;d).
Bardzo wielu ludzi mowi, zeby nie uzywac extends tylko implements i agregacji z delegacja, w swingu natomiast nie da sie pisac bez extends. James Gosling sam powiedzial ze gdyby mial zrobic Jave ponownie to pozbylby sie klas i extends ;d Ogolnie ja zawsze mialem duzo problemy ze zrozumieniem wzorcow i zasad w odniesieniu do frameworkow GUI, z wyjatkiem tych ktore specjalnie dla nich zostaly stworzone. GUI sie rzadzi wlasnymi prawami. Mozliwe tez ze po prostu jestem do kitu ;d

0

@init0
1)hm.. z tego co widze polecenie remove słuzy do usuwania jakiegos komponentu(albo tylko przycisku?). Mi chodzi o to, zeby całe okno JDialog (ktore u mnie zwie sie ScreenWindow) sie ukryło/zamknelo.
Probowalem zrobic gettera w GUI dla obiektu private ScreenWindow scwin; ale to nie zdaje egzaminu, probowalem wyciagnac przypisywanie wartosci dla tego scwin poza klase anonimowa, robic nowe obiekty itd, wszystko na nic się zdało

2)Jesli chodzi o ten enter: masz na myśli, żeby zamiast robic klase anonimową, po prostu zaimplementować ActionListenera i dodac metode actionPerformed i w niej chwytać zdarzenia z buttona, a w addActionListener dac: (this)?

Z tym actionlistenerem to kiedyś była dyskusja w moim temacie, każdy mówił inaczej - jedni, że powinno się robić klasy anonimowe, inni ze implementować actionlistenera i do tej pory nie wiem co słuszniejsze - dlatego robie tak jak mi głowa podpowiada, co bedzie bardziej użyteczne :D ale to tylko taka mała dygresja

@mućka
czytałem w książce core java 2 ze własnie swing sie opiera na modelu MVC - dlatego myslalem ze tutaj jednak to SRP, w skrócie, jest wyraźnie przedstawione, jednak sie myliłem :D dzieki za sprostowanie

to jak wie ktos moze jak zamknac ten jdialog z poziomu tego panelu? nie mam pomyslu od dluzszego czasu, a odpowiedz pewnie prosta ;p

#edit
po braku dostepu do komputera wymysłiłem ;) w konstruktorze JPanel dodalem argument typu JDialog, ktory potem ustawiam na pole w JPanelu. Wtedy mam odniesienie do tego JDialoga mojego (ScreenWindow) i go zamykam

dzieki za wszystko:)

1 użytkowników online, w tym zalogowanych: 0, gości: 1