Factory Method Pattern for LLD Interviews | BLR Traffic <?-> Dating Apps Example

Factory Method Pattern for LLD Interviews | BLR Traffic <-> Dating Apps Example

? Now that I have your attention, if you're preparing for LLD interviews, read further to solidify your understanding of FACTORY METHOD design pattern with two examples 1 - related to Blr traffic, 2 - related to Dating Apps.

No alt text provided for this image

? Broadly speaking, design patterns fall into 3 categories:

  • Creating Objects
  • Structuring the files in your codebase.
  • Making these Objects/classes, interact with each other.

Factory Method pattern falls under Creating Objects category.

? Example - 1: Bangalore Traffic Example -

No alt text provided for this image

?? Requirement:

  • Hypothetically speaking, suppose I'm about to design an application which helps me book a means of transport in Bangalore from my home till office.
  • I want to ensure that this application attempts bookings ACROSS - Uber, Ola, Rapido, QuickRide etc.

?? Observation:

  • Now while designing your software, you should try to have separate classes for CREATING these objects (example : creating UberService / OlaService objects) and OPERATING on these objects (example : UberService.bookCab() etc.)
  • This should be done in order to honour the Single Responsibility Principle.
  • The Ola app object / Uber app object may have different inputs for getting created and while designing a software we should abstract away this behaviour from the place where this object is going to be used.
  • The Factory Method separates product construction code from the code that actually uses the product. Therefore it’s easier to extend the product construction code independently from the rest of the code.

You just got a chance to bring in abstraction at the level of CREATING these Uber / Ola / Rapido objects for client usage. So basically, this design pattern wants to abstract away from the client-code, as-to HOW a particular object is created and HOW it's used.

That my friend, is Factory Method Pattern.

Don't worry if you did not understand it well yet. Let's take one more shot at it.

? Example - 2 : Tinder/Bumble for getting a prospective date!

No alt text provided for this image


?? Requirement:

  • Hypothetically speaking, suppose you're designing a software that brings its users prospective matches from all of Tinder / Bumble / <insert-other-dating-apps-here>.

?? Observation:

  • As a client, you just care about getting a relevant-good match for your users. You don't care about how this custom software of yours created the app instance for Bumble / Tinder (as both may require different set of inputs from the user) and then how it fetched matches from these apps.
  • That's a chance to abstract away from the client-code (ie. you), HOW a particular application (tinder / bumble) got instantiated from HOW the match came your way.
  • Hence using Factory Method Pattern, we would be separating HOW an application object is created from HOW it fetches the matches for us.

?? The Factory Method separates product construction code from the code that actually uses the product. Therefore it’s easier to extend the product construction code independently from the rest of the code.

?? Hopefully the above example gave some insight into WHEN/WHY to use FACTORY method pattern.

?? If you've made it this far, pat your back! Let's delve deeper into the class design for this pattern.

No alt text provided for this image

1 - DatingApp interface - this just contains a skeleton of what features of the dating application you want to expose to the client.

2 - Concrete Implementations of above interface - These would have CUSTOM logic of curating matches for folks on Tinder / Bumble by implementing the getMatches() method.

3 - DatingAppCreator - This class declares the factory method (createApp()) that returns new DatingApp objects. Important to note, that return type for the createApp() method needs to be DatingApp.

  • By declaring this factory method as abstract, we would enforce that all new concrete types of dating applications would implement this createApp() method for themselves.

4 - TinderAppCreator/BumbleAppCreator - This class, overrides the base factory method (createApp()) to return a different type of DatingApp (TinderApp or BumbleApp) or any other app that you end up searching for matches on, tomorrow!

?? Now that we have written the code responsible for creating different kinds of dating applications, let's see how you'd invoke them in the client code.

?? In the main client code, you could just do :

No alt text provided for this image

?? Benefits:

  1. You avoid tight coupling between the creator and the concrete products.
  2. Single Responsibility Principle. You can move the application creation code into one place in the program, making the code easier to support.
  3. Open/Closed Principle. You can introduce new types of dating-apps into the program without breaking existing client code.

