it's 2023 and this series is still amazing

2020 now. Still the best design pattern videos I've watched.

I've be developing software for 23 years and, have read both books, and know and have used all of these patterns. I came looking for good tutorials for my less experienced team members, and even with knowing this information already, I can't stop watching these, they are excellent resources.

So glad to hear that you're expanding this series from its original scope. This is an excellent series, actually useful as a learning resource. Thanks a lot for your time dude, and really good job so far. :)

I watch your tutorial when i was an intern employee, now as a senior level still watching your stuff. Appreciate it!

Thanks, the best design pattern tutorials on YT!

I will probably never thank you enough for these videos...! You explain things so clearly, I can spend days understanding a pattern then I watch your video and it just clicks and suddenly it's all clear. Thank you!!

00:03 The bridge pattern is a part of the additional patterns mentioned in the book Design Patterns. 01:48 The bridge pattern decouples an abstraction from its implementation. 06:10 The Bridge Pattern decouples abstraction from implementation. 08:30 The Cartesian product is a new set of all combinations of two sets. 13:01 Different views and media types need to be handled in a flexible manner. 15:13 The bridge pattern allows combining any arbitrary resource with any arbitrary view. 19:14 Using the Bridge pattern reduces the number of classes needed to handle different combinations. 21:23 The bridge pattern allows us to isolate the specifications of artist resources and view nests. 25:43 The Bridge Pattern allows views to use specific methods from resources without breaking the interface segregation principle. 27:52 Avoid duplicating behavior across different resources. 31:38 The resources in the bridge pattern have different concretions. 33:31 A view in the Bridge pattern can access a resource that behaves as a resource. 37:17 Separating artist specific, book specific, and playlist specific functionalities into their own inheritance hierarchy. 39:14 The video discusses the Bridge Pattern in design patterns. 42:54 An artist resource implemented the interface IResource and adapted over an artist. 44:46 The artist resource needs to delegate to a specific artist to get the required information. 48:37 The Bridge pattern allows for separating platform-specific and platform-independent code. 50:34 The bridge pattern allows a view to ask a resource for the information it needs to construct a particular view.

Love the sound effects of heads exploding. Understood it about half way thru the example. Excellent explanation, can't wait for a reason to use it.

The real thing about your explanations is that it's ok to be shortly distracted watching your video without loosing my train of thought. It's not necessary to be being in the full attention during whole video as in the case of classic university lectures. It's super helpful and the best thing for me.

Even though this playlist is 5-6 years old still the best out there. Thank you for this golden playlist.

2022 now. Still the best design pattern videos man

I learned from lot's of tutor all they do their best , but you are the best teacher, ...in starting I hate designed patterns because I didn't understood but after learning from I am fall In love with design pattern 😍💕

You're like the Mr. Bean of programming ;D Great work - and as you would say, super-pedagogical example! :-)

Thank you very very much! I would never have imagined that I could understand patterns so deeply! You are the best teacher ever, really!!

The best teacher of design patterns till now .

Thats another great video. I love your explanations. Basically i would differentiate Bridge Pattern from Adapter pattern as the following: Adapter pattern is meant for interoperability, where a call from the "Adapter interface" should be translated to a call to the "Adaptee Interface", in order to "plug" the calls transparently, so to speak. Bridge interface is meant for data extraction, or data combination, depending on the need. It's a bridge abstraction, relying on a implementor contract, to provide methods to access data, no matter what the implementation is.

There is no word to describe how grateful I am to you for these videos

I love your voice and you as a person

It's 2024, I was really confused about design patterns and your videos have cleared my concepts. Thanks!

Last time I watched your videos about 5-6 years ago and till now I watched a lot of other videos related to software engineering, but never saw someone explaining not like you, but even close to you.

Last moments of 2020, still the best design pattern explanations. Thank you master.

The reason of why the author used abstraction and implementation terms is : when the author say : decouple between abstraction and implementation, he means Resource(as an example) is abstraction and its implementation is View, because the View will use Resource and it will receive Resource implementation by its constructor using Dependency injection, so as you know the implementation belong to abstraction and in this example View has a reference to Resource, and technically View has implementation for Resource, so View is implementation of Abstraction Resource. it is my own vision of this definition, but i am not agree to use these terms like this because it might be confusing. thanks a lot for this explanation.

