Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

I savor, cause I discovered exactly what I was having a look for. You’ve ended my 4 day long hunt! God Bless you man. Have a great day. Bye
- Graphic Design Singapore
Getting the below exception … Exception in thread “main” java.lang.NullPointerException at com.chain.responsibility.dispenser.HundredDollarDispenser.dispense(HundredDollarDispenser.java:26) at com.chain.responsibility.dispenser.FiftyDollarDispenser.dispense(FiftyDollarDispenser.java:30) at com.chain.responsibility.dispenser.ATMDispenseChain.main(ATMDispenseChain.java:33)
- Vijayendran T R
Hi… Nice tutorial… Just 1 suggestion setNextChain() would have been moved to DispenseChain abstract class instead of keeping DispenseChain as abstract class and overriding setNextChain() in all the concrete classes…
- kushi
Good example. I’d like to point out one thing though. The pattern per GoF definition says that ‘Only one object in the chain is supposed to handle a request’. In your example I see handlers($50 and $20) doing the work partially and letting $10 handler do the rest of the job.
- Gaurav
After implementing this design pattern for years, i commonly see that there is repeated code in the concrete classes just like the implementation of your dispense methods. The intent of this design pattern is nice, but dont forget the DRY principle and it is a must in my humble opinion. I always use abstract classes for cor design pattern to eliminate duplicate code.
- killer
Mate, once again, check your English! It’s loose coupling. Furthermore, Gaurav, you’re right about only one object handling the request. That would be what’s called a pure implementation. On the other hand, there’s no real problem to let the request go through the entire tree. Another point, which is not discussed in this article, is that you may set or change the next handler during runtime. You also may not know beforehand which are the handlers that should be used, allowing the client to set them as desired. As an example, you could have many Validator classes which can be called in a certain order. But that depends on the validation. So you apply CoR and make good use out of the possibility of combining different validators ordered in so many different ways. Suppose you want to validate an email address. You need to check if the e-mail is correctly formed, if it exists, and if contains bad words. To do this job, you may have three different classes, and you can arrange them in any order - so you might as well let the client decide its own priority.
- You Know
Thank you very much Pankaj. The tutorial on Design Patterns was very helpful. I could get a brief overview of Design Patterns and one more good point is that you have taken real world examples to demonstrate. In some part of the tutorial you have mentioned that one design pattern can be combined with the other to make it more efficient, it would be helpful if you post some samples on it. Great work buddy. Thanks a lot.
- Bharath