?? When to use:

  1. Use the Factory Method when you don’t know beforehand the exact types and dependencies of the objects your code should work with.
  2. Use the Factory Method when you want to provide users of your library or framework with a way to extend its internal components.

???Remember the above points in your next interview. The interviewer would be like below:

No alt text provided for this image

?? This is my first attempt at sharing an article on a design pattern. Please excuse me for mistakes and more importantly if any feel free to correct me in comments / DMs.

?? Your like / comment / share would by-default motivate me for further articles on other patterns and multi-threading!

???Godspeed!

No alt text provided for this image
Surinder Kumar Mehra

Principal Engineer at Arcesium

2 年

I mainly see two approaches of factory on various blogs., 1. Have static factory method with switch case to return DatingApp with identifier(most blogs mention this) https://www.digitalocean.com/community/tutorials/factory-design-pattern-in-java 2. This post , few blogs mention this. Clearly 2nd is trying to avoid if else and future modifications to factory class when new Dating App is added, but I still like the first one because it makes client code free of implementation details and responsibilities of creating concrete classes. Another question, if client has to create concrete factory for each new DatingApp added, that's double the amount of files added Also, why not just create datingApp instance directly from client code instead of creating an instance of factory and asking it to create DatingApp instance(it's like not using factory at all because the client has to deal with creation of concrete implementations )

Pratyush Prateek

SDE-2 at Atlassian | Ex-Microsoft

2 年

The examples are pretty nice ! Now, people might be more excited about using this pattern rather than going out on a date ??

Kunal Singhal

SWE @Google | Candidate Master at Codeforces | NSIT CSE '23

2 年

Loved the article.

Vaibhav More

Versatile Professional: Solution Architect | Technical Lead | Project Manager | Fullstack Specialist in Java, JavaScript, Microservices, and Cloud

2 年

Sounds interesting. Giving it a shot Nikhil Srivastava

要查看或添加评论,请登录

Nikhil Srivastava的更多文章

  • Apache KAFKA Connect 101 - Part (1/2)

    Apache KAFKA Connect 101 - Part (1/2)

    ?? Learning outcomes from this article: ? Typical Kafka Usage with Producer and Consumer Clients: ? Kafka Connect 101:…

  • Gentle Intro to Data Streaming Landscape

    Gentle Intro to Data Streaming Landscape

    Learning outcomes from this article: What is stream computing and why should YOU learn about it? Typical streaming…

  • Design of Real Time Analytics for 69x Price Hike in Uber !

    Design of Real Time Analytics for 69x Price Hike in Uber !

    ?? We'll explore the engineering design philosophy behind features like: ?? The 69x surge-pricing while booking Uber…

    7 条评论
  • Kafka Replication Protocol

    Kafka Replication Protocol

    In this article, I'm going to explain you the Kafka Data Replication Protocol with a very simple example. [?] Learning…

    9 条评论
  • ZERO to HERO in 5 minutes in Apache KAFKA

    ZERO to HERO in 5 minutes in Apache KAFKA

    [?] Learning Outcomes From this article: ?? Introduction to Kafka via Bangalore Traffic Analogy ?? Producers…

    9 条评论
  • Ripping apart the Kafka Broker Architecture !!

    Ripping apart the Kafka Broker Architecture !!

    ?? Just like you, even I love distributed systems. Apache Kafka is such a beautifully designed distributed system that,…

    11 条评论
  • Damn, Threads in web server too !!

    Damn, Threads in web server too !!

    ?? Chronological learning outcomes from this article. Important low level and high level details about the functioning…

    17 条评论
  • Ditch Multi-Threading !! Learn CPU and memory architecture first

    Ditch Multi-Threading !! Learn CPU and memory architecture first

    ?? Don't risk your concurrency interviews without having good grasp on fundamentals. Read further and become a better…

    14 条评论
  • Kubernetes-101 as a noob, from a noob, like a noob !!

    Kubernetes-101 as a noob, from a noob, like a noob !!

    ?? My intention with this article is to help you form some intuition about Kubernetes, Containers, VMs etc. So that you…

    14 条评论

社区洞察

其他会员也浏览了