Interfész

1. Interfész • Egy interfészből nem lehet példányt létrehozni • Az interfészek örökíthetők Az interfész (interface) metódusfejeket definiál abból a célból, hogy valamely osztály azt a későbbiekben implementálja, megvalósítsa.

2. Interfaces are used to collect like similarities which classes of various types share, but do not necessarily constitute a class relationship. • For instance, a human and a parrot can both whistle, however it would not make sense to represent Humans and Parrots as subclasses of a Whistler class, rather they would most likely be subclasses of an Animal class (likely with intermediate classes), but would both implement the Whistler interface.

3. Another use of interfaces is being able to use an object without knowing its type of class, but rather only that it implements a certain interface. • For example, a sorting algorithm may expect an object of type Comparable. Thus, it knows that the object's type can somehow be sorted, but it is irrelevant what the type of the object is. • Finally, interfaces may be used in place of multiple inheritance of classes.

4. public interface Predator { public boolean chasePrey(Prey p); public void eatPrey(Prey p); } public class Cat implements Predator { public boolean chasePrey(Prey p) { // programming to chase prey p } public void eatPrey (Prey p) { // programming to eat prey p } }

5. If a class implements an interface and is not abstract, and does not implement a required interface, this will result in a compiler error. • If a class is abstract, one of its subclasses is expected to implement its unimplemented methods. • Classes can implement multiple interfaces

6. Absztrakt osztályok • Az elvont, vagy absztrakt osztályok bizonyos értelemben egyfajta átmenetet képeznek a hagyományos osztályok és az osztályokat meghatározó interfészek között. • Ez azt jelenti, hogy egy absztrakt osztály egyaránt tartalmaz kidolgozott, törzzsel rendelkező tagfüggvényeket, és előre nem meghatározott tagfüggvényeket, melyeket majd az osztályból származtatott alosztály fog részletesen definiálni. • Az absztrakt osztály hagyományos értelemben vett osztályként és a tőle öröklő alosztályok interfészeként egyszerre tölt be funkciót.

7. «interfész» java::util::Collection «interfész» java::util::List get(int index) : Object set(int index, Object element) : Object add(int index, Object element) remove (int index) : Object addAll(int index, Collection c):boolean indexOf(Object o) : int lastIndexOf(Object o) : int listIterator() : ListIterator listIterator(int index) : ListIterator subList(int fromIndex, int toIndex) : List size() : int isEmpty() : boolean contains() : boolean add(Object element) : boolean remove(Object element) : boolean equals(Object o): boolean containsAll(Collection c) : boolean addAll(Collection c) : boolean removeAll(Collection c) : boolean retainAll(Collection c) : boolean clear() toArray() : Object[] toArray(Object a[]) : Object[] iterator() : Iterator java::util::Vector

8. «interfész» Comparable Object +compareTo(Object obj): int String +compareTo(Object obj): int ... Comparable interfész A String hasonlítható

9. java.lang Interface Comparable Method Summary public int compareTo(Object o)          Compares this object with the specified object for order.

10. Az interfész implementálása public final class String implements Comparable { ... public int compareTo(Object o) { return compareTo((String)o); } public int compareTo(String anotherString) { ... } }

11. Collections osztály • A Java kollekció keretrendszer része • A java.util csomagban található • Nem példányosítható • Statikus metódusai konténereken (kollekciókon listákon) értelmezett algoritmusok: rendezés, megfordítás, keverés, minimum- és maximumszámítás, bináris keresés • Bizonyos metódusok megkövetelik, hogy az elemek összehasonlíthatóak (Comparable) legyenek • A sort, min, max és binarySearch metódusoknak paraméterül átadott kollekció elemeinek implementálniuk kell a Comparable interfészt!

12. java::util::Collections +sort(List list) +reverse(List list) +shuffle(List list) +min(Collection coll): Object +max(Collection coll): Object +binarySearch(List list,Object key)

13. Például Vector szamok = new Vector(); // benne Integer elemek System.out.println("min="+Collections.min(szamok)); System.out.println("max="+Collections.max(szamok)); Collections.sort(szamok); int index = Collections.binarySearch(szamok, new Integer(Console.readInt("Keresendő: "))); System.out.println("Indexe= "+index); Collections.reverse(szamok); Collections.shuffle(szamok);

14. Tervezési minták – Design Patterns • A tervezési minták (tervminták) lényegében azokra a problémákra nyújtanak egyfajta általános megoldást, melyekkel a szoftverfejlesztők gyakran találkoznak. • Ha felfedjük egy probléma lényegét és összevetjük hasonló, már megoldott problémákkal, ugyanazokkal a lényegi lépésekkel találkozunk. • GoF, or Gang-Of-Four (Négyek Bandája) Design Patterns: Elements of Reusable Object-Oriented Software (1995) (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

16. In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. • A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. • Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. • Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

17. Classification For example: • Architectural patterns • Creational patterns • Structural patterns • Behavioral patterns

18. Tervminták megadása • A minta neve és osztálya: egy jó névnek utalnia kell a felhasználás területére, a megoldott feladatra. • Cél: rövid leírása annak, hogy mi a minta által megoldott feladat vagy feladatosztály. • Más nevek: további, mások által használt nevei a mintának, ha van ilyen. • Motiváció: egy esettanulmány, amely bemutatja a tervezési feladatot, és hogy miként oldja meg azt a minta a benne szereplő osztályok és objektumok segítségével. • Felhasználhatóság: annak leírása, hogy milyen esetekben lehet a mintát alkalmazni. • Szerkezet: itt kell megadni a megfelel UML diagramot vagy diagramokat. • Elemek: a mintában előforduló osztályok, objektumok és szerepeik felsorolása.

19. Együttműködés: annak bemutatása, hogy a minta elemei miként működnek együtt a szerepük megvalósítása érdekében. • Következmények: itt kell választ adni azokra a kérdésekre, hogy miként éri el a minta a célját; milyen kompromisszumok árán; a rendszer szerkezetének milyen összetevőit lehet függetlenül változtatni. • Implementáció: itt kell megadni az implementációval kapcsolatos észrevételeket, megjegyzéseket, ajánlásokat, megszorításokat. • Példa kód: kódrészletek, amelyek bemutatják, miként lehet a minta egyes elemeit egy adott nyelven megvalósítani. • Ismert használat: példák a minta előfordulásaira működő rendszerekben. • Rokon minták: a hasonló minták nevei, a fontosabb különbségek felsorolása, illetve annak a megadása, hogy mely más mintákkal célszerű együtt használni.

20. Példa: Figyelő (Observer) Név, osztály: figyelő (observer); viselkedési (behavioral). Cél: Olyan egy-több függőség megadása objektumok között, amelyben ha egy objektum állapotot vált, akkor az összes tőle függő objektumot értesíteni és módosítani kell. Más nevek: dependents, publish/subscribe. Motiváció: Egy gyakori mellékhatás, ami egy rendszer együttműködő osztályokra bontása során felmerül, a kapcsolatban álló objektumok közötti konzisztencia fenntartásának szükségessége. Erre egy példa, amikor egy statisztika százalékos adatait akarjuk megjeleníteni táblázat, oszlopdiagram vagy kördiagram formájában. Egyidejűleg több formában is láthatók az adatok. Ekkor a statisztika a megjelenítés tárgya, a diagramoknak pedig mindig annak aktuális állapotát kell mutatniuk, anélkül hogy a diagramok egymásról tudnának. Ha bármelyiken változtatás történik, akkor az megjelenik a statisztikában, és az értesíti az összes diagramot. Ebben a példában a statisztika a tárgy (subject), a diagramok pedig a figyelők (observers).

21. Felhasználhatóság: A figyelő tervminta használható az alábbi esetekben: • Ha egy absztrakcióban két olyan tényező szerepel, amelyek közül az egyik függ a másiktól. Ha ezeket külön objektumoknak tekintjük, akkor lehetséges egymástól független változtatásuk és újrafelhasználásuk. • Amikor egy objektum állapotának megváltoztatása más objektumok változtatását teszi szükségessé, és nem ismert ezen objektumok száma. • Amikor egy objektumnak üzenetet kell küldenie más objektumoknak, amelyekről nem tehetünk fel semmit; azaz nem akarjuk szorosan összekapcsolni ezeket az objektumokat.

25. Java példa

26. Anti-patterns • Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. • They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems. • For examle: God object: Concentrating too many functions in a single part of the design (class) „Mindenható osztály”: az osztály hajtja végre majdnem az összes teendőt, a többi osztálynak legfeljebb támogató műveleteket hagy. Az osztály lényegében egy bonyolult és összetett vezérlő osztály, amelyet egyszerű osztályok vesznek körbe. Ezen osztályoknak csak adattárolási funkciójuk van (csak get és set műveletek).

29. However, design patterns have come under an increasing amount of criticism lately. Critics point out that inexperienced developers can easily fall into the pattern trap. The pattern trap blinds inexperienced developers. As such, instead of solving a solution in the best way possible, the end goal for novice developers centers on implementation of as many design patterns as possible. To some, using a design pattern seems to guarantee a good design. By that logic, if you use a lot of design patterns, you'll have a great design! Often times this belief leads to designs that just don't make sense -- even though the design might incorporate multiple patterns. Unfortunately, a design pattern does not guarantee good design.

30. WEB alkalmazások készítése Java eszközökkel • Java szervlet • JavaServer Pages • Struts framework

31. Java Servlet technológia • komponens alapú, platform független • a szervlet egy példánya sok felhasználó kérését ki tudja szolgálni • a Java API teljes készletét fel tudjuk használni • szervlet konténer, pl: Apache Tomat (http://tomcat.apache.org/) • web design ↔ objektum orientált tervezés és programozás • példa

32. JavaServer Pages • Allows software developers to dynamically generate HTML documents in response to a Web client request. • The technology allows Java code and certain pre-defined actions to be embedded into static content. • The JSP syntax adds additional XML-like tags, called JSP actions, to be used to invoke built-in functionality.

33. JSP oldalra érkező kérés feldolgozása

34. A háttérben lezajló folyamat • A kliens elküldi a JSP oldalra vonatkozó kérést a webszervernek. • A webszerver felismeri, hogy egy JSP oldalra vonatkozik a kérés. • A kérést továbbítja a webszerverhez tartozó JSP konténernek. • Ha a JSP oldal még nincs lefordítva (ez volt az első kérés) , akkor a JSP kód szervletté, majd a szervlet java kódja bájtkóddá fordul. • A lefordított szervlet végrehajtódik, és a végrehajtás eredményeként előáll egy HTML oldal, amelyet a webszerver - a kérésre válaszul - elküld a kliensnek JSP oldal – visszájára fordított szervlet A beágyazott Java kód segítségével a JSP oldalak bármilyen Java osztályt képesek használni.

35. JSP architektúrák - Model1 A Model1 architektúra a legegyszerűbb alkalmazása a JSP techno- lógiának . Csak JSP oldalaink vannak és a hozzájuk tartozó Java osztályok.

37. Belep.jsp <%@ page contentType="text/html; charset=windows-1250" %> <html> <head> <title> Belep </title> </head> <jsp:useBean id="UserBeanId" scope="request" class="nevek1.UserBean" /> <body> <h1> Bejelentkezés </h1> <form method="post" action="Kovetkezo.jsp"> <br>Felhasználói név: <input name="nev" value=<jsp:getProperty name="UserBeanId" property="nev" />> <p>Jelszó: <input type="password" name="jelszo" value=""><br> <br><br> <input type="submit" value="Belép"> <input type="reset" value="Törlés"> <jsp:getProperty name="UserBeanId" property="hibauzenet" /> vagy: <% out.println(UserBeanId.getHibauzenet()); %> </form> </body> </html>

38. UserBean.java public class UserBean { private String nev, jelszo, hibauzenet; private boolean nevhiba, jelszohiba; public UserBean(){ nev=""; jelszo=""; hibauzenet=""; } public String getNev() { return nev; } public String getJelszo() { return jelszo; } public void setNev(String nev) { this.nev = nev; } public void setJelszo(String jelszo) { this.jelszo = jelszo; }

39. public boolean hibas(){ nevhiba = nev.trim().equals(""); jelszohiba = jelszo.trim().equals(""); if (nevhiba & jelszohiba) hibauzenet = "<p><font color=red>A Felhasználói név és a Jelszó mező kitöltése kötelező!!!<br>"; else if (nevhiba) hibauzenet = "<p><font color=red>A Felhasználói név mező kitöltése kötelező!!!<br>"; else if (jelszohiba) hibauzenet = "<p><font color=red>A Jelszó mező kitöltése kötelező!!!<br>"; else hibauzenet = ""; return nevhiba | jelszohiba; } public String getHibauzenet(){ return hibauzenet; } }

40. Kovetkezo.jsp <%@ page contentType="text/html; charset=windows-1250" %> <html> <head> <title>Kovetkezo</title> </head> <jsp:useBean id="UserBeanId" scope="request" class="nevek1.UserBean" /> <jsp:setProperty name="UserBeanId" property="*" /> <body> <% if (UserBeanId.hibas()) { %> <jsp:forward page="Belep.jsp"/> <%} %> <h2>Üdvözlöm <jsp:getProperty name="UserBeanId" property="nev" /></h2> <p><input type="button" value="Vissza" onClick="document.location='Belep.jsp'"> </body> </html>

41. JSP architektúrák – Model2 Egymástól élesen elkülöníthető feladatkörű komponensek → haté-konyabb fejlesztés és karbantartás.

42. Model: az üzleti logikát tartalmazó objektumok halmaza (Java osztályok). • Üzleti logikának nevezzük az alkalmazásban megvalósított kódnak azt a részét, amely szigorúan csak a megvalósított folyamatért felelős, azaz nem felelős a megjelenésért, adatbáziskapcsolatért, vezérlésért, stb. (pl.: egy gépkocsiban az üzleti logika a motor, egy programozási környezetben a fordító, oprendszerben a kernel) • View: kizárólag a megjelenítést, a GUI felület kialakítását végző objektumok (JSP oldalak) • Controller: az előbbi két részmodult összekapcsoló, és a teljes alkalmazást mozgató vezérlési logika (servletek)

43. A modell működésének lépései • A kliens kéréssel fordul a webszerver felé (request) • A webszerver a request-et továbbítja a Controller-nek. • A Controller beazonosítja a kérést és ellenőrzi annak végrehajthatóságát. • A Controller a kérés alapján kiválasztja és meghívja a végrehajtandó üzleti logikát. Ez Model objektumok aktiválását jelenti. • A Model objektumok metódusait meghívva előáll a végrehajtott üzleti logika eredménye. • A Controller kiválasztja a megjelenítendő JSP oldalt és a vezérlést átadva, az adatréteg objektumai segítségével a JSP oldal lefordul. • A JSP oldal eredményét, vagyis a megjelenítendő HTML oldalt a webszerver továbbítja a kliens felé.

44. Apache Struts • A JSP oldalak és a köréjük épülő logika készítését megkönnyítendő több keretrendszer készült. • Ezek egyike a Struts. • Lehetővé teszi, hogy a fejlesztők az üzleti logikára koncentráljanak.

45. The goal of Struts is to cleanly separate the model (application logic that interacts with a database) from the view (HTML pages presented to the client) and the controller (instance that passes information between view and model). • Struts provides the controller (a servlet known as ActionServlet). • The web application programmer is responsible for writing the model code, and for creating a central configuration file struts-config.xml which binds together model, view and controller. • Requests from the client are sent to the controller in the form of "Actions" defined in the configuration file; • If the controller receives such a request it calls the corresponding Action class which interacts with the application specific model code. • The model code returns an "ActionForward", a string telling the controller which output page to send to the client. • Information is passed between model and view in the form of special JavaBeans. • A powerful custom tag library allows to read and write the content of these beans from the presentation layer without the need for any embedded Java code.

46. Struts-config.xml <form-beans> <form-bean name="logonForm" type="sample.action.LogonForm"/> <action-mappings> <action path="/logon" type="sample.action.LogonAction" name="logonForm" input="/logon.jsp"></action>

47. Egy JSP oldal részlet Struts akciókkal <html:form action="/logon" focus="username"> <table> <tr><td colspan=2><bean:message key="application.name"/></td></tr> <tr><td><bean:message key="label.username"/></td> <td><html:text property="username" size="16" maxlength="16"/></td></tr> <tr><td><bean:message key="label.username"/></td> <td><html:password property="password" size="16" maxlength="16"/></td></tr> </table> <br> <html:submit><bean:message key="button.logon"/></html:submit> </html:form>