I cant express how great you have explained this. 10 min into the video and I already understand it better than by any videos or tutorials I watched or read before. Thanks!

This is what I understand to implement this pattern in React land: We have a base Card which is our Abstract View. Then we have concretions of this Card, ReadOnlyCard and ActionsCard. We get entities such as Artist or Song from our API. Then for example, we can then do a mapping exercise: Do a artists.map(artist => { }) We can also just create an ArtistReadOnlyCard if we have a specific view to `show` for this card since it it might vary from a SongReadOnlyCard. These videos make me really think on how to create components that I can re-use in other apps and which ones are app specific components. Also entity specific components. This made me think about creating ReactHookForm specific components. Let's say I want to Create a LibPhoneField in order to compose this: TextField -> PhoneField -> LibPhoneField. I might be off topic now. Anyway great video!

2022 still the best design pattern videos!! I am really sad to see that you are not posting more videos like this that have you explain in a whiteboard very fundamental stuff! Really appreciate your teachings!!! Please comeback with topics like this! Love your whiteboard teachings!!

I had to read Head First Design Pattern yrs ago I find it entertaining and effective, If I recall there was that girl that was anti-pattern which helps you question why you should use the pattern in the first place and understand it better.

I am saved by this video... all 52 minutes with it

This is literally the best design patterns video I ever watched on KZfaq

The enlightenment/ the moment of Ahaa happened to me at 23:40 of this video. Thanks a lot!

Finally I understood what is that Bridge pattern about! Thanks a lot! P.S. Understood it on the mark of 30-40% of the video, because I really used it already in my work, but didn't understand that I did.

I watch your design patterns videos before breakfast and even before i return to bed at night, excellent job

Thank you. I read the 'Design Patterns' chapter on Bridge and really couldn't understand how this was different from simple delegation or what problem it was actually trying to solve. I don't know if your interpretation is precisely the problem they are trying to solve, but it certainly gives me a good way of thinking about it that makes sense.

I would definitely recommend this series for learning Design Patterns to any friends and colleagues.

This has to be the hardest of all the patterns covered in this series yet. Will watch it twice. Thanks a lot for creating this series.

2022 now. Still the best design pattern videos I’ve watched.

The best ever explanations of design patterns! You are awesome man! Please just don't stop recording new episodes. And your "code walk" series is really about those things that every programmer should think about. Do as many as possible, please :)

Great explanation! also, the video starts at 2:45

Cannot easily agree that resource is an implementation of a view (abstraction) Yet appreciate the effort to give a 🆒 real life examples explanation that is rich in context and easy to follow!

You are The God of explanation

I wish I had found this channel before because I never really understood this subject before I heard from this guy, thank u so so much!

I bet this is the best explanation of the bridge pattern all over the youtube

You're awesome! With your explanation, anyone has a grasp of Design Pattern. Thank you!

Thanks!!! I finally found a good example of how to apply this pattern. Very good explanation for the pattern.

This comes together exactly at 15:16. Very nicely explained.

2022 and still the best series on Design patterns

This is my second revision of this series and again I'll say what an explanation!!!! Great job bro...

First I just compared the length of your videos and the other pattern videos and thought " that's ridiculous" but, you sir managed to imprint it in my brain perfectly. You don't just explain well you do it in a way that sticks (Just like the head first books do). Kudos!

I was able to codify in .net this pattern thanks to you, very simple pattern indeed, once you get the grasp of it. The explanations and definitions about it are hard / nonsense though. I went one step further and made the Bridge to implement a generic, so I can use the bridge to implement whatever interface, which whatever return type.

Shout out from 2023! Thanks for taking the time to make these super helpful videos

Read both books but I still prefer the video demonstration ... Simply Most Amazing Simplified Design Pattern Videos !!!

king of design pattern tutorials

As I am currently preparing for an exam I have to thank you a lot for the Spotify example. That made the whole concept so obvious to me. Mind blown!

my prof recommended this video as a part of her lessons. this is honestly much better.

I was confused about the bridge pattern but now it's 100% clear ! thanks ! please continue this series

2022 now, still the best 😉 congratulations on the good job!

This is literally the best video/explanation i ve seen about this topic (bridge)

