This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
Hi All, I thought of putting forward a list of J2EEpatterns of which Iam familiar with.Wd like everyone to contribute to it and if someone discusses about their respective anti-patterns it would be gr8 PatternDescription: Value Object:Reduce network traffic by acting as a caching proxy of a remote object.Total load on the remote object�s remote interface is decreased, because data represented by the Value Object are cached on the client by the Value Object instance. All accesses to the properties of the Value Objects are local, and so those accesses cause no remote method invocations.Decreased latency can improve user response time. Potential Liability - Stale data. Whenever a value object is backed by a volatile set of values (such as a stock's price and trading volume, for example) it should only be treated as a snapshot of those values.
MVC:Clarifies design by separating data modeling issues from data display and user interaction.Allows the same data to be viewed in multiple ways and by multiple users.Improves extensibility by simplifying impact analysis.Improves maintainability by encapsulating application functions behind well-known APIs, and decreasing code replication (�copy-paste-and-hack�).Enhances reusability by decoupling application functionality from presentation.Makes applications easier to distribute, since MVC boundaries are natural distribution interface points.Can be used to partition deployment and enable incremental updates.Facilitates testability by forcing clear designation of responsibilities and functional consistency.Enhances flexibility, because data model, user interaction, and data display can be made �pluggable�.
Data Access Object:Greater deployment flexibility�Resource vendor independence�Resource implementation independence�Easier migration to CMP�Enhanced extensibility�Increased complexity because of a level of indirection BusinessDelegate�Reduced coupling, improved manageability.�Service exception translation�Simpler, uniform interface hiding the details.Delegate may cache results � this may improve performance�Increased complexity because of a level of indirection
Front Component:�Provides centralized dispatching of requests, e.g. via a controller servlet.Enables centralized handling of security, navigation, and presentation formatting Fa�ade:Provides a layer between clients and subsystems of a complex system.Shields clients from subsystem components, making the subsystems easier to use
Factory:Handles requests for object creation Singleton:A class which can have at most one instance Template Method:The key idea is that there is a basic algorithm we want to stay the same, but we want to let subclasses vary how they do the steps. The Template Method says to define the algorithm in the parent class, but implementations of the steps in the subclasses
Bimodal Data Access:Under certain conditions, allows designer to trade off data consistency for access efficiency. JDBC provides read-only, potentially dirty reads of lists of objects, bypassing the functionality, and the overhead, of Entity enterprise beans. At the same time, Entity enterprise beans can still be used for transactional access to enterprise data. Which mechanism to select depends on the requirements of the application operation
Session Entity Fa�ade:Being an instance of the Facade pattern, this pattern shares its applicability. In the context of J2EE application development, use the Session Facade pattern when you want to provide a simple interface to a complex subsystem of enterprise beans or when you want to reduce communication & dependencies b/w client objects and enterprise beans.
Now if someone can add to the anti-patterns of the above along with explanations it would be complete.
Rishi, Not every pattern has a corresponding anti-pattern. It's not like matter and anti-matter. An anti-pattern is simply a common, bad way of doing things that people THINK is advantageous (but in fact is not, for reasons often too subtle for them to discern, at least while they're doing it...) Take a look at the previously discussed "Anti-patterns" book by Tom Mobray, et. al., or look here: http://c2.com/cgi-bin/wiki?AntiPatterns Kyle
Hi Kylie, Iam not saying that every pattern needs to have an anti-pattern.When I say anti-pattern i meant what could be possible flaws in the respective patterns which often does occur which can be taken care of (in restropective of being called an anti-pattern)
Kyle, I was able to access the paper you announced here once. Unfortunately I was unable to save it locally and subsequent attempts to get to it got a "page not found" error. Do you have it available elsewhere? Thanks! ...And thanks for dropping by Junilu