WEBVTT 00:00:00.000 --> 00:00:02.819 You know, if an architect built a skyscraper, 00:00:03.080 --> 00:00:07.599 the way most amateur programmers write code, 00:00:07.820 --> 00:00:10.500 Oh, it would be a disaster. Right. The entire 00:00:10.500 --> 00:00:12.640 building would just instantly collapse the second 00:00:12.640 --> 00:00:15.019 someone opened a window on the 40th floor. Yeah. 00:00:15.339 --> 00:00:17.980 Because, I mean, usually when we talk about massive 00:00:17.980 --> 00:00:20.899 structures, there is an obvious physical reality 00:00:20.899 --> 00:00:23.399 to them. You can see the steel girders. You can 00:00:23.399 --> 00:00:25.620 like touch the concrete pillars. You can literally 00:00:25.620 --> 00:00:28.539 feel the heavy cables holding a suspension bridge 00:00:28.539 --> 00:00:30.539 together. Right. The architecture is tangible. 00:00:30.600 --> 00:00:32.619 You can just walk up and knock on a load bearing 00:00:32.619 --> 00:00:35.840 wall to see how solid it is. Exactly. But then 00:00:35.840 --> 00:00:37.789 you look at the digital world. you look at the 00:00:37.789 --> 00:00:40.969 software running your mobile banking app or an 00:00:40.969 --> 00:00:43.469 incredibly expansive multiplayer video game. 00:00:43.869 --> 00:00:45.350 Or even just the operating system on the phone 00:00:45.350 --> 00:00:48.670 in your pocket right now. Yeah. These are colossal, 00:00:48.990 --> 00:00:52.250 mind -bogglingly complex structures, yet they 00:00:52.250 --> 00:00:54.729 are completely invisible. Underneath all the 00:00:54.729 --> 00:00:57.350 sleek buttons and smooth animations, it's just 00:00:57.350 --> 00:00:59.890 text, millions and millions of lines of code. 00:00:59.950 --> 00:01:02.229 It really is wild when you think about it. It 00:01:02.229 --> 00:01:04.989 is. So welcome to today's deep dive. We are digging 00:01:04.989 --> 00:01:07.430 into the master blueprints of the digital age, 00:01:07.730 --> 00:01:10.650 focusing specifically on what are known as structural 00:01:10.650 --> 00:01:13.930 patterns in software design. Our mission today 00:01:13.930 --> 00:01:18.189 is to basically demystify these invisible scaffolds. 00:01:18.790 --> 00:01:21.030 By the end of this deep dive, you are going to 00:01:21.030 --> 00:01:23.629 understand exactly how the massive software systems 00:01:23.629 --> 00:01:27.010 you rely on every day avoid crumbling under their 00:01:27.010 --> 00:01:29.629 own massive weight. Because while code might 00:01:29.629 --> 00:01:33.579 look like a chaotic just a random jumble of English 00:01:33.579 --> 00:01:35.819 words and math symbols to the untrained eye, 00:01:36.280 --> 00:01:39.540 it's actually highly structured, rigorously planned 00:01:39.540 --> 00:01:42.299 architecture. And those structural patterns are 00:01:42.299 --> 00:01:44.200 exactly what keep the digital world standing. 00:01:44.439 --> 00:01:46.239 OK, let's unpack this. Because before we get 00:01:46.239 --> 00:01:48.340 into the really clever tricks and specific tools 00:01:48.340 --> 00:01:50.659 programmers use to keep your apps running smoothly, 00:01:51.239 --> 00:01:53.400 we need to understand what a structural pattern 00:01:53.400 --> 00:01:55.760 actually is. Right, the foundation. Yeah, and 00:01:55.760 --> 00:01:58.140 where this whole philosophy comes from. At its 00:01:58.140 --> 00:02:00.840 core, a structural pattern is a software design 00:02:00.680 --> 00:02:03.420 blueprint that encapsulates relationships between 00:02:03.420 --> 00:02:06.099 entities. And the history behind this is fascinating. 00:02:06.120 --> 00:02:08.780 It really stems from a legendary group in computer 00:02:08.780 --> 00:02:11.039 science known as the Gang of Four. Oh, yeah. 00:02:11.180 --> 00:02:13.840 They are absolute pioneers in software engineering. 00:02:13.919 --> 00:02:16.400 We were talking about Eric Gamma, Ralph Johnson, 00:02:16.840 --> 00:02:19.580 John Floesides, and Richard Helm. Right. They 00:02:19.580 --> 00:02:22.180 authored this really seminal book in the 90s, 00:02:22.180 --> 00:02:25.219 simply called Design Patterns. They essentially 00:02:25.219 --> 00:02:28.639 looked at the wild, totally unstructured landscape 00:02:28.639 --> 00:02:31.990 of early software. and categorize the solutions 00:02:31.990 --> 00:02:35.449 into creational, structural, and behavioral patterns. 00:02:35.669 --> 00:02:38.050 Wow, so they basically wrote the textbook. They 00:02:38.050 --> 00:02:40.569 really did. They were also heavily involved in 00:02:40.569 --> 00:02:42.830 communities that championed these ideas, like 00:02:42.830 --> 00:02:45.830 the Hillside Group and the Portland Pattern Repository, 00:02:46.090 --> 00:02:48.469 working alongside other major figures in the 00:02:48.469 --> 00:02:52.599 field, like Martin Fowler. OK, but there is one 00:02:52.599 --> 00:02:54.639 name attached to this history that completely 00:02:54.639 --> 00:02:57.080 stopped me in my tracks. Oh, who was that? Christopher 00:02:57.080 --> 00:03:00.060 Alexander. Ah. Because he isn't a computer scientist 00:03:00.060 --> 00:03:02.340 at all. He is a real world building architect. 00:03:02.460 --> 00:03:05.860 Yeah, he is. So the implication here is that 00:03:05.860 --> 00:03:09.759 using a structural pattern in software is exactly 00:03:09.759 --> 00:03:12.580 like a home builder using a standard mathematically 00:03:12.580 --> 00:03:15.479 proven blueprint for a door frame instead of 00:03:15.479 --> 00:03:18.800 inventing a brand new, totally untested way to 00:03:18.800 --> 00:03:21.409 build a door for every single house. Precisely. 00:03:21.729 --> 00:03:23.710 They borrow directly from physical architecture. 00:03:23.990 --> 00:03:26.370 But here's where I struggle a bit with that transition 00:03:26.370 --> 00:03:28.990 from the physical to the digital. Okay, how so? 00:03:29.629 --> 00:03:32.560 Well, software isn't wood and steel, right? It 00:03:32.560 --> 00:03:35.419 isn't bound by the laws of gravity or the tensile 00:03:35.419 --> 00:03:38.020 strength of concrete. No, not at all. It's infinitely 00:03:38.020 --> 00:03:40.659 flexible. A developer can write code literally 00:03:40.659 --> 00:03:43.259 any way they want. So why on earth would they 00:03:43.259 --> 00:03:46.060 constrain that infinite flexibility with these 00:03:46.060 --> 00:03:48.300 rigid, old -school patterns? What's fascinating 00:03:48.300 --> 00:03:50.340 here is that this infinite flexibility you were 00:03:50.340 --> 00:03:52.039 talking about, that is exactly the problem. Wait, 00:03:52.159 --> 00:03:54.280 really? The flexibility is the problem. Absolutely. 00:03:54.490 --> 00:03:56.669 When you can build anything any way you want 00:03:56.669 --> 00:03:59.330 without any constraints, what you almost always 00:03:59.330 --> 00:04:02.610 end up building is a tangled fragile mess. Think 00:04:02.610 --> 00:04:06.250 about it. If every single programmer on a hundred 00:04:06.250 --> 00:04:09.949 person team invents their own unique way for 00:04:09.949 --> 00:04:12.490 different parts of a system to interact, the 00:04:12.490 --> 00:04:15.550 whole structure becomes impossible to read. It 00:04:15.550 --> 00:04:18.250 becomes impossible to maintain and incredibly 00:04:18.250 --> 00:04:21.939 dangerous to update. By encapsulating relationships, 00:04:22.699 --> 00:04:25.600 these patterns create predictable, standardized 00:04:25.600 --> 00:04:28.060 ways for digital objects to connect. So they 00:04:28.060 --> 00:04:30.300 basically had to invent gravity for the code. 00:04:30.600 --> 00:04:33.319 Exactly. The Gang of Four essentially realized 00:04:33.319 --> 00:04:35.959 that because software lacked physical gravity, 00:04:36.500 --> 00:04:38.860 it desperately needed structural rigor. Otherwise, 00:04:38.980 --> 00:04:40.959 it just collapses. They had to bring the laws 00:04:40.959 --> 00:04:43.639 of physics into the Wild West of code. That makes 00:04:43.639 --> 00:04:45.620 total sense. It really does. So let's look at 00:04:45.620 --> 00:04:48.079 how these patterns actually organize relationships 00:04:48.079 --> 00:04:50.620 by, say, building a hypothetical system together. 00:04:50.879 --> 00:04:54.560 Let's say we are building a massive, modern e 00:04:54.560 --> 00:04:56.899 -commerce platform. OK, sounds good. The most 00:04:56.899 --> 00:04:59.399 common relationship problem imaginable in any 00:04:59.399 --> 00:05:01.920 big system is two pieces of code that completely 00:05:01.920 --> 00:05:03.500 refuse to talk to each other. Oh, definitely. 00:05:03.680 --> 00:05:05.920 Happens all the time. Right. So we are moving 00:05:05.920 --> 00:05:08.639 into the realm of the translator patterns, starting 00:05:08.639 --> 00:05:11.339 with the adapter pattern. And the core definition 00:05:11.339 --> 00:05:14.639 here is that an adapter takes one interface and 00:05:14.639 --> 00:05:17.899 adapts it into what a client expects. It is essentially 00:05:17.899 --> 00:05:21.220 a bridge between two incompatible I instantly 00:05:21.220 --> 00:05:22.759 thought of traveling abroad when I read this. 00:05:22.939 --> 00:05:25.379 Oh, yeah. Yeah, the adapter pattern is basically 00:05:25.379 --> 00:05:28.480 a universal travel plug. You have your American 00:05:28.480 --> 00:05:31.540 laptop charger and you are staring at a European 00:05:31.540 --> 00:05:35.199 wall socket. They both fundamentally handle electricity, 00:05:35.680 --> 00:05:38.220 but the physical prongs just do not match. Right. 00:05:38.319 --> 00:05:40.100 You stick an adapter in the middle and suddenly 00:05:40.100 --> 00:05:42.779 the power flows perfectly. It functions exactly 00:05:42.779 --> 00:05:45.470 like a travel plug. And in software, this happens 00:05:45.470 --> 00:05:48.009 constantly, especially in a scenario like your 00:05:48.009 --> 00:05:50.310 e -commerce platform. Give me an example. So 00:05:50.310 --> 00:05:53.430 let's say your slick brand new mobile app needs 00:05:53.430 --> 00:05:56.170 to pull customer data from a 20 -year -old legacy 00:05:56.170 --> 00:05:58.449 banking database. OK. Sounds like a headache 00:05:58.449 --> 00:06:01.550 already. It is. Your modern app expects that 00:06:01.550 --> 00:06:03.569 data to be neatly formatted in a lightweight 00:06:03.569 --> 00:06:07.170 language like JSON. but the ancient banking database 00:06:07.170 --> 00:06:11.670 only spits out clunky old -school XML data. Instead 00:06:11.670 --> 00:06:13.750 of spending millions of dollars rewriting the 00:06:13.750 --> 00:06:16.170 entire banking system, the developers just write 00:06:16.170 --> 00:06:19.089 an adapter. It sits in the middle, catches the 00:06:19.089 --> 00:06:22.430 XML, translates it into JSON on the fly, and 00:06:22.430 --> 00:06:25.600 hands it to the app. So neither the app nor the 00:06:25.600 --> 00:06:28.259 database even knows the other is speaking a different 00:06:28.259 --> 00:06:30.800 language. Exactly. That is brilliant and you 00:06:30.800 --> 00:06:33.100 can take that even further, right? Because there's 00:06:33.100 --> 00:06:36.040 a variation called the retrofit interface pattern. 00:06:36.120 --> 00:06:38.720 Ah, yes. Which is an adapter that acts as a new 00:06:38.720 --> 00:06:41.120 interface for multiple classes at the exact same 00:06:41.120 --> 00:06:43.579 time. So instead of just adapting one single 00:06:43.579 --> 00:06:46.699 travel plug, you are essentially retrofitting 00:06:46.699 --> 00:06:50.240 an entire row of wildly different kitchen appliances 00:06:50.240 --> 00:06:53.970 to use one single unified wall out. Yeah, and 00:06:53.970 --> 00:06:55.730 if you string them together you get what is called 00:06:55.730 --> 00:06:59.069 an adapter pipeline. This is incredibly useful 00:06:59.069 --> 00:07:02.110 for debugging. How so? Well, if your e -commerce 00:07:02.110 --> 00:07:04.730 system is failing, and you don't know why, you 00:07:04.730 --> 00:07:07.370 pass your data through a pipeline of different 00:07:07.370 --> 00:07:09.410 adapters. Because the adapters are separate, 00:07:09.610 --> 00:07:12.490 isolated steps, you can inspect exactly how the 00:07:12.490 --> 00:07:14.569 data is being transformed at every single point 00:07:14.569 --> 00:07:17.629 in the chain. Oh, making it much easier to isolate 00:07:17.629 --> 00:07:19.949 exactly where the error is happening. Exactly. 00:07:20.230 --> 00:07:22.550 OK, but I have to push back on a couple of definitions 00:07:22.550 --> 00:07:24.930 here, because as we look at these translators, 00:07:25.050 --> 00:07:27.910 some of the terms sound awfully similar. Sure, 00:07:28.029 --> 00:07:30.230 lay them on me. Let's talk about the extensibility 00:07:30.230 --> 00:07:32.069 pattern, which is also known as a framework. 00:07:32.790 --> 00:07:34.790 The defining characteristic is that it hides 00:07:34.790 --> 00:07:38.230 complex code behind a simple interface. But then, 00:07:38.250 --> 00:07:40.569 right next to it, we have the facade pattern. 00:07:41.290 --> 00:07:43.930 And a facade creates simplified interface of 00:07:43.930 --> 00:07:47.230 an existing interface to ease usage for common 00:07:47.230 --> 00:07:51.220 tasks. Right. Wait a second. Hiding complex code 00:07:51.220 --> 00:07:55.100 behind a simple interface versus creating a simplified 00:07:55.100 --> 00:07:58.199 interface for existing complex code. Aren't those 00:07:58.199 --> 00:08:00.480 basically the exact same thing? Why do we need 00:08:00.480 --> 00:08:02.879 two totally different names for this? It is a 00:08:02.879 --> 00:08:05.220 really subtle distinction, but it's a vital one 00:08:05.220 --> 00:08:07.600 when you are actually architecting a massive 00:08:07.600 --> 00:08:10.040 system. Okay, break it down for me. A facade 00:08:10.040 --> 00:08:12.620 is about easing the usage of existing interfaces. 00:08:13.060 --> 00:08:14.899 Think about what happens when you click the Buy 00:08:14.899 --> 00:08:17.459 Now button on that e -commerce platform we are 00:08:17.459 --> 00:08:20.189 building. For you, the user. It is one simple 00:08:20.189 --> 00:08:24.009 button. That is the facade. But behind that single 00:08:24.009 --> 00:08:27.310 button, the system is frantically pinging inventory 00:08:27.310 --> 00:08:30.310 servers in a warehouse. Oh, right. It is contacting 00:08:30.310 --> 00:08:32.169 your credit card company's fraud department. 00:08:32.769 --> 00:08:35.330 It is calculating dynamic shipping algorithms 00:08:35.330 --> 00:08:38.289 based on your zip code. And it is generating 00:08:38.289 --> 00:08:40.929 a receipt. That's a lot going on. All of those 00:08:40.929 --> 00:08:43.309 complex subsystems still exist and do their own 00:08:43.309 --> 00:08:46.370 jobs. But the facade hides the chaos from you. 00:08:46.509 --> 00:08:48.429 Next time I buy something online, I will definitely 00:08:48.429 --> 00:08:50.669 be thinking about the facade pattern, so it simplifies 00:08:50.669 --> 00:08:53.190 what is already there. What about extensibility? 00:08:53.830 --> 00:08:56.389 Extensibility, on the other hand, acts as a framework. 00:08:57.049 --> 00:08:59.129 It provides a simple foundation where you are 00:08:59.129 --> 00:09:01.710 meant to plug in your own custom code to extend 00:09:01.710 --> 00:09:05.049 its capabilities. The framework handles all the 00:09:05.049 --> 00:09:07.190 boring, repetitive plumbing like how to connect 00:09:07.190 --> 00:09:10.029 to a server, so you can focus entirely on writing 00:09:10.029 --> 00:09:13.419 the unique features of your specific app. A facade 00:09:13.419 --> 00:09:16.500 simplifies the chaos. An extensibility framework 00:09:16.500 --> 00:09:19.220 gives you a clean slate to build upon. Ah, got 00:09:19.220 --> 00:09:22.419 it. That actually perfectly tees up another translator 00:09:22.419 --> 00:09:24.379 pattern called the bridge pattern. That's a good 00:09:24.379 --> 00:09:27.639 one. Yeah, the core concept here is that it decouples 00:09:27.639 --> 00:09:29.940 an abstraction from its implementation so that 00:09:29.940 --> 00:09:32.820 the two can vary independently, which sounds 00:09:32.820 --> 00:09:35.460 like a lot of jargon, but it is incredibly powerful. 00:09:35.519 --> 00:09:38.559 It really is. You are separating the idea of 00:09:38.559 --> 00:09:40.759 what something does from how it actually does 00:09:40.759 --> 00:09:43.940 it. Right. It is essential for preventing code 00:09:43.940 --> 00:09:47.500 from becoming too rigid. Think about your television 00:09:47.500 --> 00:09:50.360 and your remote control. OK. The remote control 00:09:50.360 --> 00:09:52.940 is the abstraction. It has a volume up button 00:09:52.940 --> 00:09:56.179 and a channel down button. The TV itself contains 00:09:56.179 --> 00:09:58.340 the implementation of the actual computer chips 00:09:58.340 --> 00:10:01.220 that change the channel. The bridge pattern connects 00:10:01.220 --> 00:10:04.340 them. Because they are decoupled, you can completely 00:10:04.340 --> 00:10:06.759 upgrade the internal computer chips of the TV, 00:10:07.220 --> 00:10:09.480 and your old remote control still works perfectly. 00:10:09.820 --> 00:10:11.620 Okay, so we have adapters, facades, and bridges 00:10:11.620 --> 00:10:13.799 making sure all our mismatched pieces can actually 00:10:13.799 --> 00:10:16.279 communicate smoothly. But once you have those 00:10:16.279 --> 00:10:18.519 connections, how do you stack them together to 00:10:18.519 --> 00:10:20.320 build something massive without the whole thing 00:10:20.320 --> 00:10:23.529 crashing down? Let's transition from translating 00:10:23.529 --> 00:10:26.509 to building. This brings us to the composite 00:10:26.509 --> 00:10:29.710 and decorator patterns. These are two very elegant 00:10:29.710 --> 00:10:32.950 solutions to the problem of scale. Let's start 00:10:32.950 --> 00:10:35.750 with the decorator pattern It fundamentally supports 00:10:35.750 --> 00:10:37.909 adding additional functionality to an object 00:10:37.909 --> 00:10:40.389 at runtime. And it specifically prevents the 00:10:40.389 --> 00:10:43.610 issue where subclassing would result in an exponential 00:10:43.610 --> 00:10:47.230 rise of new classes. When I see exponential rise 00:10:47.230 --> 00:10:49.690 of new classes, I immediately think about buying 00:10:49.690 --> 00:10:52.049 a car at a dealership. Oh, that's a great analogy. 00:10:52.509 --> 00:10:55.690 Imagine you are a software engineer programming 00:10:55.690 --> 00:10:59.289 a car manufacturer's inventory system. You start 00:10:59.289 --> 00:11:01.799 with a base model car. That is your blueprint 00:11:01.799 --> 00:11:04.399 or your class. Right. Now a customer wants a 00:11:04.399 --> 00:11:06.980 red car. So you write a whole new red car blueprint. 00:11:07.419 --> 00:11:09.139 Another customer wants a blue car. So you write 00:11:09.139 --> 00:11:11.919 a blue car blueprint. It gets messy fast. Exactly. 00:11:12.460 --> 00:11:14.620 Because wait, someone wants a red car with a 00:11:14.620 --> 00:11:17.549 sunroof. Now you have to code a unique red car 00:11:17.549 --> 00:11:20.889 with sunroof blueprint, then a blue car with 00:11:20.889 --> 00:11:23.350 leather seats blueprint. The combinations multiply 00:11:23.350 --> 00:11:25.350 endlessly. If you have 50 different options, 00:11:25.409 --> 00:11:28.649 you would literally need millions of unique blueprints 00:11:28.649 --> 00:11:31.409 to cover every possible combination. It's absurd. 00:11:31.649 --> 00:11:33.750 Your application would be completely bloated, 00:11:34.210 --> 00:11:37.350 super slow, and basically impossible to update. 00:11:37.610 --> 00:11:41.070 Exactly. If you had to build a totally new, distinct 00:11:41.070 --> 00:11:43.889 factory blueprint for every single combination 00:11:43.889 --> 00:11:47.440 of paint colors, radio, tires, and seats, your 00:11:47.440 --> 00:11:49.340 code base would be a nightmare. Absolutely a 00:11:49.340 --> 00:11:51.379 nightmare. The decorator pattern is like adding 00:11:51.379 --> 00:11:53.179 those options at the dealership right when you 00:11:53.179 --> 00:11:55.779 buy it. You just take the generic base car object 00:11:55.779 --> 00:11:58.340 and at runtime, meaning while the program is 00:11:58.340 --> 00:12:00.519 actually running live, not when the programmer 00:12:00.519 --> 00:12:03.299 is typing the code, you dynamically decorate 00:12:03.299 --> 00:12:05.899 it with a red paint job module, and then you 00:12:05.899 --> 00:12:07.980 decorate it again with a sunroof module. You 00:12:07.980 --> 00:12:10.700 completely prevent that exponential explosion 00:12:10.700 --> 00:12:12.559 of blueprints. Right, and if we connect this 00:12:12.559 --> 00:12:15.509 to the bigger picture, It really highlights the 00:12:15.509 --> 00:12:18.590 genius of dynamic behavior in software. How so? 00:12:18.769 --> 00:12:21.029 You're keeping the code for the car entirely 00:12:21.029 --> 00:12:23.570 separate from the code for the sunroof until 00:12:23.570 --> 00:12:25.549 the exact millisecond they need to be joined 00:12:25.549 --> 00:12:28.090 together. Wow. Now consider how we group those 00:12:28.090 --> 00:12:29.990 objects together using the composite pattern. 00:12:30.409 --> 00:12:32.610 This is defined as a tree structure of objects 00:12:32.610 --> 00:12:34.950 where every single object has the exact same 00:12:34.950 --> 00:12:37.730 interface. A tree structure where every object 00:12:37.730 --> 00:12:40.460 has the same interface. Explain the power of 00:12:40.460 --> 00:12:42.059 that to me because it sounds a little abstract. 00:12:42.440 --> 00:12:44.840 Sure. Think about the file system in your computer 00:12:44.840 --> 00:12:47.279 right now. Okay. You can have a single document 00:12:47.279 --> 00:12:50.860 file, or you can have a folder that contains 00:12:50.860 --> 00:12:54.779 10 document files, or you can have a master folder 00:12:54.779 --> 00:12:57.519 that contains 10 other folders which each contain 00:12:57.519 --> 00:13:00.740 hundreds of files. Right. In a composite pattern, 00:13:01.019 --> 00:13:04.019 the operating system treats a single leaf, one 00:13:04.019 --> 00:13:07.100 tiny document, and an entire branch. a massive 00:13:07.100 --> 00:13:09.559 folder full of folders exactly the same way. 00:13:09.779 --> 00:13:12.039 They share the same interface. Oh, so the system 00:13:12.039 --> 00:13:13.799 doesn't have to stress about what it's looking 00:13:13.799 --> 00:13:15.919 at. Exactly. You can click Delete on a single 00:13:15.919 --> 00:13:18.279 text file, or you can click Delete on a massive 00:13:18.279 --> 00:13:20.779 master folder, and the system executes the exact 00:13:20.779 --> 00:13:23.019 same underlying command. That's amazing. Yeah. 00:13:23.240 --> 00:13:25.100 It doesn't need to write custom logic to figure 00:13:25.100 --> 00:13:28.419 out if it's looking at one tiny object or a massive 00:13:28.419 --> 00:13:30.799 sprawling tree of objects. It just issues the 00:13:30.799 --> 00:13:33.740 command, and the structure handles the execution 00:13:33.740 --> 00:13:35.850 down the chain. That is incredibly efficient. 00:13:36.169 --> 00:13:38.070 And there is a closely related concept called 00:13:38.070 --> 00:13:40.350 the aggregate pattern, right? Yes, there is. 00:13:40.490 --> 00:13:43.190 which is a version of that composite tree, but 00:13:43.190 --> 00:13:46.029 it specifically includes methods for aggregating 00:13:46.029 --> 00:13:49.590 or gathering up all those child objects together. 00:13:50.129 --> 00:13:52.549 So if you need to calculate the total file size 00:13:52.549 --> 00:13:55.889 of that massive folder, the aggregate pattern 00:13:55.889 --> 00:13:58.289 lets the system traverse that sprawling tree 00:13:58.289 --> 00:14:01.049 structure efficiently without getting lost. Precisely. 00:14:01.429 --> 00:14:04.590 It turns a chaotic web of data into a neatly 00:14:04.590 --> 00:14:07.370 organized hierarchy. Here's where it gets really 00:14:07.370 --> 00:14:09.830 interesting. Because once we have built this 00:14:09.830 --> 00:14:12.129 massive tree of code, and we have decorated it 00:14:12.129 --> 00:14:13.950 with all these runtime features, it is going 00:14:13.950 --> 00:14:17.529 to be incredibly heavy. How do these structural 00:14:17.529 --> 00:14:20.110 patterns optimize the system so it doesn't just 00:14:20.110 --> 00:14:22.330 instantly max out your RAM and crash your computer, 00:14:22.809 --> 00:14:25.450 or leak sensitive information to hackers? We 00:14:25.450 --> 00:14:28.529 are moving into the realm of efficiency, secrets, 00:14:28.690 --> 00:14:31.029 and traffic control. Which is where software 00:14:31.029 --> 00:14:33.129 engineering starts to... look a lot less like 00:14:33.129 --> 00:14:35.110 architecture and a lot more like high -speed 00:14:35.110 --> 00:14:37.009 logistics. Let's talk about the flyweight pattern. 00:14:37.269 --> 00:14:39.690 This is used when a large quantity of objects 00:14:39.690 --> 00:14:42.750 share a common property's object to save space. 00:14:42.970 --> 00:14:46.289 This instantly screams open -world video games 00:14:46.289 --> 00:14:49.509 to me. Think about an expansive game with a massive, 00:14:50.029 --> 00:14:53.169 dense digital forest. Right. If the game engine 00:14:53.169 --> 00:14:57.009 tries to load 10 ,000 completely unique, massively 00:14:57.009 --> 00:14:59.649 detailed, high -resolution tree objects into 00:14:59.649 --> 00:15:02.470 your computer's memory all at once, your graphics 00:15:02.470 --> 00:15:05.029 card will literally melt. It would completely 00:15:05.029 --> 00:15:07.730 overwhelm the hardware. Just... instantly. So 00:15:07.730 --> 00:15:10.750 instead the game loads one single tree blueprint 00:15:10.750 --> 00:15:13.570 into memory. That is the flyway. Yes. Then it 00:15:13.570 --> 00:15:16.129 just references that one blueprint 10 ,000 times, 00:15:16.149 --> 00:15:18.129 maybe just changing the mathematical coordinates 00:15:18.129 --> 00:15:21.570 for where each tree is planted. It saves an unbelievable 00:15:21.570 --> 00:15:24.529 amount of digital space. It really does. It is 00:15:24.529 --> 00:15:26.730 the ultimate exercise in memory conservation. 00:15:27.009 --> 00:15:29.289 What you are doing is splitting the object state 00:15:29.289 --> 00:15:31.649 in half. Okay, break that down. You isolate the 00:15:31.649 --> 00:15:33.870 intrinsic properties, the heavy things, that 00:15:33.870 --> 00:15:35.990 are exactly the same for every single tree like 00:15:35.990 --> 00:15:37.860 the the 3D mesh and the high -res texture of 00:15:37.860 --> 00:15:40.779 the bark. You load that once. Got it. Then the 00:15:40.779 --> 00:15:42.940 extrinsic properties, the lightweight stuff that 00:15:42.940 --> 00:15:45.399 changes, like its X and Y coordinates on the 00:15:45.399 --> 00:15:48.299 map, are calculated separately. That is so smart. 00:15:48.399 --> 00:15:50.080 But then I hit this next term and I have to ask 00:15:50.080 --> 00:15:51.919 you about it because it caught me completely 00:15:51.919 --> 00:15:56.220 off guard. What is it? Tombstone. A tombstone 00:15:56.220 --> 00:15:59.480 is defined as an intermediate lookup object that 00:15:59.480 --> 00:16:02.460 contains the real location of an object. That 00:16:02.460 --> 00:16:05.419 sounds incredibly morbid for coding. Why on earth 00:16:05.419 --> 00:16:07.980 do programmers call an intermediate lookup object 00:16:07.980 --> 00:16:11.720 a tombstone? I mean, it is definitely a colorful 00:16:11.720 --> 00:16:14.179 piece of developer jargon. But to understand 00:16:14.179 --> 00:16:17.120 why it is so clever, you really have to understand 00:16:17.120 --> 00:16:20.059 a process called garbage collection. OK, I'm 00:16:20.059 --> 00:16:23.529 listening. In complex software, memory is constantly 00:16:23.529 --> 00:16:26.049 moving around. When you close a tab in your browser, 00:16:26.210 --> 00:16:28.450 the system deletes that data and shifts other 00:16:28.450 --> 00:16:31.470 data around to free up RAM. It's constantly cleaning 00:16:31.470 --> 00:16:34.769 up after itself. OK, so the actual physical location 00:16:34.769 --> 00:16:37.549 of data in the memory chips is constantly changing. 00:16:37.870 --> 00:16:40.970 Right. Now imagine a hundred different parts 00:16:40.970 --> 00:16:43.129 of your phone's operating system are all pointing 00:16:43.129 --> 00:16:45.919 to a specific piece of data. If that data suddenly 00:16:45.919 --> 00:16:48.480 gets moved by the garbage collector to save space, 00:16:48.940 --> 00:16:51.059 you would have to track down all 100 pointers 00:16:51.059 --> 00:16:52.580 and update their coordinates. It would bring 00:16:52.580 --> 00:16:56.240 the system to grinding halt. Wow, yeah. So instead, 00:16:56.539 --> 00:16:58.659 everyone points to the tombstone. The tombstone 00:16:58.659 --> 00:17:01.580 is planted in the ground. Its location never, 00:17:01.580 --> 00:17:05.700 ever changes. But inside the tombstone is a little 00:17:05.700 --> 00:17:08.200 dynamic note that keeps track of where the real 00:17:08.200 --> 00:17:11.359 data is currently hiding. Oh. So the data can 00:17:11.359 --> 00:17:14.019 move around 1 ,000 times a second, but the system 00:17:14.019 --> 00:17:16.700 never loses it because it just asks the unmoving 00:17:16.700 --> 00:17:19.559 tombstone where it went. Exactly. That is brilliant. 00:17:20.019 --> 00:17:22.019 And speaking of keeping track of things securely, 00:17:22.339 --> 00:17:24.619 there are several patterns that act almost like 00:17:24.619 --> 00:17:27.380 bouncers or secret keepers for the system. Oh, 00:17:27.380 --> 00:17:29.599 for sure. We have the opaque pointer, which is 00:17:29.599 --> 00:17:31.859 a pointer to an undeclared or private type to 00:17:31.859 --> 00:17:35.220 hide implementation details. And we have the 00:17:35.220 --> 00:17:37.859 proxy pattern, which is a class functioning as 00:17:37.859 --> 00:17:39.960 an interface to another thing. Both of these 00:17:39.960 --> 00:17:42.059 are fundamentally about protection and control. 00:17:43.220 --> 00:17:45.640 An opaque pointer ensures that outside parts 00:17:45.640 --> 00:17:48.500 of the program can pass a piece of data around 00:17:48.500 --> 00:17:50.839 without ever being able to peek inside and see 00:17:50.839 --> 00:17:53.680 the complex private mechanics going on. Oh, I 00:17:53.680 --> 00:17:56.539 see. It is opaque. You literally cannot see through 00:17:56.539 --> 00:17:58.900 it. Yeah. This prevents developers from accidentally 00:17:58.900 --> 00:18:01.579 messing with core system files. Makes sense. 00:18:01.839 --> 00:18:05.279 And what about the proxy? A proxy acts as a digital 00:18:05.279 --> 00:18:07.700 stand -in. They have it like a personal assistant 00:18:07.700 --> 00:18:10.099 to a very busy CEO. You don't get to talk to 00:18:10.099 --> 00:18:12.059 the CEO directly. You talk to the proxy. Right. 00:18:12.400 --> 00:18:14.259 The proxy can check your security credentials 00:18:14.259 --> 00:18:16.480 before it lets your request pass through to the 00:18:16.480 --> 00:18:19.900 main database. Or it could be used for lazy loading. 00:18:20.240 --> 00:18:22.539 Lazy loading. Yeah. If you open a massive web 00:18:22.539 --> 00:18:25.480 page with 100 high -res images, the proxy acts 00:18:25.480 --> 00:18:29.119 as a lightweight placeholder box. It delays actually 00:18:29.119 --> 00:18:31.579 downloading the heavy image file until you scroll 00:18:31.579 --> 00:18:33.779 down and actually look at it, saving massive 00:18:33.779 --> 00:18:35.640 amounts of bandwidth. That makes a web. feels 00:18:35.640 --> 00:18:38.339 so much faster. We also have a marker interface 00:18:38.339 --> 00:18:40.599 pattern, which is described as an empty interface 00:18:40.599 --> 00:18:43.460 used to associate metadata with a class. At first, 00:18:43.460 --> 00:18:45.720 I thought, why would anyone write an interface 00:18:45.720 --> 00:18:48.640 that is completely empty? But it is essentially 00:18:48.640 --> 00:18:51.319 just slapping a digital sticky note on an object, 00:18:51.460 --> 00:18:54.559 right? Exactly. By passing an object through 00:18:54.559 --> 00:18:57.299 an empty marker interface, you aren't changing 00:18:57.299 --> 00:18:59.859 the object's code at all. You are changing how 00:18:59.859 --> 00:19:03.210 the compiler treats it. Oh. It is a signal to 00:19:03.210 --> 00:19:05.470 the underlying system. For example, it might 00:19:05.470 --> 00:19:08.509 say, hey, this specific customer data object 00:19:08.509 --> 00:19:11.309 is marked as safe to be serialized and saved 00:19:11.309 --> 00:19:14.069 permanently to a hard drive, which protects other 00:19:14.069 --> 00:19:16.329 unmarked temporary data from being accidentally 00:19:16.329 --> 00:19:19.279 written to disk. That's super clever. And finally, 00:19:19.420 --> 00:19:21.339 in this section of traffic control, we have pipes 00:19:21.339 --> 00:19:24.460 and filters. This is a chain of processes where 00:19:24.460 --> 00:19:27.079 the output of each process is the input of the 00:19:27.079 --> 00:19:29.759 next. The ultimate digital assembly line. Exactly. 00:19:30.160 --> 00:19:32.900 Think of a stream of raw data coming into an 00:19:32.900 --> 00:19:35.279 app. It goes in one end, it hits a filter that 00:19:35.279 --> 00:19:37.640 removes any spam characters, the output flows 00:19:37.640 --> 00:19:40.400 into the next pipe, it hits a filter that capitalizes 00:19:40.400 --> 00:19:43.059 the names. And the finished, polished data comes 00:19:43.059 --> 00:19:47.069 out the other end. Yeah. So... Having zoomed 00:19:47.069 --> 00:19:50.329 in on all these intricate hidden mechanics, the 00:19:50.329 --> 00:19:53.150 adapters translating languages, the decorators 00:19:53.150 --> 00:19:55.509 dynamically adding features, the flyweight saving 00:19:55.509 --> 00:19:57.910 our graphics cards, we really need to zoom out. 00:19:57.910 --> 00:20:01.730 We do. Because the broader ecosystem these structural 00:20:01.730 --> 00:20:05.410 patterns live in is vast. It's massive. We have 00:20:05.410 --> 00:20:08.029 really only been exploring one specific neighborhood 00:20:08.029 --> 00:20:11.589 in a sprawling metropolis of kind. Right. Beyond 00:20:11.589 --> 00:20:14.049 structural patterns, the Gang of Four and others 00:20:14.049 --> 00:20:16.569 defined creational patterns, which handle how 00:20:16.569 --> 00:20:18.589 objects are birthed into existence, like the 00:20:18.589 --> 00:20:22.150 abstract factory or the singleton, and behavioral 00:20:22.150 --> 00:20:24.369 patterns, which handle how objects communicate, 00:20:24.390 --> 00:20:26.289 like the observer and the visitor. But then it 00:20:26.289 --> 00:20:28.509 keeps going. Oh, it really does. We have concurrency 00:20:28.509 --> 00:20:30.450 patterns, which manage multiple things happening 00:20:30.450 --> 00:20:32.869 at the exact same time, with wild names, like 00:20:32.869 --> 00:20:36.170 double check locking, thread pool, balking, and 00:20:36.170 --> 00:20:38.650 semaphore. We have architectural patterns, like 00:20:38.650 --> 00:20:42.230 MVC, publish subscribe. and naked objects, which 00:20:42.230 --> 00:20:45.269 sounds completely absurd but actually refers 00:20:45.269 --> 00:20:48.109 to a pattern that automatically generates a user 00:20:48.109 --> 00:20:50.650 interface directly from the core business logic, 00:20:51.130 --> 00:20:53.349 stripping away all the middle layers so the objects 00:20:53.349 --> 00:20:55.990 are completely exposed or naked to the user. 00:20:56.400 --> 00:20:59.140 It is a comprehensive, continuously evolving 00:20:59.140 --> 00:21:02.279 catalog of human problem solving in the digital 00:21:02.279 --> 00:21:05.640 space. But looking at this dizzying list of terms 00:21:05.640 --> 00:21:08.220 from balking to naked objects, I have to ask. 00:21:08.220 --> 00:21:10.440 Sure, what's that? If we have this perfectly 00:21:10.440 --> 00:21:13.000 mapped out universe of patterns for literally 00:21:13.000 --> 00:21:15.819 every possible scenario, does that mean software 00:21:15.819 --> 00:21:18.619 engineering is just paint by numbers now? Do 00:21:18.619 --> 00:21:20.880 developers just look at a problem, pick a pattern 00:21:20.880 --> 00:21:22.779 off the shelf, plug it in, and clock out for 00:21:22.779 --> 00:21:25.200 the day? This raises an important question about 00:21:25.200 --> 00:21:27.220 what these patterns actually represent in the 00:21:27.220 --> 00:21:29.940 real world. It is very tempting to think of them 00:21:29.940 --> 00:21:32.240 as automated assembly lines, where you just push 00:21:32.240 --> 00:21:34.700 a button and the software writes itself. Right, 00:21:34.799 --> 00:21:37.480 that's what it sounds like. But that is a massive 00:21:37.480 --> 00:21:40.660 misconception. Patterns are a shared vocabulary. 00:21:41.240 --> 00:21:43.920 They're highly conceptual blueprints, not lines 00:21:43.920 --> 00:21:47.259 of pre -written code. Just because you have a 00:21:47.259 --> 00:21:49.000 dictionary and know all the words in the English 00:21:49.000 --> 00:21:51.319 language doesn't mean you can instantly sit down 00:21:51.319 --> 00:21:53.420 and write a Pulitzer Prize -winning novel. Oh, 00:21:53.460 --> 00:21:55.140 that's a great way to put it. You still have 00:21:55.140 --> 00:21:57.599 to know how to weave the narrative together with 00:21:57.599 --> 00:22:01.119 style and context. Exactly. Knowing the decorator 00:22:01.119 --> 00:22:03.660 pattern or the proxy pattern allows a senior 00:22:03.660 --> 00:22:06.039 engineer to communicate a complex architectural 00:22:06.039 --> 00:22:09.160 idea to a junior developer in two words instead 00:22:09.160 --> 00:22:11.319 of a two -hour whiteboard presentation. Wow, 00:22:11.559 --> 00:22:13.900 yeah. But the engineer still has to possess the 00:22:13.900 --> 00:22:16.079 skill the critical judgment, and the creativity 00:22:16.079 --> 00:22:19.079 to implement that pattern effectively within 00:22:19.079 --> 00:22:21.539 the unique constraints of their specific system. 00:22:22.500 --> 00:22:24.539 They are incredibly sharp tools in the toolbox, 00:22:25.059 --> 00:22:28.019 but they are not the carpenter. So what does 00:22:28.019 --> 00:22:31.039 this all mean? We started this deep dive talking 00:22:31.039 --> 00:22:33.059 about the invisible structures that surround 00:22:33.059 --> 00:22:35.299 us, the blueprints of the modern digital world. 00:22:36.799 --> 00:22:39.019 Through the philosophy of the Gang of Four and 00:22:39.019 --> 00:22:41.259 architectural pioneers like Christopher Alexander, 00:22:41.819 --> 00:22:45.059 we have seen how applying strict abstract constraints 00:22:45.059 --> 00:22:48.500 to code actually enables infinite safe creation. 00:22:48.680 --> 00:22:51.519 It does. We explored how adapters and facades 00:22:51.519 --> 00:22:54.559 act as universal translators, bridging the gap 00:22:54.559 --> 00:22:57.619 between ancient databases and modern apps. We 00:22:57.619 --> 00:23:00.039 saw how decorators prevent endless duplication, 00:23:00.460 --> 00:23:03.200 how composites treat massive folders and tiny 00:23:03.200 --> 00:23:05.980 files exactly the same way. And how flyweights 00:23:05.980 --> 00:23:08.450 and tombstones optimize our memory so our phones 00:23:08.450 --> 00:23:11.390 don't freeze up when we open a video game. Exactly. 00:23:11.849 --> 00:23:13.990 The truth is every single time you use a seamless 00:23:13.990 --> 00:23:16.450 mobile app or breeze through a complex e -commerce 00:23:16.450 --> 00:23:19.109 checkout, you are directly benefiting from these 00:23:19.109 --> 00:23:21.450 invisible structural patterns working silently 00:23:21.450 --> 00:23:24.130 in the background to prevent digital chaos. They're 00:23:24.130 --> 00:23:26.849 the quiet unsung heroes of our modern infrastructure. 00:23:27.470 --> 00:23:30.109 Without them, the digital age simply would not 00:23:30.109 --> 00:23:32.059 function. But I want to leave you with one final 00:23:32.059 --> 00:23:34.180 thought. We spent this whole deep dive looking 00:23:34.180 --> 00:23:36.380 at the master blueprints for success. But in 00:23:36.380 --> 00:23:38.720 the world of software engineering, there is a 00:23:38.720 --> 00:23:40.819 dark mirror to everything we just talked about. 00:23:40.960 --> 00:23:42.680 Oh, yes, there is. There is something called 00:23:42.680 --> 00:23:45.259 an anti -pattern. Think about that for a second. 00:23:45.799 --> 00:23:48.640 If structural patterns are the proven mathematically 00:23:48.640 --> 00:23:51.700 sound blueprints that keep the massive invisible 00:23:51.700 --> 00:23:54.019 skyscrapers of our digital world standing tall. 00:23:55.000 --> 00:23:57.480 What does it look like when a massive system 00:23:57.480 --> 00:24:00.019 is accidentally built on an anti -pattern? It's 00:24:00.019 --> 00:24:02.799 not pretty. No, it is a blueprint for failure. 00:24:03.160 --> 00:24:05.839 It is a structural collapse, a digital disaster 00:24:05.839 --> 00:24:08.519 just waiting for a single stress test to bring 00:24:08.519 --> 00:24:11.200 the whole thing crashing down. And as you navigate 00:24:11.200 --> 00:24:13.579 the apps, the websites, and the systems you use 00:24:13.579 --> 00:24:15.259 every single day trying to spot where things 00:24:15.259 --> 00:24:17.220 are holding together beautifully and where things 00:24:17.220 --> 00:24:19.160 are structurally starting to crack and show their 00:24:19.160 --> 00:24:21.759 anti -patterns is a fascinating way to look at 00:24:21.759 --> 00:24:23.140 the invisible world around you.