Great video. Your channel is superb. Just one request, please make the code legible for mobile screens. I usually watch these kind of videos on mobile when I am taking a break or something. I am sure there are others who prefer mobile as well.
whoah, your implementation of say() and use of say.call() made me realize things that I guess I already knew but didn't understand the practical uses of. I'm really looking forward to watching the rest of these design pattern videos, fantastic work!
@@DevSage Why aren't you passing it in as a param? I feel like that gives you more of an overview of what the function does. Well.. maybe not in this example but I think you get what I mean right
A long time ago back in school there was actually 2 competing sides and this was 1 of them, but I think eventually no one does it anymore. I dont know anyone who does this now lol
I’m just getting started with modern JS after working with Drupal & PHP for the past three years without an understanding of any design patterns, so I’ve gotta day I’m stoked on your series here. Thank you for putting this out there!
Thanks alot dude, I was looking all over the internet for a simple demonstation of how to use Factory Patterns and your video was it. Be blessed man. 😁
No words to describe this video other than simple, concise and straight to the point. The simplicity in your way to explain code makes it entertaining for those who, like me, are taking their first steps into the development world. Awesome video!
Awesome video! Very easy to follow and I actually feel like I understand the factory pattern now. A follow up describing the best use cases for the factory design pattern would be great also! Keep up the good work!
Good video and I also enjoyed your video on building a library. One thing to note: you shouldn't need a break statement if you're returning a value. Sub'd and looking forward to more videos.
This is very confusing... The create method must be static, and the type must be of type enum, a map or similar. Finally, the call method will add an insult to the injury... It must be part of a parent class. And, why you are not using the class keyword to create objects?
Great tutorial! You should look into a pop filter so your P's and B's don't make such a loud wind-like sound. Just a suggestion, keep up the super helpful stuff! :)
So, what's wrong with just employees.push(new Developer('Patrick')), employees.push(new Tester('Mike'))? I don't get what problem exactly this pattern solves because, in my opinion, it do exactly the opposite and create more problems because you have to keep in mind type constants. Every time you want to create new object, you have to check your factory method and find needed type.
hey dev thank you for this - also as a side point in the above example - there's a boundless array being populated right ? with like in each Element will be [{"Patrick" ,"Developer"}],[{"John","Tester"}] is that how the outputted array will look ?
I don't see how this helps though. The only thing it did was to obfuscate what type of employee you created. No one is going to remember if they need type 1, 2, 3, 4, 5, 6, 7, etc.
Yes, using numbers would get a little confusing. This pattern is more useful when you're using a strongly typed language like TypeScript where you could make use of enums instead of raw numbers.
I love your way of teaching, here I have tried factory pattern in a functional way. const baseData = (name, type) => { return { name, type }; }; const factory = (name, type) => { switch (type) { case "Developer": return baseData(name, type); case "Tester": return baseData(name, type); } }; const instnace = factory("Aashir", "Developer"); console.log("instance: ", instnace); Please let me know if you found anything wrong with it, Thanks :)
This does not scale. For instance, if more unique properties are added to either employee type, they would need to be passed into the factory, which is just too much redundant code. Much better to have an object for each employee type that can be expanded upon.
Just learning Javascript so I'm probably missing something but you are talking about objects in this but it seems to me you are using functions. Except as far as I know "this" is usually used with objects so yeah. Just a bit confused.
Great video. Your channel is superb. Just one request, please make the code legible for mobile screens. I usually watch these kind of videos on mobile when I am taking a break or something. I am sure there are others who prefer mobile as well.
Hey, @DevSage, could you please provide reference to the defintion of the "Factory Pattern" you presented in the video? The classic Gang of Four Patterns LIst doesn't contain "Factory", it contains "Abstract Factory" and "Factory Method", your solution doesn't match any of them. So, have you invented the new one? Sorry for the question, but a lot of developers could be confused and fail the interview just due to the misunderstanding in terms and definitions ...
Yes, this is not clean factory pattern. In this example factory has dependency on Developer and Tester. Actually EmployeeFactory have to be abstract class and we need two subclass like DeveloperFactory and TesterFactory. So abstract factory class not depends on concrete Developer or Tester implementation. And we can easy add another class like Designer, and create DesignerFactory implementation of abstract factory class. So our code is open to extension and close to modification. In the video example factory is not close to modification and open for extension. And also Factory need some additional logic(interface) inside factory itself. Otherwise it useless.We can add some methods to Factory like, work() and each class Designer Developer and Tester will works, but in they way.
You could certainly do that, yes. That might actually be an easier way to do it. I just wanted to make sure the general idea of the pattern is understood
A class is a factory, typeof anything "new" is "object", typeof Object is "function" because it's constructed via function, meaning it's made by a factory. Welcome to javascript ladies and gentlemen.
Because you have a centralized factory for a type of objects. If you for instance get a json with multiple employees you can then just call employeeFactory.create(name, type) instead of implementing the switch for everytime you import data. And if you change Developer to take (name, salary) you just have to change it in one place. As soon as multiple devs work on it, its easier to have one reference then to dig trough everyones code if they called new Developer(n), as an example.
@@benjaminbaer5485 honestly your examples made the penny drop for me. i feel a lot of design pattern explanations (or maybe even tech explanations in general) focus only on how to do the thing but not what the benefits are when compared to other solutions.
I think this breaks the OCP It would be better to create an EmployeeFactory that returns a EmployeeType object in the then let the EmployeeType Class handle how users are created, that way you only have to modify the Employee Types not the Employee Factory
Yes. The functions used here are Constructor Functions. In JavaScript Factory Functions are regular functions. JavaScript is not an Object Oriented Programming language like Java but it supports OOP. Some programmers do not like using Constructor Functions in JavaScript because of how the 'this' keyword works and how it's reference changes depending on the program. Below is an example of how we could rewrite the code using Factory Functions : function developer(name) { let newDev = { } newDev.name = name; newDev.type = "Developer"; return newDev; } function tester(name) { let newTester = { } newTester.name = name; newTester.type = "Tester"; return newTester; } function employee( ) { const create = (name, type) => { switch(type) { case 1: return developer(name); case 2: return tester(name); } } const say = ( obj ) => { console.log(" Hi I am " +obj.name+ "and I am " +obj.type); } return { create, say }; } const emp = employee( ); const employees = [ ]; employees.push( emp.create("Patrick", 1) ); employees.push( emp.create("John", 2) ); employees.forEach( ( obj ) => { emp.say(obj) }); Apart from this, I think the explanation in the video is pretty good!
This is call Constructor Pattern not Factory Pattern Please correct this The Constructor Pattern The Module Pattern The Revealing Module Pattern The Singleton Pattern The Observer Pattern The Mediator Pattern The Prototype Pattern The Command Pattern The Facade Pattern The Factory Pattern The Mixin Pattern The Decorator Pattern Flyweight
@@DevSage The concept is rather simple. So the use cases would be a good addition. The use cases may be something what makes the material a bit different from tones of pattern tutorials on RUclips
📕"Design Patterns Explained Simply" Ebook: payhip.com/b/MLtJ
🤖 GitHub: github.com/pkellz/devsage/blob/master/DesignPatterns/FactoryDesignPattern.js
💙 Twitter: twitter.com/realDevSage
📙 Ebooks: payhip.com/devsage
💥 Discord: discord.gg/BP8wPv6raA
Great video. Your channel is superb. Just one request, please make the code legible for mobile screens. I usually watch these kind of videos on mobile when I am taking a break or something. I am sure there are others who prefer mobile as well.
I'm glad it helped you!
I'm just getting into software patterns as a junior developer and concise nature of these videos are amazing. thank you.
Hi, your comment is over 5 years ago, I just want to know how are you know in your career? Thank you.
whoah, your implementation of say() and use of say.call() made me realize things that I guess I already knew but didn't understand the practical uses of. I'm really looking forward to watching the rest of these design pattern videos, fantastic work!
Appreciate you
@@DevSage Why aren't you passing it in as a param? I feel like that gives you more of an overview of what the function does. Well.. maybe not in this example but I think you get what I mean right
@@onlyme0349 I suppose either way could work
My BROTHA you don’t know how happy I am to find these videos. Keep up the great work. 👌🏾
💪🏾💪🏾💪🏾
His way of writing curly brackets is driving me crazy.
It's probably because of his Java background (or C, or C++).
Taht's how its done in C#, I find it very elegant and its easier to read
I came to the comment section to find this comment xD
I think I used to see or do this when I was working with java/c#. And probably the ides would format it that way
A long time ago back in school there was actually 2 competing sides and this was 1 of them, but I think eventually no one does it anymore. I dont know anyone who does this now lol
I’m just getting started with modern JS after working with Drupal & PHP for the past three years without an understanding of any design patterns, so I’ve gotta day I’m stoked on your series here. Thank you for putting this out there!
Damn, underrated channel. Thanks for all this!
Thanks alot dude, I was looking all over the internet for a simple demonstation of how to use Factory Patterns and your video was it. Be blessed man. 😁
No words to describe this video other than simple, concise and straight to the point. The simplicity in your way to explain code makes it entertaining for those who, like me, are taking their first steps into the development world. Awesome video!
Glad I could help! 😁
This is the best explanation of design patterns I have ever seen. Thanks!
I am so glad I found your channel bro! Your channel full of gems. Love and blessings from South Africa
Appreciate it. Nice to meet you 😁
to be honest: you by far have the best vids. keep them coming please!!
Nice way about your explanations. Great tone of voice and such too. Very calming 😌
this was so good !! I'm starting to see how this important especially as a junior developer on the job hunt !
This is great.
Short but affective.
Thank you very much.
You're welcome!
You should also add when NOT to use this pattern & common gotchas. Every pattern has its pros & cons. Nice video btw :) Thanks!
The video and explanation are very comprehensive and easy to follow. Thank you!
Your delivery is outstanding. Much appreciated
Thanks!
Awesome video! Very easy to follow and I actually feel like I understand the factory pattern now. A follow up describing the best use cases for the factory design pattern would be great also! Keep up the good work!
I appreciate you
great video, I read this concept from a book and the video helps me to get the point very well.
Awesome introductory video!
Good shit even tho it was 3 year ago. Learnt something new, easy and fast. Thank you
Thank you explaining this in such a simple way
hello bud... you just made things click for me in a huge way. wow. thank you
Glad I could help
why you didn't put the semicolon at the end of code?
Didn't feel like it
Good video and I also enjoyed your video on building a library. One thing to note: you shouldn't need a break statement if you're returning a value. Sub'd and looking forward to more videos.
You're right. Never noticed that until now haha. Thanks for the sub
This is very confusing... The create method must be static, and the type must be of type enum, a map or similar. Finally, the call method will add an insult to the injury... It must be part of a parent class. And, why you are not using the class keyword to create objects?
Man you just explain it so easily same with your recursion video kudos to you 👌😎😎
Thanks 👍🏽
Great tutorial! You should look into a pop filter so your P's and B's don't make such a loud wind-like sound. Just a suggestion, keep up the super helpful stuff! :)
Gang of four was just giving me headache...Thanks man
So, what's wrong with just employees.push(new Developer('Patrick')), employees.push(new Tester('Mike'))? I don't get what problem exactly this pattern solves because, in my opinion, it do exactly the opposite and create more problems because you have to keep in mind type constants. Every time you want to create new object, you have to check your factory method and find needed type.
Also, every time when you are reading the code, you probably don't know what that numbers is
hey dev thank you for this - also as a side point in the above example - there's a boundless array being populated right ? with like in each Element will be [{"Patrick" ,"Developer"}],[{"John","Tester"}] is that how the outputted array will look ?
I find your lack of default case in your switch statement disturbing
So that means Abstract Factory is when we don’t want to modify the values from outside the function using object creation?
why does an instance of the factory function need to be created? Would you not be able to create employees directly from the factory function itself?
I guess you don't actually need the factory function. Yeah you could return employees from the factory itself
@@DevSage ok. What's the benefit of the instance of the factory function then? Just curious as I'm a beginner with JS 😛
How is this entire thing better than just using new Developer(“Patrick”)? Seems way more concise to me.
Fantastic! A simple yet very easy to understand explanation! Thank you =D Please make more videos on more design patterns =)
I appreciate it
Could you have used Class syntax for this instead?
Great video. What is the advantage of using this pattern instead of a Class? It seems to do the same with a good quality code as well.
I don't think he realised he had to answer this question! Lol.
@@rutwickgangurde3247 yeah, it's not a rhetorical question, haha
I really hope this gets answered as I'm wondering why he doesn't create classes for the developers and testers instead of functions
this video was very helpful to understand factory design pattern
Glad it was helpful!
Great! Very instructive material! Thanks a lot!
Appreciate you! Know of any projects or step by step walkthroughs to help a person practice this?
I don't see how this helps though. The only thing it did was to obfuscate what type of employee you created.
No one is going to remember if they need type 1, 2, 3, 4, 5, 6, 7, etc.
Yes, using numbers would get a little confusing. This pattern is more useful when you're using a strongly typed language like TypeScript where you could make use of enums instead of raw numbers.
I think the 'break' statement inside the switch cases is irrelevant because you have a return statement which also exists the switch.
You are correct
I love your way of teaching, here I have tried factory pattern in a functional way.
const baseData = (name, type) => {
return { name, type };
};
const factory = (name, type) => {
switch (type) {
case "Developer":
return baseData(name, type);
case "Tester":
return baseData(name, type);
}
};
const instnace = factory("Aashir", "Developer");
console.log("instance: ", instnace);
Please let me know if you found anything wrong with it, Thanks :)
This does not scale. For instance, if more unique properties are added to either employee type, they would need to be passed into the factory, which is just too much redundant code. Much better to have an object for each employee type that can be expanded upon.
Also your switch does literally nothing lol. Hopefully after 2 years you figured this all out on your own though.
Just learning Javascript so I'm probably missing something but you are talking about objects in this but it seems to me you are using functions. Except as far as I know "this" is usually used with objects so yeah. Just a bit confused.
Thanks brother. very clear presentation.
You're welcome
This is very helpful. Thank you!
You're welcome!
You do not need a break if you return from each case in switch, right?
You are right.
No need to have break in the switch because it'a inside a function and there is a "return"...But it's a very good good video👏🏾
Correct! And thank you!
So this remind me when teacher explained me OOP concepts , the Developer and other entities are called Model or "Pojo" in java.
nice explanation, thanks!
thanks for posting ~ great explanation
Glad you enjoyed it!
Saw... Liked... Subscribed
Great video. Your channel is superb. Just one request, please make the code legible for mobile screens. I usually watch these kind of videos on mobile when I am taking a break or something. I am sure there are others who prefer mobile as well.
Is really factory method often used in real time applications?
Yes!
clean and neat thanks for great content
Thanks for watching!
thanks for the tips and explanation
which javascript books and course have help you the most
Hey, @DevSage, could you please provide reference to the defintion of the "Factory Pattern" you presented in the video?
The classic Gang of Four Patterns LIst doesn't contain "Factory", it contains "Abstract Factory" and "Factory Method", your solution doesn't match any of them.
So, have you invented the new one?
Sorry for the question, but a lot of developers could be confused and fail the interview just due to the misunderstanding in terms and definitions ...
Yes, this is not clean factory pattern. In this example factory has dependency on Developer and Tester. Actually EmployeeFactory have to be abstract class and we need two subclass like DeveloperFactory and TesterFactory. So abstract factory class not depends on concrete Developer or Tester implementation. And we can easy add another class like Designer, and create DesignerFactory implementation of abstract factory class. So our code is open to extension and close to modification. In the video example factory is not close to modification and open for extension. And also Factory need some additional logic(interface) inside factory itself. Otherwise it useless.We can add some methods to Factory like, work() and each class Designer Developer and Tester will works, but in they way.
Amazing video. Would it not be better to define EmployeFactory as an object with a method called "create"?
You could certainly do that, yes. That might actually be an easier way to do it. I just wanted to make sure the general idea of the pattern is understood
i dont understand the need of EmployeeFactory and inner create function. can't we have createEmployee function ?
A class is a factory, typeof anything "new" is "object", typeof Object is "function" because it's constructed via function, meaning it's made by a factory.
Welcome to javascript ladies and gentlemen.
EmplopyeeFactory is declared as a function ,but being called just like a constructor using new EmployeeFactory().slightly confused with this.
It's very similar to Redux Action creators and Reducers, right?
A flaw here is that you case types are not communicative in your code. You should be able to pass in 'tester' or 'developer'
I LOVED THAT.
Glad you liked it!
Great video. Thanks man :D
Thanks!!
Do you can recommend me a book about this content ?
www.dofactory.com/javascript/design-patterns
addyosmani.com/resources/essentialjsdesignpatterns/book/
DevSage thanks, great playlist.
when you return in switch, you don't need to break.
Thanks this is great stuff
Glad you like it
Well explained
Excellent
Vau it is around 6 month i am working with redux state management.I didnt know that i was using Factory pattern :)
There has to be a better example use case of factory patterns than this. This just made the code much less readable for no benefit.
Hey, i have noticed it's similar to C programming way of creating function .....
I'm not sure how it's better than just "employees.push(new Developer('Patrick'))
Maybe it's just good to practice structured code?
Hmn i don't like over complicating for the sake of it, it would be nice to see some situations where the benefits of this structure can be seen
@@omirrrr True, tbh I'm just starting into design patterns because I just had a job interview where they asked me about them, so I'm not sure either.
Because you have a centralized factory for a type of objects.
If you for instance get a json with multiple employees you can then just call employeeFactory.create(name, type) instead of implementing the switch for everytime you import data.
And if you change Developer to take (name, salary) you just have to change it in one place.
As soon as multiple devs work on it, its easier to have one reference then to dig trough everyones code if they called new Developer(n), as an example.
@@benjaminbaer5485 honestly your examples made the penny drop for me. i feel a lot of design pattern explanations (or maybe even tech explanations in general) focus only on how to do the thing but not what the benefits are when compared to other solutions.
no need brake after return
Couldnt you just write say(emp) instead of say.call(emp)?
“This” inside say would refer to the window object. Using call or apply would pass in what “this” you are implying
Understand well 💗
I think this breaks the OCP It would be better to create an EmployeeFactory that returns a EmployeeType object in the then let the EmployeeType Class handle how users are created, that way you only have to modify the Employee Types not the Employee Factory
Best for building many types and many objects
Factory an object that manufactues many objects
JS factory functions are not used with a keyword "new"...
Explain it to me
Yes. The functions used here are Constructor Functions. In JavaScript Factory Functions are regular functions. JavaScript is not an Object Oriented Programming language like Java but it supports OOP. Some programmers do not like using Constructor Functions in JavaScript because of how the 'this' keyword works and how it's reference changes depending on the program.
Below is an example of how we could rewrite the code using Factory Functions :
function developer(name) {
let newDev = { }
newDev.name = name;
newDev.type = "Developer";
return newDev;
}
function tester(name) {
let newTester = { }
newTester.name = name;
newTester.type = "Tester";
return newTester;
}
function employee( ) {
const create = (name, type) => {
switch(type) {
case 1:
return developer(name);
case 2:
return tester(name);
}
}
const say = ( obj ) => {
console.log(" Hi I am " +obj.name+ "and I am " +obj.type);
}
return {
create, say
};
}
const emp = employee( );
const employees = [ ];
employees.push( emp.create("Patrick", 1) );
employees.push( emp.create("John", 2) );
employees.forEach( ( obj ) => {
emp.say(obj)
});
Apart from this, I think the explanation in the video is pretty good!
thanks
You're welcome!
return and break. there is no need to break gain
You're right!
Thank you
great way to describe it, i sub'd!
Thank you 😊
Isn't it the strategy pattern?
No the strategy pattern is this -> ruclips.net/video/SicL4fYCz8w/видео.html
This is call Constructor Pattern not Factory Pattern Please correct this
The Constructor Pattern
The Module Pattern
The Revealing Module Pattern
The Singleton Pattern
The Observer Pattern
The Mediator Pattern
The Prototype Pattern
The Command Pattern
The Facade Pattern
The Factory Pattern
The Mixin Pattern
The Decorator Pattern
Flyweight
Cosnts... the special case mutables
Isn’t it a constructor pattern?
It's a creational pattern
Didn't worked :(
nice!
Thanks!
👏
Great
bro do you have another channel? Cause ya voice sounds like Computer Science channel lol
Haha well no that's not my channel. But after going to that channel and listening for myself I can see/hear EXACTLY what you mean lol
thanks bro
You're welcome!
Ya bro how are you
I'm doing good man. How about you?
Very strange design pattern. Interesting though.
There's not much value in that video without comprehensive explanation of the use cases
Depends on how much you already know about factories
@@DevSage The concept is rather simple. So the use cases would be a good addition. The use cases may be something what makes the material a bit different from tones of pattern tutorials on RUclips