We have handled many J2EE projects at the Sun Java Center, and over time we have noticed that similar problems recur across these projects. We have also seen similar solutions emerge for these problems. While the implementation strategies varied, the overall solutions were quite similar. Let us discuss, in brief, our pattern identification process.
When we see a problem and solution recur, we try to identify and document its characteristics using the pattern template. At first, we consider these initial documents to be candidate patterns. However, we do not add candidate patterns to the pattern catalog until we are able to observe and document their usage multiple times on different projects. We also undertake the process of pattern mining by looking for patterns in implemented solutions.
As part of the pattern validation process, we use the Rule of Three, as it is known in the pattern community. This rule is a guide for transitioning a candidate pattern into the pattern catalog. According to this rule, a solution remains a candidate pattern until it has been verified in at least three different systems. Certainly, there is much room for interpretation with rules such as this, but they help provide a context for pattern identification.
Often,similar solutions may represent a single pattern. When deciding how to form the pattern, it is important to consider how to best communicate the solution. Sometimes,a separate name improves communication among developers. If so,then consider documenting two similar solutions as two different patterns. On the other hand,it might be better to communicate the solution by distilling the similar ideas into a pattern/strategy combination.
Patterns Versus Strategies
When we started documenting the J2EE patterns, we made the decision to document them at a relatively high level of abstraction. At the same time, each pattern includes various strategies that provide lower level implementation details. Through the strategies, each pattern documents a solution at multiple levels of abstraction. We could have documented some of these strategies as patterns in their own right; however, we feel that our current template structure most clearly communicates the relationship of the strategies to the higher level pattern structure in which they are included.
While we continue to have lively debates about converting these strategies to patterns, we have deferred these decisions for now, believing the current documentation to be clear. We have noted some of the issues with respect to the relationship of the strategies to the patterns:
J2EE Related Interview Questions
|Java Script Interview Questions||Adv Java Interview Questions|
|J2SE Interview Questions||Core Java Interview Questions|
|Java Struts Interview Questions||Hibernate Interview Questions|
|JavaServer Faces (JSF) Interview Questions||Java 8 Interview Questions|
|JavaFX Interview Questions||NHibernate Interview Questions|
|Spring MVC Framework Interview Questions||The Java Debugger (JDB) Interview Questions|
J2ee Platform Overview
Presentation Tier Design Considerations And Bad Practices
Business Tier Design Considerations And Bad Practices
J2ee Patterns Overview
Presentation Tier Patterns
Business Tier Patterns
Integration Tier Patterns
Epilogue J2ee Patterns Applied
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.