Sie sind auf Seite 1von 3

design Principles: - open close open to updation close to modification - dependency inversion goal is to decouple the tightly couple

modules. high level modules should not depend on low level modules. They should b e depended on the Abstraction. Abstraction should not be depended on the details. details should be dep ended on the Abstraction. - single responsibility Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities th e change might affect the other functionality of the classes. - interface segregation dont use fat interfaces. segregate the methods into diff interfaces. if we dont do that class would have to implement some irrelevant methods . Java design patterns: 1) Singleton pattern. purpose: to have only one instance of this class in the system, allowing other classes to access this object e.g. calender instance. getInstance() method. Implementation: - give private constructor. - getinstance method it returns the object. - static class type object. - override clone() method. Uses: - Logger class. - Configuration class like driver loading. - if serial port is to be used we provide a singleton handler an d synchronized method. 2) Factory pattern. purpose: creates the object without exposing the things happening at the object creation. use created object by high level interface Implementation: - provide private constructor. - provide public static method which will create the object. 3) Facade pattern. purpose: to provide a simplified interface to a group of subsystems or a complex subsystem. to make complex systems easier to use by providing a simpler in terface without removing the advanced options. facade defines a higher-level interface that makes the sybsyste m easier to use. Examples: - JDBC design is an example a database design is complex system to design but JDBC p rovides easier ways to connect to database and manage the data without exposing details. Implementation:

TravelAgent{ HotelAgent; FlightAgent; method getHotelAndFlight() {} } use the method to get both hotel and flight booking DAdone rathe r than saperately doing it. J2EE design patterns: 1) DAO pattern(Data access object) problem: data resource operations are a complex mechanism. So the databa se logic , presentation logic and business logic comes together. purpose: to saperate all the diff kinds of logic mentioned above. 2) Transfer Object problem: if set of attributes are to be shown together, we need to call method for individual attribute. solution: bind those attributes into a single object and call for that o bject. it is the use of transfer object. Implementation: - provide a simple POJO(javabean) as a transfer object. - declare all the fields as public. - it must be serializable. "diff between pojo and javabean: javabean is serializable but pojo can b e non-serializabele" 3) Front Controller: problem: code duplication. view navigation is left to views this leads to a major code cha nges if the view navigation is changed 4) MVC: Model: Data and business logic. View: Representation of the data. Controller: the bridge between model and view. intercepts the user input s and take decisions. 5) Service Locator: purpose: to retrive the remote services and resources. relevant to "connection pooling and JNDI connection(reserved ser vice or resource)" servicelocator object acts as a connection between 2 tiers. uses the application's central point to operate. chaceing. client invokes the appropriate method to get specific service. reduces network traffic etc. implementation: service locator should be singleton. service locator communicates with repositiry through initialinte rface, controls the cache, does lookup etc. 6) Business Delegate: purpose: to hide complexity of remote communication with bus service comp onents from the clients. problem:

when client directly communicates with remote resources or servi ces. - network performance - when service logic changes whole client logic is to be changed. solution: use business deligate to encapsulate the logic hides the details like lookups reduces coupling between clients and services caching can improve the performance.

7) View Helpers: - provides the implementation for view part. - if we dont use view helpers reusablity can not be achieved too much java code in view part maintanence can be hectic. - solution remove all the view logic from model view contains the representation logic 8) Intercepting Filters: problem: when request comes at server some common tasks like compression, logging should be done these task should be implemented into servlets if we dont use fi lters solution: dont need to modify the servlet code. filter chain is maintained by filter manager. websites: -------------allapplabs.com javacamp.org oodesign.com informit.com jpgtutorials.com

Das könnte Ihnen auch gefallen