You rock, man! From what videos of yours I have seen, you offer very lucid and memorable explanations of design patterns. I especially appreciate that you show your own process of understanding--this saves us or greatly lightens a learner's process needed to reach the moment of clarity when we understand a concept in our own mental framework and can then see potential as to how we could use it in our own circumstances. That is, you take the process down to your personal level, a level we eventually have to take learning--this much better than tossing us data somewhat like a Wikipedia article for us to ponder...and ponder, i.e., "leave it to the reader to figure out". In other words, you help us to faster reach paths in our own way of understanding by walking through your own paths and sometimes how you got there. Thank you!

Thanks. Now that I know what the Bridge pattern is, I see I've been using it for years. :) I guess it's one of those patterns that evolves naturally when you start holding references to interfaces instead of actual classes.

2021: Still the best resource for Design Patterns! Love your efforts man! 🤓🙌

2023 and this is still the best resource for design pattern

Great Job man! This serie is a success

This was the first video of yours that I have watched and you presented it very well. I was reading about this pattern for hours and couldn't really grasp it but with your help I think I have obtained a pretty solid grasp of it. Thank you!

This is what I call talent. Best explanation ever. Thx man!

It is just a detail, but at 10:10 you said that number of elements exponentialy increases by increasing the number of elements of 2 sets A and B. But for two sets it is always quadratic. Cartesian product exponentially increase with the number of sets. (e.g. N x N x N ... ). Otherwise I love this series. Thank you for all the work you put to it.

Somehow I managed to understand Bridge pattern - perfectly clear. I did not have Heads first book... Thank you for the lectures!

Number of sets in the Cartesian product linearly increases O(n*m), where n, m are the sizes of the sets, maybe thinking of the size of the powerset for exponential increase. Great video!

strategy and bridge pattern look almost the same but while the strategy pattern uses composition to achieve its goals, it does not necessarily require the abstraction and implementation to be separated. In the bridge pattern, however, the separation of abstraction and implementation is a core feature of the pattern. so this is the key difference between the two.

Man, you are making the programming more funny than before. The best tech video I have ever seen. Thanks for the all series.

Your DP videos are seriously the best explanations anywhere. And I totally agree the definition of the bridge pattern is superconfusing. Especially because the “abstraction” in this case doesn’t need to be conceptually related to its “implementor”. Maybe I’m wrong but I see it as sort of a combination of template and strategy pattern.

You are really amazing, I even don't have words to explain How amazing your way of teaching is. I'm totally inspired by you.

Great way of explaining the design pattern. I understood the example but as you said at the end, it would be great if you could also list few other scenarios where this pattern would be applicable.

Definitely an anti subclass explosion pattern, kinda like Decorator. While Decorator focuses on variations of similar concerns (type1, type2, type3, etc. and how to combine them), Bridge is used for orthogonal concerns (type1, type2 on one side and platformA, platformB on the other side and how to make combinations between types and platforms). Types and Platforms being the two orthogonal concerns. BTW the example in the GOF book is quite nice.

Man I finally understand this pattern. It is actually extremely simple but it was described in such a confusing way at my university. Great job!

as well as the previous patterns, you've provided best description.

Thank you! Really nice and clean explanation. I totally agree that the definition in the book is quite confusing but thanks to you I got the idea completely.

Just one thing that can makes easier and a small correction on what you mentioned on 36:45 of the video above. The thing is the views are dependent to the resource. The views can be taken as a view for smart phone, tablet and a normal computer display (for the sake of resolution mainly). These views are dependent to resources, while resources has no dependencies to these different types of display. That is a good example for Bridge pattern on why Front-end and Back-end are kept separately. Thanks :)

This reminds me difference between multiplication and addition or permutation and combination logic. All about looking for importance of value or order similarity count. Little hard to explain but i hope you get it.

Thank you for making such valuable videos. These are going to be a great resource for developers.

This actually is the best pattern at least to understand abstraction. I also understood the use of Interfaces really well when I understood this pattern.

It will be 2024 in 5 days and this series is still amazing

Hey Christopher, this one of the best explanations and examples I have ever come across on Bridge pattern. Thanks much for your efforts and a wonderful brain storming tutorial

I got here by searching for bridge pattern deep dive. This is a must watch.

