Vzory pro závody Java


Original: http://csis.pace.edu/~bergin/patterns/event.html

Joseph Bergin

Píšete Java program s tlačítky, polí, nebo jiných součástí a je třeba vyvinout události strukturu.

Myslete na posluchače události, Java, jako kdyby byly Command objekty, které jsou odpovědné za provádění příkazů na aplikaci, když uživatel manipuluje uživatelského rozhraní. Posluchači / příkazy jsou součástí funkčnosti aplikace, nikoli jeho rozhraní. Jinými slovy, oni jsou regulátory, které tvoří “lepidlo” mezi Názory a modelu nejsou součástí pohledů samotných.

Síly, které zde platí. Chceme se vyhnout non-objektově orientovaný ruku dispečink metod (pomocí přepínače prohlášení) a nechte infrastruktura Java zvládnout základní tok řízení. Chceme být schopni přidat další prvky grafického uživatelského rozhraní a dokonce i kompletní výhled na naší základní aplikační framework beze změny mnoho existující kód. Chceme, aby příkaz objekty (posluchači), které provádějí pokyny pro uživatele do aplikace, které mají být spojeny s aplikační framework v místním způsobem – a není součástí Zobrazit struktury.

Jednosložkové za Listener

Vytvořte jeden objekt posluchače pro každý prvek a přidat posluchače ke komponentě. Metody posluchače třídy bude zpracovávat události pro danou součást pouze.

Například, budete mít rozhraní se dvěma tlačítky. Pak použít dva různé posluchače, jeden pro každé tlačítko. Ty mohou pocházet z téže třídy nebo různých tříd. Viz faktorem pro funkčnost

Tlačítko redButton = new Button (“RED”);
redButton.addActionListener (nové ColorActionCommand (Color.red));
Tlačítko greenButton = new Button (“zelená”);
greenButton.addActionListener (nové ColorActionCommand (Color.green));

Použití samostatné posluchače znamená, že by nemělo být nutné provádět logické testy, které zjistí, co by mělo být provedeno v posluchači. To má dvě výhody. Nejprve to dělá spuštění kódu o něco rychlejší. Za druhé se zvyšuje udržovatelnost a rozšiřitelnost vašeho kódu. Pokud potřebujete přidat novou komponentu, nemusíte měnit stávající metody.

Všimněte si, že jednotlivé posluchači nemusí být jmenován. Je dost vytvořit jako argumenty přidanými metodami posluchače.

Odůvodnění: Pokud se pokusíte mít jeden posluchač (často applet nebo aplikace samotný objekt) fungují jako posluchače pro několik složek, pak jste odklízení základní depeši, která je zásadní pro volání metod a provádějí odeslání ručně. To vyžaduje, aby nějaká přepínacím mechanismu použít k odlišení různých složek, jejichž události, které jsou manipulace. Systém je lépe vybavena k tomu, než jste. Tento přepínač struktura je tak náchylné k chybám a náročné na údržbu, protože program roste. Nechte odeslání do systému.

Faktorem pro funkčnost

Také známý jako jednu třídu na funkčnosti Group

Některé komponenty je třeba reagovat podobným způsobem, ale je možné je od sebe odlišit na základě malého počtu hodnot a parametrů. Například, může být kalkulačka applet několik tlačítek, ale číselná tlačítka vše se chová stejným způsobem, kromě toho, že každý musí zpracovat jinou číslici.

Vytvořte jednu třídu posluchače událostí pro všechny komponenty s podobným chováním, ale přesto vytvořit jeden objekt posluchače pro každou z těchto složek. Tyto posluchači budou všichni členové jednoho posluchače třídy. Budete potřebovat konstruktor této třídy, který přijímá hodnotu nebo hodnoty, které odlišují jednotlivé posluchače od ostatních.

Například ve výše uvedené situaci, můžeme vytvořit jeden ColorButtonListener třídy:

třída implementuje ColorActionCommand ActionListener
{Public void actionPerformed (ActionEvent e)
{- Bez ohledu na použití MyColor
}

veřejné ColorActionCommand (barevná c)
{MyColor = c;
}

soukromé Barva MyColor;
}

V případě, že komponenty nejsou podobné funkce, nepokoušejte se používat stejné třídy vytvořit posluchače. Místo toho, napsat novou třídu pro každý jednotlivý funkčnosti skupinu složek.

V případě kalkulačky, jsou také funkční tlačítka (“+”, “-” …), kromě číselných tlačítek. Použijte jednu nebo více tříd pro tyto tlačítka, odlišné od třídy, která definuje číselné tlačítko posluchače.

Extrémní případ je ten, ve kterém každá složka chová odlišně od všech ostatních. Tento tzv. jednu třídu na Listener

Vnitřní Posluchači

Musíte napsat jednu nebo více tříd posluchače. Kam by se měl těchto tříd?

