Thank you for your question. I will answer the pints in turn.
1, what do mean by time saving patterns ? -- >Can you explain this with a simple Java Code to understand better.?
2. "Learn how Java EE offers implementation of many patterns through annotations and a cleaner programming model than J2EE". -- > Can you explain this with a simple Java Code to understand better.?
We mean that you need to write less code if the pattern is implemented in Java EE compared to Java SE. Here is an example of the Factory Pattern implemented in Java SE.
First you create the abstract factory class.
Then you implement the abstract class.
And finally you create an instance of the factory and call the factory method ceateMessage().
In Java EE we use two annotations (@Produces and @Inject) and the Context and Dependency Injection framework to do much of the work for us.
Here we create the factory and produce the message.
and finally we use the message by injecting the produced message and printing it to the console.
As you can see the amount of code that we need to write is minimal as the CDI takes care of the creation and injection of the message.
3. Good to know you have explained Aspect Oriented Programming, Asynchronous Programming, and Restful WebServices
We also discuss microservices and message orientated middleware both hot topics at the moment.
4. Learn when patterns are not the answer, why that is, and what to use instead --> Can you explain this with a simple Java Code to understand better?
To demonstrate this with code is a little difficult in such a small space, a context is necessary. Patterns are not magic bullets that will solve all your problems. You must first understand the problem and how a pattern might be able to help solve it and also how the pattern might make the problem worst. We discuss each pattern, talking about their pros and cons and things you should watch out for. Additionally we tell wars stories about the use of the pattern in real life. The story may be an example of how the pattern saved the day or maybe a story about how the pattern caused more problems than it solved.
I hope I have answered you question. Please feel free to go to the amazon website a have a look inside Professional Java EE Design Patterns in order to get a feel of what its like. I think you will find it useful.
Thank you Deepak for your question. I will answer them in turn.
Deepak Lal wrote:
Yet the query number 4 is unanswered with a sample code ??
To answer with simple Java code would be almost impossible as a great deal of context would be required so using small code snippets would be meaningless. Nevertheless the important point to take away it that design patterns may help solve known problems, but one should not apply a pattern to a problem just because that is what you have learnt you should do or because its 'fashionable'. You must first analyse weather or not that pattern really would solve the problem. For example: the use of the REST pattern (Level 3 on the Richardson Maturity Model, and may be consider fashionable) may make it easy for others to access your resources but it is very chatty and may result in higher network resource usage and performance issues, therefore an alternative solution may be to use a SOAP or RPC style approach (Level 1 on the Richardson Maturity Model) although it is trickier to use (and out of fashion). However the additional resource usage may be justifiable if it is more important that your resources are easily accessible. You wait up the pros and cons and not just use REST because its what you have been taught to use or because it is fashionable.
Deepak Lal wrote:
Unfortunate to see a customer who has bought the book saying its a Fraud on the authors website. --Please comment ?
I agree, it is unfortunate that someone felt it necessary to post such an unconsidered review. Left me respond to each point.
The reviewer refers to the language as childish, we would prefer to refer to the language as accessible and enjoyable. We have taken a joyfully approach to a rather dry subject, and attempted to make it as pleasurable as possible. I suggest that this style is not to the taste of the reviewer.
The code example clearly demonstrates the concepts that are being discussed, they are deliberately kept simple to ensure that the message is not lost among a clutter of overly complicated code.
As far as the code examples not compiling, this is untrue. They all compile. They are presented in an IDE neutral way so that they can be imported into your favourite IDE. Some work is required to get them working with your chosen IDE, that is the consequence of presenting them in an IDE neutral way, however any competent developer would not find it difficult nor too much work to get the best from the code source. I feel it would have been more appropriate for the reviewer to contact either Murat or I directly with regard to code source related issues.
I hope I put to rest any concerns you have. Thank you for participating in this book promotion.
BTW The winners are chosen by Ranch staff, neither Murat nor I can influence who wins.