For me as a data scientist your videos really stepped up my software development game. The Factor Pattern together with having abstract classes as interfaces is something I immediately applied in my current project. This is not something you typically learn in data science courses, even though I think this is crucial when willing to write code in a professional context. Thanks Arjan for sharing those valuable insights!
Totally agree. Although Arjan is working in Python, much of the design discussion applies to any language. The OOP and pattern concepts discussed are easily used in other languages (well, okay SOME details aren't perfectly portable, but most)
I'm binging your videos currently and (among other things) there's something I love: the examples are meaningful. They are practical, solve actual problems. Not your another off the mill tutorial with generic class C inheriting class B etc. Seeing that your example applications mimic actually doing something, makes it 100x easier to wrap the application logic and focus on the topic at hand. I'm amazed.
I just found out about you today while learning certain design patterns. Now, I started reading about factory patterns just a few hours ago and boom, you're here with the video. Thanks for the video. Maybe adapter pattern in the next video?
Unsure if this is mentioned somewhere, but this is the GOF Abstract Factory pattern. Not to be confused with the GOF Factory Method pattern. The Abstract Factory pattern's goal is, as Arjan says, for grouping different class instantiations together. The Factory Method pattern is about extending the functionality of a class.
To be more specific, Factory Method pattern delegates object instantiation to the sub-classes and makes rest of the code dependant on an interface or an abstract class
At 9:53 when you do the dict trick. The value is an Instance of each object type due to the () at the end right? Does that mean this is bad if you have many factories which take up memory and you instantiate them all. Is it better to leave the value instantiated then instantiate once it returns?
I really like the idea where you first present the problem and show the solution. Most videos I watched rant about the theory but forgets to tell you the why part.
Thank you your videos, I understood the design patterns. I implemented it in my current project initially I thought it was lot of work but I persisted and wrote classes for them. I had a requirement to change the data source from DB to file. Some I had implemented it as classes, it was easier me for replacing the spice without impacting the code ! It was a life and a time saver. Thank you ! Please keep sharing such quality content. I’m sure it must be helpful for a lot of folks!
9:29 doesn't this make the factories dict eagerly instantiate all these object at once? (regardless if they are being used or not) I am not sure what's the correct way to do it, but if i had to write it this way i would: factories = { "low": FastExporter, "high": HighQualityExporter, "master": MasterQualityExporter } and then: factories[export_quality]()
Nothing wrong with this, but seeing that the factories are pretty small it's not a big deal. In a lot of real-world examples, you'll also need to send some arguments into the creation of those factories, so you can't just store the class, you'd have to store a function that returns an instance. Funnily enough, you're essentially storing a factory of the factory. In the end, it's usually just simpler to instantiate them right away. The objects are probably short-lived.
My thoughts exactly, but I'm more of a cpp guy, so I'm eager to hear what the pythonic way is. Also, repeated calls may create new and new instances. (do they?) That could be solved by moving the map out of the function to the module level I guess. (And thanks for the nice vid.)
@@CrapE_DM The shown variant using it's class name and creation on demand is indeed a much cleaner version. I would use factories.get(key) to handle non-existent keys/requests gracefully. You'll use factories in larger projects containing multiple different services. How do you want to estimate the life span of an object or service, outside of your own context? You'll probably have no information about complexicity, startup, resources of such a service by instance creation. Projects grow in real world, sometimes really fast. So at this stage, creating objects might become bigger issue than you might expect. (Think about db connections, service/event registration etc pp) Passing additional information via *args or **kwargs is simple.
Yes it does instantiate them all and always discards the majority of them unused. And yes your code is the correct way of implementing this. Likely just an oversight.
@Andrew Ramshaw Hey Andrew, I think you misunderstood or mispelled sth. The factory method is a method (!) pattern and only encapsulated in a class at c#, java etc. because of their' OOP. You'll see that a factory method is always static, there will be never an instance of the factory itself - as this would'nt make any sense. Like a factory, the method creates suitable products according to specified parameters or configurations. At this point there is no dependency on parents or side effects, just a dependency on a common (abstract or interface) type per factory method. Do not mix multiple thoughts into a pattern, as one pattern (usually) addresses only one challenge.
I so enjoy your presentation and delivery. Great job in explaining "why" things are used and not just the typical "how" (which is what geeks who already grokk something tend to do). I also like how you discuss what things a pattern doesn't do well and then you provide an alternative for such cases. ⭐⭐⭐
I have been watching all your videos over the last week. I am glad I have reached a point where as soon as you started explaining the factory pattern for decoupling the main(), I thought that this would eventually lead back to dependency injection.
I really enjoyed the video. Your pacing and amount of content is very good as a reference! In a future video, could you clarify the differences between a Factory Pattern and a Builder Pattern? I feel like the builder is a way to collect factories, but I would enjoy seeing a worked example.
Amazing video! One SUPER small item I saw in read_explorer() is that export_quality is using in to check against the available factories. Using: if factories.get(export_quality) will not iterate through the dictionary but directly see if that key is available. Considering how few factories are available, this would never get noticed. I recently found your channel and binged a few videos already :) Subscribed!! Can't wait for more.
Just providing a real world example here. I just solved an issue that I had where I needed to provide an implementation of an output port based on a given value with the factory pattern. In this case it was a Payment Processing Service and the code quality and maintainability was quite good with the implementation of the factory pattern, which comes super handy since Payment Processing Services are always likely to require updates or new integrations in the future. Thanks for the video, super useful as always!
Design patterns are useful for giving common solutions a name, but I find that the 'standard' implementations often don't make for Pythonic code. In Java you need all these classes to satisfy the 'compiler', but thanks to Python's dynamic nature you can achieve the same with much less code. For example, a function get_exporters(quality: str) -> Tuple[VideoExporter, AudioExporter] would do the same, but in ~5 lines instead of ~30, and would be much easier to understand, while still removing the coupling. Add to that that classes are usually moved to separate files, and it becomes really hard to get an overview of the application without diagrams. There's a nice talk about this that motivates it better than I could: Stop writing classes. Though considering the intended audience is Python beginners and intermediates, I understand the focus on explaining the design patterns as they normally appear. Another section 'making it Pythonic' would be nice, but I guess that could get too complex for beginners.
I mostly agree with this, though classes are not completely useless. If for example you want to add some settings to a factory that influence how the instances are created, then a class is a good solution because it combines data with behavior. I'm using classes in most of my examples when explaining these design patterns to not make it too confusing for the viewers, but I'm seriously thinking about following up with a series where I try to reimagine these patterns, but then using more Pythonic features instead and see how that holds up.
No, not really. I guess you think that because you would have to add a new factory to the dict if violates the closed for modification principle. Open/Closed means you can modify the way a system works without modifying the code that already exists. You can extend the code and use it in different ways, but the old code is still in tact and doesn't need to be re-tested. The Factory Method pattern will create a different type of object based on specified parameters. Factory Method actually works well with the Open/Closed principle if done correctly. However, if you create a new class and then want the Factory Method to create a new object of that type you would have to change the Factory Method.
Really enjoy the video that talking about the design pattern in python, especially with a understandable example. Look forward to see more video with more difficult and useful pattern in python.
Might not be understanding correctly, but at 3:53 you mention that the main() function has weak/low cohesion because it is "doing a lot of things". Does that actually make it _low_ cohesion though since all of the video/audio functionality is within same area? I agree that this function has _high coupling_ with the other classes.
As Arjan mentioned if you have wide variety of combinations then I use a factory controller class which can generate the proper factories. It is not so complicated.
I would like to propose the use of a factory dictionary approach, where the dictionary values store class names instead of actual instances. This can be more efficient, especially when creating instances is resource-intensive. The idea is to define a dictionary of factories like this: factories = { 'one': FactoryOne, 'two': FactoryTwo } Later, when you need to create an instance based on a specific key, you can use the stored class names to instantiate the desired objects. This is done as follows: return factories[key]() With this approach, you optimize memory usage by storing class names, and actual instances are only created when needed.
Hey! First, thank you so much for your videos. I knew about patterns long time ago but never really understood how to put them in practice. I have a question about this... I don't see that much of a benefit. Basically what I see in this example is that the Factory pattern allows us to know about half the things we needed - before we needed to know about 3 video exporters and 3 audio exporters, now only 3 factories. But I still have to know about the factories. And yes, you can move that to a different function as you did with the read_exporter, but you could've also done the same without the factories and just have a dict with tuples, like `{"master": (LosslessVideoExporter(), WavAudioExporter()), ...}` What's the real benefit of this?
You only have to know the Abstract Factory "ExporterFactory" but not the 3 factories themselves. You can keep adding as many factories as you want as long as they implement ExporterFactory.
Im a bit confused about terms and concepts so any help is appreciated. 1) Is example from video an implementation of "Abstract factory" pattern? 2) Does such thing as "Factory pattern" exist? Or maybe its not a "pattern", but something else? Because i mostly find "Factory method" and "Abstract Factory" among patterns. Great video, btw! As always on this channel.
Function "read_exporter" initializes all exporters, which I think is bad. It is generally a bad idea to create a dict (or a list) containing instances instead of classes. WDYT?
For your factories object, why did you instantiate all 3 in the object? Would it not be better to instantiate on the return when the needed factory was pulled from the dict?
Great video on the Factory Pattern. My question is, doesn’t the read_exporter function violate OCP in SOLID as we’ll have to keep changing it to add more Exporters?
That's correct. I did this in this video to keep things simple. Optimally, you'd want a mechanism to be able to register these factories dynamically so that the code that uses them doesn't need to know which factories there are. I'm working on a video at the moment that addresses that particular issue.
Do you want to instantiate all those exporter objects in the low/high/master dictionary? Wouldn't it be better to instantiate only the one that is called?
Thank you for your videos. Content is amazing have a question: At 10:21 you defined read_exporter. But if we call read_exporter then it will create objects of all 3 classes from factories dict. Won't that be a memory wastage cause at the end we are going to use only one object? Please correct me if I am wrong.
Question: If the concrete classes require different parameters in the constructor, how can you implement this in the factories get_video/audio_exporter() methods?
Thanks god I learned English, my man. I'm Brazilian and the tutorials we find in Portuguese are nowhere near as good as this one (aka how to make a CRUD, make an Animals class and crap like that), I programmed everything on main() for years back when I was a teen simply because there's nothing about code designing in the Portuguese side of the internet.
Thank you for the video. I do have one suggestion though. When you mentioned about the cases where factory pattern is not possible, such as when the user decides on the different params to get their desired exporter, I would use the Builder design pattern.
What should I do if I need N objects that have the same methods, but each type of object has a different input args + partially some common properties?
Thanks for the video. Seems you shouldn't create all of available factory instances in the `factories` dict. Just remove brackets from dict (don't __call__ classes) and add call on return to create chosen class only
Instanciating the exporters in the dictionary is not alocating unecessary memory? I'm new in python so i don't really know, but if does, there is not a way to create the instances in execution time when necessary?
Why is the factory a class instead of a method? Also what's currently really missing on TH-cam is tutorials about compilers such as Nuitka and Pyinstaller, the whole professional side of shipping your code.
Bruh, there are literally thousands of tutorials in PyInstaller out there. They are not even compilers, they just package all you python modules and an python executable into an executable file. (Btw there is no "professional way of shipping your code".)
To your question why the factory is a class instead of a method (you mean function, don't you?): It's basically done to make it clear in the context of object oriented programming. The same functionality can be achieved by using functions (or even just dictionaries). In case of functions it makes the code less readable. That's it.
That's a nuclear cooling tower in you thumbnail, not a factory. Ha ha. Just feeding the algorithm. I like your series, it's very good!! and you speak well with an accent that makes you sound very intelligent.
Question: Why to use classes at all here? Why not just functions like "export_video(quality, path)",export_audio(quality,path)" and then use then just use them directly in the 'main'? In the above approach, you make an abstract factory, and a class for each of the combinations of qualities factories and then a separate class for each quality settings and an abstract class for them. Why is it a bad idea to just use a function instead all of this? If you need to group the video export and audio export together, you can just put them in another function. What am I missing here?
It’s not a bad idea at all to rely on more Pythonic mechanisms that achieve the same result with less code. In this video I wanted to stick to the traditional pattern (which relies on classes and inheritance). However, I did a follow-up video where I explored a few alternatives, see: th-cam.com/video/zGbPd4ZP39Y/w-d-xo.html.
Great Python content. Thank you very much for content like this. Do you mind a silly question: why the ExporterFactory.get_video_exporter & ExporterFactory.get_audio_exporter don't have the decoractor @abstractmethod like the class VideoExporter?
Het voelt alsof je veel meer code typt voor een niet veel beter eindresultaat. Wat is het voordeeld van het gebruik van een class voor elke soort exporter, inplaats van video- en audio-exporter in tuples te zetten, waarna je de tuples in een dictionary samenvoegt?
I am a bit confused. Usually factories are used to generate instance of similar object no ? But here we have to create a different factory per class ! (well one factory for two classes, but let's start simple with just a family of video codec) What is the use of it ? Each time I create a new VideoExporter I have to create it's dedicated factory. The only improvement I see, is that the switch has been located in a different function, not in the main anymore. And I still would have to rewrite this switch after adding a new codec. The difference is that we have a switch of factories instead of codec... great. Shouldn't we use metaclass and each class using the relevant metaclass being automatically referenced with its associated keyword in to the factory when it is created ? And thus according to this exemple, we would have only two factories, one for video, one for audio, able to return the instance matching the good codec from the relevant keyword, with auto handled switch !
3 ปีที่แล้ว
This reminds me of a plugin registration architecture. Is the plugin architecture related to the factory pattern?
Often, plugin systems rely on a factory-like pattern. Each plugin basically defines a concrete factory that provides instances specific to the plugin. Combine that with a factory registration method + dynamic script loading and you have the basics of a plugin architecture.
In your read_exporter function, you check if export_quality is in a set of possible quality options. Is there any reason why you use a set instead of a list?
But you could just map corresponding keys ("master", "fast", etc...) to tuples of audio and video exporter. This would reduce the overhead of having extra classes while keeping the same functionality. Am I missing something or could it really be substituted completely with ease(at least in this example)? What I mean: mapping = dict(master=(LosslessVideoExporter,WavAudioExporter), fast=(H264BPVideoExporter, AACAudioExporter), ...) I mean you have to map some kind of user interaction anyway. You even need that kind of dictionary anyway. What's the point having classes that neither store data nor compute anything (I mean, they do, but instancing an object is pretty trivial - using a separated method for this seems pretty bloated to me)?
Yes, you could probably also do this with tuples. I use a class here because that's how the Factory pattern is defined, so I prefer to stay close to the original pattern in order to avoid confusion. Another reason to use a class and not a tuple is that you might want to store data in the factory. For example, you could imagine that a Factory also stores some configuration settings or data that it needs to create the instances. This is exactly what classes are good at.
The goal of the factory pattern is to separate creation from use. If you can achieve that same thing with tuples or dicts and you don’t need class-specific features such as attributes, or dataclass behavior, then why not use that if it’s more convenient? The thing I’m concerned about is whether using typing will be as easy as with classes. I’m intrigued though by the idea. I might take up the challenge and do a video where I compare the two options.
Very high quality video. :) Subbed! I wanna see you use Starlette, which I love. :) Factory pattern with pydantic saves my life everyday when I am writing code. Factory pattern is also helpful, if you are trying to validate your types if you are doing graphql with something like ariadne.
Great content Arjan! Could you add a video on OOP for data science? I see a lot of code with tightly coupled functions that alter a single giant pandas dataframe. It would be nice to see you shine your light on that
A bit off topic. But I believe that prepare_export and do_export create an antipattern known as sequential coupling. Template method pattern should've been used here.
Not a fan of "get_...". When I get sth from the fridge I expect it to be there and after I got it to not be there anymore. Imho "create_audio/video_exporter" is far better. Alternatively "construct/build/etc" - whatever the domain language might be.
No worries and that's a valid point! Get and create indeed mean different things. This is a great example of Phil Karltons quote "There are only two hard things in Computer Science: cache invalidation and naming things." ;).
While the general Point being made here is ok, the example is not at all pythonic. Python isn't Java. You shouldn't create a factory class that has no constructor and no internal state. You can instead replace every instance of a subclass with a tuple (or a namedtuple if you are fancy) of two functions (in this example, one can even just use the constructors of the Exporters themselves.). Python3.6+ Type hinting even gives you a good way of telling the user (and IDE) what a function expects.
Also, what is the point of having "prepare_export" and "do_export"? Why not have simple functions like export_h264(data, directory)? I feel like OOP forces you to create unneeded abstractions.
@@ianliu88 There might be differences in how you want to handle the result. You might want to save it to disk, or send it to a server, or compress the resulting video copy, etc. In this specific case, you probably want to save it to disk in all of those cases, but there may be other programs where you want to separate preparing something from actually doing something with the prepared object.
I don't really understand the benefit of writing factories to instantiate objects versus packing all of this functionality into a static class or even just a module, then creating "argument objects" and passing them into something that does the job, calling the correct methods, etc.
In this video, I wanted to stick to the traditional Factory design pattern to show how it works. However, these design patterns were conceived in the 90s and programming languages have evolved since then. I’m currently working on a video that expands on the idea behind a pattern like the factory and then suggests a few alternatives using more modern Python features.
There is! I'm working on a course called Foundations of Software Design. It's still in the early stages though, so it will take a while before I can release it.
01:30 If it doesn't really matter for this example, then it shouldn't really be in this example, because otherwise it unnecessarily obfuscates it and makes it more confusing, since the viewer's brain starts cracking things that don't really matter :q 09:20 Not the best name for a function. Function names should express actions (verbs), not objects (nouns). Considering that, the name of this function may suggest that it reads some exporter instead of returning a read exporter object. 09:50 Wouldn't it be returning the same instances from each call instead of a new one? 11:08 Nope, it just says that it does ;)
@@ArjanCodes Since you're a friend of Uncle Bob, I'm assuming you've read _Clean Code_. Your methods already convey their intention, so the comments are redundant and distracting. The ultimate offender being "Main function." Your content is excellent, though.
Ah right, I see what you mean. I try to make sure that there are no pylint issues in my code examples. Pylint wants every class and method to have a docstring. I try to keep them as short as possible to not be distracting, but sometimes I go too far :).
💡 Here's my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
For me as a data scientist your videos really stepped up my software development game. The Factor Pattern together with having abstract classes as interfaces is something I immediately applied in my current project. This is not something you typically learn in data science courses, even though I think this is crucial when willing to write code in a professional context. Thanks Arjan for sharing those valuable insights!
Thank you, John - I'm happy that the videos are helpful to you!
Curious to know how you applied the concept in your current DS project?
Totally agree. Although Arjan is working in Python, much of the design discussion applies to any language. The OOP and pattern concepts discussed are easily used in other languages (well, okay SOME details aren't perfectly portable, but most)
I'm binging your videos currently and (among other things) there's something I love: the examples are meaningful. They are practical, solve actual problems. Not your another off the mill tutorial with generic class C inheriting class B etc. Seeing that your example applications mimic actually doing something, makes it 100x easier to wrap the application logic and focus on the topic at hand. I'm amazed.
I just found out about you today while learning certain design patterns. Now, I started reading about factory patterns just a few hours ago and boom, you're here with the video. Thanks for the video. Maybe adapter pattern in the next video?
Welcome aboard! The Adapter pattern is in the planning, but it might take a little while.
Unsure if this is mentioned somewhere, but this is the GOF Abstract Factory pattern. Not to be confused with the GOF Factory Method pattern. The Abstract Factory pattern's goal is, as Arjan says, for grouping different class instantiations together. The Factory Method pattern is about extending the functionality of a class.
This comment saved me a lot of confusion, thanks a lot!
To be more specific, Factory Method pattern delegates object instantiation to the sub-classes and makes rest of the code dependant on an interface or an abstract class
I am starting a new fulltime developer position in august and im trying to brush up my basics. your channel is amazing
Thank you - glad you like it. And good luck at your new position!
At 9:53 when you do the dict trick. The value is an Instance of each object type due to the () at the end right? Does that mean this is bad if you have many factories which take up memory and you instantiate them all. Is it better to leave the value instantiated then instantiate once it returns?
Searched for this comment) I think it's just as an example but yes in general if you have a lot of objects it's pain
I really like the idea where you first present the problem and show the solution. Most videos I watched rant about the theory but forgets to tell you the why part.
Thank you your videos, I understood the design patterns. I implemented it in my current project initially I thought it was lot of work but I persisted and wrote classes for them. I had a requirement to change the data source from DB to file. Some I had implemented it as classes, it was easier me for replacing the spice without impacting the code ! It was a life and a time saver. Thank you !
Please keep sharing such quality content. I’m sure it must be helpful for a lot of folks!
Glad to hear that the videos are helpful!
9:29 doesn't this make the factories dict eagerly instantiate all these object at once? (regardless if they are being used or not)
I am not sure what's the correct way to do it, but if i had to write it this way i would:
factories = {
"low": FastExporter,
"high": HighQualityExporter,
"master": MasterQualityExporter
}
and then: factories[export_quality]()
Nothing wrong with this, but seeing that the factories are pretty small it's not a big deal. In a lot of real-world examples, you'll also need to send some arguments into the creation of those factories, so you can't just store the class, you'd have to store a function that returns an instance. Funnily enough, you're essentially storing a factory of the factory. In the end, it's usually just simpler to instantiate them right away. The objects are probably short-lived.
My thoughts exactly, but I'm more of a cpp guy, so I'm eager to hear what the pythonic way is. Also, repeated calls may create new and new instances. (do they?) That could be solved by moving the map out of the function to the module level I guess. (And thanks for the nice vid.)
@@CrapE_DM The shown variant using it's class name and creation on demand is indeed a much cleaner version. I would use factories.get(key) to handle non-existent keys/requests gracefully. You'll use factories in larger projects containing multiple different services. How do you want to estimate the life span of an object or service, outside of your own context? You'll probably have no information about complexicity, startup, resources of such a service by instance creation. Projects grow in real world, sometimes really fast. So at this stage, creating objects might become bigger issue than you might expect. (Think about db connections, service/event registration etc pp)
Passing additional information via *args or **kwargs is simple.
Yes it does instantiate them all and always discards the majority of them unused. And yes your code is the correct way of implementing this. Likely just an oversight.
@Andrew Ramshaw Hey Andrew, I think you misunderstood or mispelled sth.
The factory method is a method (!) pattern and only encapsulated in a class at c#, java etc. because of their' OOP. You'll see that a factory method is always static, there will be never an instance of the factory itself - as this would'nt make any sense. Like a factory, the method creates suitable products according to specified parameters or configurations. At this point there is no dependency on parents or side effects, just a dependency on a common (abstract or interface) type per factory method.
Do not mix multiple thoughts into a pattern, as one pattern (usually) addresses only one challenge.
I so enjoy your presentation and delivery. Great job in explaining "why" things are used and not just the typical "how" (which is what geeks who already grokk something tend to do).
I also like how you discuss what things a pattern doesn't do well and then you provide an alternative for such cases. ⭐⭐⭐
I have been watching all your videos over the last week. I am glad I have reached a point where as soon as you started explaining the factory pattern for decoupling the main(), I thought that this would eventually lead back to dependency injection.
Very good! These things are all connected by a set of basic principles in the end.
I'm addicted to your channel man!
Congrats. Cheers from Brazil.
Thank you, glad you like the content!
this is the best python channel hands down, anyone can suggest other channels like this?
Thanks Artur!
tech with tim is also great
You might like mCoding!
theprimetime neuralnine fireship
I really enjoyed the video. Your pacing and amount of content is very good as a reference!
In a future video, could you clarify the differences between a Factory Pattern and a Builder Pattern? I feel like the builder is a way to collect factories, but I would enjoy seeing a worked example.
Amazing video! One SUPER small item I saw in read_explorer() is that export_quality is using in to check against the available factories. Using: if factories.get(export_quality) will not iterate through the dictionary but directly see if that key is available. Considering how few factories are available, this would never get noticed. I recently found your channel and binged a few videos already :) Subscribed!! Can't wait for more.
My most frequently used pattern before your videos. Thank you!
Same here :). Glad you liked it!
Thank you for what you are doing. It is really helpful. Keep going.
Just providing a real world example here. I just solved an issue that I had where I needed to provide an implementation of an output port based on a given value with the factory pattern. In this case it was a Payment Processing Service and the code quality and maintainability was quite good with the implementation of the factory pattern, which comes super handy since Payment Processing Services are always likely to require updates or new integrations in the future.
Thanks for the video, super useful as always!
Thank you, Juan, glad you liked the video!
Awesome videos man, really helps me understand design patterns that up till now sounded a bit vague and abstract to me. Bedankt!
Thank you Jelle - graag gedaan ☺️
Your code examples and the way how you explain them is top.
Thank you!
Another outstanding video Arjan!
Design patterns are useful for giving common solutions a name, but I find that the 'standard' implementations often don't make for Pythonic code. In Java you need all these classes to satisfy the 'compiler', but thanks to Python's dynamic nature you can achieve the same with much less code.
For example, a function get_exporters(quality: str) -> Tuple[VideoExporter, AudioExporter] would do the same, but in ~5 lines instead of ~30, and would be much easier to understand, while still removing the coupling. Add to that that classes are usually moved to separate files, and it becomes really hard to get an overview of the application without diagrams.
There's a nice talk about this that motivates it better than I could: Stop writing classes.
Though considering the intended audience is Python beginners and intermediates, I understand the focus on explaining the design patterns as they normally appear. Another section 'making it Pythonic' would be nice, but I guess that could get too complex for beginners.
I mostly agree with this, though classes are not completely useless. If for example you want to add some settings to a factory that influence how the instances are created, then a class is a good solution because it combines data with behavior.
I'm using classes in most of my examples when explaining these design patterns to not make it too confusing for the viewers, but I'm seriously thinking about following up with a series where I try to reimagine these patterns, but then using more Pythonic features instead and see how that holds up.
@@ArjanCodes Looking forward to it!
Looking forward to this as well
Another fantastic video!
Thank you! Cheers!
9:56 Say I wanted to add another factory to the factories object wouldn't that break the Open-Closed Principle? What's a way around that?
No, not really.
I guess you think that because you would have to add a new factory to the dict if violates the closed for modification principle.
Open/Closed means you can modify the way a system works without modifying the code that already exists. You can extend the code and use it in different ways, but the old code is still in tact and doesn't need to be re-tested.
The Factory Method pattern will create a different type of object based on specified parameters. Factory Method actually works well with the Open/Closed principle if done correctly. However, if you create a new class and then want the Factory Method to create a new object of that type you would have to change the Factory Method.
When to use the factory pattern? Whenever you want to turn Python code into Java code.
class WindowComponentGraphicsManagerBaseFactory extends AbstractWindowComponentGraphicsManagerFactory implements BasicGraphicsFactory
BaseFactoryManagerFactory wants to know your location
Really enjoy the video that talking about the design pattern in python, especially with a understandable example. Look forward to see more video with more difficult and useful pattern in python.
Glad to hear you like it, Chris!
Might not be understanding correctly, but at 3:53 you mention that the main() function has weak/low cohesion because it is "doing a lot of things". Does that actually make it _low_ cohesion though since all of the video/audio functionality is within same area? I agree that this function has _high coupling_ with the other classes.
As Arjan mentioned if you have wide variety of combinations then I use a factory controller class which can generate the proper factories. It is not so complicated.
Master quality video on Factory pattern :)
I would like to propose the use of a factory dictionary approach, where the dictionary values store class names instead of actual instances. This can be more efficient, especially when creating instances is resource-intensive. The idea is to define a dictionary of factories like this:
factories = {
'one': FactoryOne,
'two': FactoryTwo
}
Later, when you need to create an instance based on a specific key, you can use the stored class names to instantiate the desired objects. This is done as follows:
return factories[key]()
With this approach, you optimize memory usage by storing class names, and actual instances are only created when needed.
Hey! First, thank you so much for your videos. I knew about patterns long time ago but never really understood how to put them in practice.
I have a question about this... I don't see that much of a benefit.
Basically what I see in this example is that the Factory pattern allows us to know about half the things we needed - before we needed to know about 3 video exporters and 3 audio exporters, now only 3 factories. But I still have to know about the factories.
And yes, you can move that to a different function as you did with the read_exporter, but you could've also done the same without the factories and just have a dict with tuples, like `{"master": (LosslessVideoExporter(), WavAudioExporter()), ...}`
What's the real benefit of this?
You only have to know the Abstract Factory "ExporterFactory" but not the 3 factories themselves. You can keep adding as many factories as you want as long as they implement ExporterFactory.
Im a bit confused about terms and concepts so any help is appreciated.
1) Is example from video an implementation of "Abstract factory" pattern?
2) Does such thing as "Factory pattern" exist? Or maybe its not a "pattern", but something else? Because i mostly find "Factory method" and "Abstract Factory" among patterns.
Great video, btw! As always on this channel.
I love how you pieces them up! Awesome! please do more videos with classes :D
Thank, glad you like it, and will do!
@@ArjanCodes by the way do you have advanced courses for python on sale? Looking out for more advanced tips out there?
Not yet, but I am working on a course at the moment!
@@ArjanCodes inform me about the ones tailored for advanced users. Thanks so much! Can't wait
Function "read_exporter" initializes all exporters, which I think is bad. It is generally a bad idea to create a dict (or a list) containing instances instead of classes. WDYT?
The advantage of the factory is that they don’t weight anything in memory, they are just methods, no data
For your factories object, why did you instantiate all 3 in the object? Would it not be better to instantiate on the return when the needed factory was pulled from the dict?
Would love a video on comparing the Factory and Builder design patterns and when to use one versus the other.
Great video on the Factory Pattern. My question is, doesn’t the read_exporter function violate OCP in SOLID as we’ll have to keep changing it to add more Exporters?
That's correct. I did this in this video to keep things simple. Optimally, you'd want a mechanism to be able to register these factories dynamically so that the code that uses them doesn't need to know which factories there are. I'm working on a video at the moment that addresses that particular issue.
@@ArjanCodes for those looking for it: th-cam.com/video/zGbPd4ZP39Y/w-d-xo.html
Do you want to instantiate all those exporter objects in the low/high/master dictionary? Wouldn't it be better to instantiate only the one that is called?
9:52 are creating these exporters, like you did in the video, good for the memory? I thought lazy initialization was a better approach.
I strongly recommend you to use visualizations to introduce the patterns in a better way. Nice video.
Thank you for your videos. Content is amazing have a question:
At 10:21 you defined read_exporter. But if we call read_exporter then it will create objects of all 3 classes from factories dict. Won't that be a memory wastage cause at the end we are going to use only one object?
Please correct me if I am wrong.
lol, I was thinking the exact same.
Question: If the concrete classes require different parameters in the constructor, how can you implement this in the factories get_video/audio_exporter() methods?
Thanks god I learned English, my man. I'm Brazilian and the tutorials we find in Portuguese are nowhere near as good as this one (aka how to make a CRUD, make an Animals class and crap like that), I programmed everything on main() for years back when I was a teen simply because there's nothing about code designing in the Portuguese side of the internet.
Great video! You explain the concepts incredibly well.
Thank you for the video. I do have one suggestion though. When you mentioned about the cases where factory pattern is not possible, such as when the user decides on the different params to get their desired exporter, I would use the Builder design pattern.
You are a high quality video exporter.
Haha, good one 😁.
What should I do if I need N objects that have the same methods, but each type of object has a different input args + partially some common properties?
Thanks Arjan. this is so authentic.
Thanks for the video.
Seems you shouldn't create all of available factory instances in the `factories` dict. Just remove brackets from dict (don't __call__ classes) and add call on return to create chosen class only
Instanciating the exporters in the dictionary is not alocating unecessary memory? I'm new in python so i don't really know, but if does, there is not a way to create the instances in execution time when necessary?
This is also a good example of strategy pattern.
Great video. Really helped me understand this pattern
Why is the factory a class instead of a method? Also what's currently really missing on TH-cam is tutorials about compilers such as Nuitka and Pyinstaller, the whole professional side of shipping your code.
Bruh, there are literally thousands of tutorials in PyInstaller out there. They are not even compilers, they just package all you python modules and an python executable into an executable file.
(Btw there is no "professional way of shipping your code".)
To your question why the factory is a class instead of a method (you mean function, don't you?): It's basically done to make it clear in the context of object oriented programming. The same functionality can be achieved by using functions (or even just dictionaries). In case of functions it makes the code less readable. That's it.
That's a nuclear cooling tower in you thumbnail, not a factory. Ha ha. Just feeding the algorithm. I like your series, it's very good!! and you speak well with an accent that makes you sound very intelligent.
Thanks Michael! I'm learning something new everyday, haha :).
Hi, Can you please show how we pass object parameters of low , high , medium instead of input ()?
If the factory class has a registry that takes up low, high or master, does that change it from being a factory to something else?
Oh my gosh! you made cry because of the excitement
Question: Why to use classes at all here? Why not just functions like "export_video(quality, path)",export_audio(quality,path)" and then use then just use them directly in the 'main'? In the above approach, you make an abstract factory, and a class for each of the combinations of qualities factories and then a separate class for each quality settings and an abstract class for them.
Why is it a bad idea to just use a function instead all of this? If you need to group the video export and audio export together, you can just put them in another function. What am I missing here?
It’s not a bad idea at all to rely on more Pythonic mechanisms that achieve the same result with less code. In this video I wanted to stick to the traditional pattern (which relies on classes and inheritance). However, I did a follow-up video where I explored a few alternatives, see: th-cam.com/video/zGbPd4ZP39Y/w-d-xo.html.
@@ArjanCodes Thank you very much!
Top notch content, keep it up.
Great Python content. Thank you very much for content like this. Do you mind a silly question: why the ExporterFactory.get_video_exporter & ExporterFactory.get_audio_exporter don't have the decoractor @abstractmethod like the class VideoExporter?
Oops, sorry for asking before looking at the final code on github. Those methods are indeed declared as abstract. :)
I know that's probably not the point of this video but I feel like we should be using argpase instead of input for cmd scripts.
Yes, that’s probably the best option if you want to create a more complex CLI.
I absolutely love your videos! Can you please guide me to master programming as a beginner.
Underrated video
Thank you, glad you liked it!
Very high quality content .
Finally founded QUALITY PYTHON DEVELOPER.
could someone explain why to declare variables without assignment?
video_exporter: VideoExporter
audio_exporter: Audio Exporter
Amazing video, as always! Thanks, Arjan.
I also learned Python has Protocol classes but seems to me it's the same as ABC.
Het voelt alsof je veel meer code typt voor een niet veel beter eindresultaat. Wat is het voordeeld van het gebruik van een class voor elke soort exporter, inplaats van video- en audio-exporter in tuples te zetten, waarna je de tuples in een dictionary samenvoegt?
That one was great!! Thanks for the help. you provide great content!!
The only video I kinda dont get is the Observer one.. but I guess thats just me
Could we consider read_exporter() to be a FactoryFactory?
GOF is proud of you 😁
I am a bit confused.
Usually factories are used to generate instance of similar object no ?
But here we have to create a different factory per class ! (well one factory for two classes, but let's start simple with just a family of video codec)
What is the use of it ? Each time I create a new VideoExporter I have to create it's dedicated factory.
The only improvement I see, is that the switch has been located in a different function, not in the main anymore.
And I still would have to rewrite this switch after adding a new codec. The difference is that we have a switch of factories instead of codec... great.
Shouldn't we use metaclass and each class using the relevant metaclass being automatically referenced with its associated keyword in to the factory when it is created ?
And thus according to this exemple, we would have only two factories, one for video, one for audio, able to return the instance matching the good codec from the relevant keyword, with auto handled switch !
This reminds me of a plugin registration architecture. Is the plugin architecture related to the factory pattern?
Often, plugin systems rely on a factory-like pattern. Each plugin basically defines a concrete factory that provides instances specific to the plugin. Combine that with a factory registration method + dynamic script loading and you have the basics of a plugin architecture.
@@ArjanCodes I see, thanks for the explanation
In your read_exporter function, you check if export_quality is in a set of possible quality options. Is there any reason why you use a set instead of a list?
because the choices are unordered and unique, so a set is a better match than a list. If there is no order, don't use a list.
Juste discovered your channel. Awesome tutorials, thank you very much ! Subscribed ;)
Thanks Robin, glad you're enjoying the videos!
But you could just map corresponding keys ("master", "fast", etc...) to tuples of audio and video exporter. This would reduce the overhead of having extra classes while keeping the same functionality. Am I missing something or could it really be substituted completely with ease(at least in this example)?
What I mean:
mapping = dict(master=(LosslessVideoExporter,WavAudioExporter), fast=(H264BPVideoExporter, AACAudioExporter), ...)
I mean you have to map some kind of user interaction anyway. You even need that kind of dictionary anyway. What's the point having classes that neither store data nor compute anything (I mean, they do, but instancing an object is pretty trivial - using a separated method for this seems pretty bloated to me)?
Yes, you could probably also do this with tuples. I use a class here because that's how the Factory pattern is defined, so I prefer to stay close to the original pattern in order to avoid confusion. Another reason to use a class and not a tuple is that you might want to store data in the factory. For example, you could imagine that a Factory also stores some configuration settings or data that it needs to create the instances. This is exactly what classes are good at.
@@ArjanCodes okay, so the fact that it's almost evenly convenient to use a dictionary instead is due to the chosen example an not generally the case?
The goal of the factory pattern is to separate creation from use. If you can achieve that same thing with tuples or dicts and you don’t need class-specific features such as attributes, or dataclass behavior, then why not use that if it’s more convenient? The thing I’m concerned about is whether using typing will be as easy as with classes. I’m intrigued though by the idea. I might take up the challenge and do a video where I compare the two options.
Increase the font size, can't see anything in my low res 240p video setting
Thanks for your feedback!
Very high quality video. :) Subbed! I wanna see you use Starlette, which I love. :)
Factory pattern with pydantic saves my life everyday when I am writing code. Factory pattern is also helpful, if you are trying to validate your types if you are doing graphql with something like ariadne.
Glad you enjoyed it and thank you for the suggestion! I don’t have experience with Starlette. How is it different from something like Flask?
I came on youtube to brush up on the factory pattern, you did an awesome job! Definitely using it in my code today. Thanks.
Awesome content, You got a new follower !
Thank you - and welcome onboard!
Is it considered bad practice to have a single factory and pass in the desired quality as a parameter rather than 3 separate factories?
Great content Arjan! Could you add a video on OOP for data science? I see a lot of code with tightly coupled functions that alter a single giant pandas dataframe. It would be nice to see you shine your light on that
Thank you so much! This helps a lot :D
Thanks so much, glad the content is helpful!
Excellent!
My only issue is that the user input prompt is still hard-coded, so doesn't automatically adjust to changes in the export options.
You're right. Fortunately, it's an easy fix:
export_quality = input(
f"Enter desired output quality ({', '.join(factories)}): "
)
A bit off topic. But I believe that prepare_export and do_export create an antipattern known as sequential coupling. Template method pattern should've been used here.
Really great video
Not a fan of "get_...". When I get sth from the fridge I expect it to be there and after I got it to not be there anymore.
Imho "create_audio/video_exporter" is far better.
Alternatively "construct/build/etc" - whatever the domain language might be.
Oh and sorry didn't want to be the "just negative guy". It's actually a great video, but this one thing just itched :)
No worries and that's a valid point! Get and create indeed mean different things. This is a great example of Phil Karltons quote "There are only two hard things in Computer Science: cache invalidation and naming things." ;).
I always felt like keeping my __main__ part as light as possible. Now I see why it is cool and how to properly do it.
main():
main2()
Problem avoided
@@chri-k ahahaha, that's the way!!! :D
While the general Point being made here is ok, the example is not at all pythonic. Python isn't Java. You shouldn't create a factory class that has no constructor and no internal state. You can instead replace every instance of a subclass with a tuple (or a namedtuple if you are fancy) of two functions (in this example, one can even just use the constructors of the Exporters themselves.). Python3.6+ Type hinting even gives you a good way of telling the user (and IDE) what a function expects.
Can you put a github gist link of how to do it in pythonic way?
@@TsArun-qw6xn he has just made a video with a pythonic version of this pattern
Also, what is the point of having "prepare_export" and "do_export"? Why not have simple functions like export_h264(data, directory)? I feel like OOP forces you to create unneeded abstractions.
@@ianliu88 This is not o problem of OOP. This is a problem in the head of designer ;)
@@ianliu88 There might be differences in how you want to handle the result. You might want to save it to disk, or send it to a server, or compress the resulting video copy, etc. In this specific case, you probably want to save it to disk in all of those cases, but there may be other programs where you want to separate preparing something from actually doing something with the prepared object.
I don`t understand. it is video about pattern factory or about factory function/method ?
I don't really understand the benefit of writing factories to instantiate objects versus packing all of this functionality into a static class or even just a module, then creating "argument objects" and passing them into something that does the job, calling the correct methods, etc.
In this video, I wanted to stick to the traditional Factory design pattern to show how it works. However, these design patterns were conceived in the 90s and programming languages have evolved since then. I’m currently working on a video that expands on the idea behind a pattern like the factory and then suggests a few alternatives using more modern Python features.
hi, any chance you release an online course?
There is! I'm working on a course called Foundations of Software Design. It's still in the early stages though, so it will take a while before I can release it.
01:30 If it doesn't really matter for this example, then it shouldn't really be in this example, because otherwise it unnecessarily obfuscates it and makes it more confusing, since the viewer's brain starts cracking things that don't really matter :q
09:20 Not the best name for a function. Function names should express actions (verbs), not objects (nouns). Considering that, the name of this function may suggest that it reads some exporter instead of returning a read exporter object.
09:50 Wouldn't it be returning the same instances from each call instead of a new one?
11:08 Nope, it just says that it does ;)
Thanks for this great video
You’re welcome - happy you liked it!
You should do a video on Asynchronous in Python, it's little mysterious and not sure it's reliable.
Being a friend of Uncle Bob, the comments in the code _really_ surprise me.
@@ArjanCodes Since you're a friend of Uncle Bob, I'm assuming you've read _Clean Code_. Your methods already convey their intention, so the comments are redundant and distracting. The ultimate offender being "Main function." Your content is excellent, though.
Ah right, I see what you mean.
I try to make sure that there are no pylint issues in my code examples. Pylint wants every class and method to have a docstring. I try to keep them as short as possible to not be distracting, but sometimes I go too far :).
@@ArjanCodes That's why you can disable them in .pylintrc. 😄
It kind of makes me feel dirty doing that. I’ll just have to get over it I guess ;).
Take into account that is easier for the audience that are not that expert (like me) to have proper documented classes and functions :)
In this example an extra layer of inheritance was used. It increases the complexity in provided example without a reason :)
Otherwise... nice.
EXCELLENT!!!