Factory Pattern in Java: Creating Objects with Ease

In this video, you'll learn how to implement the Factory Method Pattern in Java and how it can help simplify your object creation process. You'll see step-by-step how to implement this design pattern in your #java projects and follow along with practical examples to reinforce your understanding. By the end of this video, you'll be able to create objects with ease using the Factory Pattern, making your code more maintainable, scalable, and organized. Whether you're a beginner or an experienced Java developer, this video is packed with valuable insights that will take your coding skills to the next level.
#designpatterns #softwareengineer #developer
Link to code in GitHub: github.com/sean-campbelltech/...
Visit our website: campbelltech.io/
Checkout our Udemy courses: www.udemy.com/user/sean-campb...

[@manikandan027]

Excellent Explantion with example

[@campbelltech]

Thank you for the awesome feedback.

[@javarj6650]

Thanks

[@campbelltech]

You're welcome

[@dsoto63301]

My problem with all of these implementations is that they always use a switch to control the class to create... To me it violates the OC principle, and you can end up with a 1000+lines method... No mention the different dependencies each implementation may have. Could you think of other ways to solve it in java without a switch? (Reflection, maybe)

[@campbelltech]

Hey Daniel, thanks for your comment. Firstly, I agree with you that a switch or if statement in a separate class still looks like nested code at first glance. However, the alternative seems to be nested if-else statements with logic inside each condition, often in a single class. I've seen this too often in the 17 years that I have worked as a Software Engineer at multiple companies.
The factory method pattern makes these statements:
1.) You still need a condition to determine which logic to invoke,
2.) But, the logic is decoupled into separate classes. The switch merely decides which implementation of an interface rather than having nested code in one place
3.) It is also centralized and not repeated every time your code needs to decide which payment option for example.
In terms of the dependencies concern, check out our other video on how to make a factory method injectable:
th-cam.com/video/WNzjz0v0t7o/w-d-xo.html

[@campbelltech]

You could use reflection yes. You could create an annotation called @FactoryMethod and then use reflection to auto-detect which classes implement a certain interface, or extends a certain abstract class :-) In this way, you could have abstract logic that generates a factory method in runtime, rather than having that switch visible in compile time. If you create such an annotation and it goes open-source, remember to reference campbelltech :-) We could collaborate on such a project.

[@waynefaustorilla]

I agree. It also violates the Single Responsibility Principle as one class (PaymentFactory) is being used for 3 responsibilities (Credit Card, Paypal, and Google Pay). Wouldn't it be better to make different Factories for different payment types (CreditCardPaymentFactory, PaypalPaymentFactory, GooglePaymentFactory)?

[@kamalam29]

@@waynefaustorilla then that switch / nested if-else statement would be transferred to the client code. you have to make a decision, however.