Great thanks for making this series!! You make each pattern's goal and details super clear! One thing that upsets me regarding patterns is that i fail to see which patterns to apply when i am encountered with a real-life scenario. I mean sometimes i see a problem that needs to be solved, and my intuition says that it can be solved by using some pattern, but to pick correct pattern is pretty Hard...

Great video. Suprised these aren't getting more views. I'm learning so much.

Thanks Christopher Okhravi. It is interesting. Your explanation is in sync with my thought process.

I love this explanation for the Bridge design pattern, I've recently been strugling with some sort of similar issue and as long as the requirements grow I'm having a large cartesian product underlying in my implementation. I will apply this particular design pattern in the short term :)

Thank you, Christopher, it is really awesome, the way you explain using the real-world example. because of that only I was able to connect it to the problem that I faced before.

On first sight the advantage of this Bridge seems hidden: Cartesian Product and Sum with 2 Concrete Views and 2 Concrete Resources are both 4. 🤓 But, honestly, you've impressive explanation skills. Many thanks! 😊

Simply brilliant!

I think in simple terms, it is a "bridge" to enable you to access a specific resource (e.g. books, artists) for the thing that it wants to construct. Cos in strategy pattern it is the behaviour of the specific client that uses the strategy and in bridge, it polymorphs the target of the implementor of the interface.

The definition of GOF about "abstraction" and "implementation" kind of confusing but correct, because the relation between two interface is one-directional so in your example "view" is an abstraction which based on its "resources"(different implementations). But resources cannot use or be aware of the view. Actually it seems bridge pattern works only when in separating one class can become the client of the other class.

If I am right the GoF Catalog of Design Patterns contains 23 design patterns and this is the 3) °Bridge° (151): Here is an excerpt from the book « Design Patterns: Elements of Reusable Object-Oriented Software » ― by Richard Helm; John Vlissides; Ralph Johnson; Erich Gamma ― Published by Addison-Wesley Professional, (1994) → The Catalog of Design Patterns The catalog beginning on page 79 contains 23 design patterns. Their names and intents are listed next to give you an overview. The number in parentheses after each pattern name gives the page number for the pattern [a convention we follow throughout the book]. 1) °Abstract Factory° (ep 5). Provide an interface for creating families of related or dependent objects without specifying their concrete classes. (087) 2) °Adapter° (ep 8). Convert the interface of a class into another interface clients expect. [The] adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. (139) 3) °Bridge° (ep 11). Decouple an abstraction from its implementation so that the two can vary independently. (151) 4) °Builder°. Separate the construction of a complex object from its representation so that the same construction process can create different representations. (097) 5) °Chain of Responsibility°. Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. (223) 6) °Command° (ep 7). Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. (233) 7) °Composite° (ep 14). Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. (163) 8) °Decorator° (ep 3). Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. (175) 9) °Facade° (ep 9). Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. (185) 10) °Factory Method° (ep 4). Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. (107) 11) °Flyweight°. Use sharing to support large numbers of fine-grained objects efficiently. (195) 12) °Interpreter°. Given a language, define a [representation] for its grammar along with an interpreter that uses the representation to interpret sentences in the language. (243) 13) °Iterator° (ep 16). Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. (257) 14) °Mediator°. Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. (273) 15) °Memento°. Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. (283) 16) °Observer° (ep 2). Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. (293) 17) °Prototype°. Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. (117) 18) °Proxy° (ep 10). Provide a surrogate or placeholder for another object to control access to it. (207) 19) °Singleton° (ep 6). Ensure a class only has one instance, and provide a global point of access to it. (127) 20) °State° (ep 17). Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. (305) 21) °Strategy° (ep 1). Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. (315) 22) °Template Method° (ep 13). Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure. (325) 23) °Visitor°. Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. (331)

Thanks a lot ! This is an extraordinary explanation

I love the way you explains the difference between Adapter and Bridge Pattern. Hope to see more videos may be some the real life application where we can fit different patterns.

Not until we learn about Bridge Pattern won’t we know how important Adapter Pattern is!

Another great example of an application of this pattern would be the Spring MVC architecture, where views vary independently of the Model objects returned by various Controllers, and controllers are nothing but adapters of the database :)

Still 2024 and I watched all of your design pattern videos❤

this is an absolutly prefect explanation for this design pattern. good job!

The arrow when implementing an interface is a dashed line. Other than that, it seems right on to me.