Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The modern view on implementation of classic design patterns in Java


Published on

Almost every developer heard about design patterns. They was introduced long time ago to solve particular set of repeating problems in systems of different complexity level and size. But there is an opinion that many design patters just filled holes in the OOP languages of that time. Java as one of them has transformed and improved significantly in the last 10 years. So may be we could review design patterns implementation in modern Java world? Some of them are now may be easily replaced with language idioms, some others may be covered with existing libraries and frameworks. I'm sure you know some design patterns that are dead now or became anti-patterns in their initial implementation. Lets make this fun and useful review together!

Published in: Technology

The modern view on implementation of classic design patterns in Java

  1. 1. The modern view on implementation of classic design patterns in Java Mikalai Alimenkou @xpinjection
  2. 2. Disclaimer This is only my personal experience
  3. 3. Familiar with design patterns?
  4. 4. Holy bible for developers 
  5. 5. Java have long/slow roadmap
  6. 6. You could follow code samples
  7. 7. #1: Singleton
  8. 8. DI fight against Singleton
  9. 9. This is common anti- pattern now Isolate existing Singletons from new code with DI DI containers ‘killed’ Singleton pattern
  10. 10. #2: Builder
  11. 11. ‘Storing’ VS ‘runtime’ style builders Builder is the most common pattern Java is still bad in handling properties
  12. 12. #3: Prototype
  13. 13. DI container handle prototypes in their own way Clone method in Object is confusing Useful for domain model with DDD style
  14. 14. #4: Factory Method
  15. 15. Use basic functional interfaces if possible Doesn’t work for abstract factory Constructor is also a function
  16. 16. #5: Adapter
  17. 17. Functional interfaces are interchangeable Doesn’t work for complex interfaces Use basic functional interfaces if possible
  18. 18. #6: Proxy
  19. 19. May be done with composite functions Inline lambda wrapping is also available Main usage with AOP and DI containers
  20. 20. Libs for manual proxy creation • java.lang.reflect.Proxy • Byte Buddy ( • cglib ( • javassist ( javassist/javassist)
  21. 21. #7: Template Method
  22. 22. Utilize basic functional interfaces Inline needed parts in tests and simple clients Use composition instead of inheritance
  23. 23. #8: Command
  24. 24. Collect commands in collection or combine them Doesn’t work with complex commands (with ‘undo’) Dude, this is just a plain lambda!
  25. 25. #9: Chain of Responsibility
  26. 26. Combine consumers in the chain Doesn’t work for “workflow” handlers May be use typed functions pipeline?
  27. 27. #10: Strategy
  28. 28. Inline strategy in tests and other light clients Store strategies in single holder as static methods Dude, this is just a plain lambda again!
  29. 29. #11: Iterator
  30. 30. Use Streams everywhere Create own streams with Spliterator Forget about manual iterations
  31. 31. #12: Decorator
  32. 32. Wrap function with lambda Combine functions to provide additional behavior Use the Proxy approaches
  33. 33. #13: Observer
  34. 34. Pass methods as listeners Observer and Listener are functional interfaces Inline listener logic in lambda
  35. 35. #14: Visitor
  36. 36. Use general implementation Try to use default methods where applicable Very rarely used design pattern
  37. 37. And remember…
  38. 38. @xpinjection