Všechny vaše posluchače tříd by mělo být na vnitřní třídy, která obsahuje složky, které posloucháte. Například pokud jste vytvořili nový panel objekt držet tlačítek je uvedeno výše, pak posluchač třídy by měly být vnitřní tohoto panelu třídy. Díky tomu je definice posluchače pocházející ze stejného místa, v němž se používá. Panel dále obsahuje obě tlačítka a tlačítko posluchače.

Vzhledem k tomu, o kterou se ucházíte jedna složka Per Listener nemusíte širší viditelnost.

To také poskytuje posluchače třídy přístup do dalších částí obvodového třídy, které mohou být nezbytné pro zpracování události. To zase minimalizuje počet potřebných parametrů, pokud je postaven objekt posluchače. To dělá, nicméně, zvyšuje propojení mezi ohradní třídy a posluchače třídy. Pokud obklopující třída je upravena, může být nutné upravit vnitřní třídu stejně.

Podělte se pouze tehdy, je identický by vyžadovala a nejnižší

Máte několik složek, a některé z nich se musí chovat shodně s ostatními.

Dejte stejný posluchače ke všem komponentům, které jsou zaručeny reagovat stejně.

Někdy je logika tohoto problému je taková, že obě složky musí nutně reagovat stejným způsobem. V této situaci by měl být stejný posluchač být použit pro obě složky. Poté, aktualizace zpracování pro jednu komponentu automaticky se tak pro ostatní. Pokud máte dva posluchače / příkazy, pak budete muset držet je v synchronizaci jako problém změny. To může způsobit problémy s údržbou.

Například, někdy chcete Button provádět některé akce na obsah TextField. Pokud chcete také stejné akce, která se provádí, když uživatel klikne na tlačítko Enter, zatímco pole je aktivní, pak stejný posluchač by měl být použit jak pro tlačítka a pole.

Delegát Když Požadavky libovolně měnit

Máte komponenty, které se chovají stejně, ale uvědomit si, že tato situace může v budoucnu změnit.

Někdy současný design znamená, že obě složky musí reagovat stejně, ale to je si uvědomil, že by to mohlo v budoucnosti změnit.

V této situaci platí jedna složka Per Listener a jednu třídu na posluchače. Už akční metody jedné z těchto tříd (delegující) stačí zavolat ty ostatní. To vyžaduje, aby delegující mít třída konstruktor bere parametr, který je další komponenty posluchač. To vyžaduje, aby pojmenování posluchače.

Pokud se situace v budoucnu změní a dva komponenty vyžadují různé akce, pak to delegující třída bude muset být přepsán.
Komponenta Naslouchá sobě

(Tento model je díky Ed Epp University of Portland). Jste navrhování GUI s mnoha komponent. Jak můžete dát jasně najevo, které posluchač jde s, která komponenta.

Pro každou komponentu skupiny stejného druhu, který musí jednat stejným způsobem vytvořit třídu, která rozšiřuje AWT komponenty a realizuje odpovídající posluchače rozhraní. Už konstruktor přidat toto jako posluchače.

Například. Předpokládejme, že chcete použít tlačítko (nebo sada tlačítek), která se chová určitým způsobem. Budovat a použít třídu jako

třída FooCommandButton rozšiřuje tlačítko implementuje ActionListener
{Public FooCommandButton (…)
{…
addActionListener (this);
}

public void actionPerformed (ActionEvent e)
{…
}
}

Tato třída může být umístěna kdekoliv, že je to výhodné. To může být vnitřní třídy, nebo to může být veřejná nebo soukromá nejvyšší úrovni třídy.

Je-li další součást jiné třídy musí jednat stejně jako je tento, jako je pole, jehož činnost posluchač by měl provést stejným způsobem na tlačítko přidat tuto složku jako posluchače na druhého. To znamená, že mohou být přidány jako FooButton posluchače pro odesílatele.

Všimněte si, že tento vzor zahrne všechny ty dřívější kromě vnitřních posluchačů. Tím, že tyto třídy vnitřní třídy získáte výhodu viditelnosti polí a metod, které obsahují třídy, když napíšete actionPerformed metody. To může být velmi užitečné. Proto může být nejlepší kombinovat komponenty Naslouchá sobě a vnitřní posluchačů.

Tento vzor má některé negativní důsledky, nicméně. To je jen opravdu užitečné, když je tam jen jeden a GUI komponenta smí postavit malou množinu možných událostí. Nicméně, v případě, že jsou více rozhraní na stejnou základní aplikace, může být obtížné sdílet příkazy mezi nimi, protože příkazy jsou v komponenty grafického uživatelského rozhraní. Pokud součást musí reagovat na více událostí, jako jsou zaměření akcí nebo dílčích akcí, například, pak tyto třídy jsou stále nemotorné a zapouzdření příliš mnoho na jednom místě, které by pravděpodobně být odděleny.

Poslední aktualizace: 12.05.2000

Comments are closed.