Simple Event Dispatcher Example0:00
Let's begin with a discussion on visual debt, or noise, or complexity, or whatever term you want to use. So take a look at this example I have here. It's a basic event dispatcher. Very, very simple. So if we take a look at this, we have a public API that consists of listen and fire. When you call listen, we just save it to an events object. And when you call fire, we find the event, and then for each one, we trigger the associated callback. So this might be a basic implementation here. We new up our dispatcher. We attach some listeners. We're just using string-based events, which is fine. And then we pass closures here to handle when that event is fired.
Defining Visual Debt0:33
We're just using string-based events, which is fine. And then we pass closures here to handle when that event is fired. So in this case, we have two listeners. We fire the event, and if we run it, we get those. All right? Very, very basic. So what do I mean when I say visual debt, or noise, or clutter, or complexity? Everyone has a different word for it. What I'm saying is regardless of what it is, so it could be a keyword, a variable. It could be a class, a namespace, a type, or a PHP type, a return type, a doc block, all of this stuff. They think of them as little tiny nuggets of noise, little tiny nuggets of complexity.
Complexity Default in PHP1:00
It could be a class, a namespace, a type, or a PHP type, a return type, a doc block, all of this stuff. They think of them as little tiny nuggets of noise, little tiny nuggets of complexity. And that doesn't mean they're inherently bad. It means they are micro pieces of noise that will add up over the course of an application. And anyone who has ever found themselves drowning under like a sea of complexity should be familiar with this concept. Now, my worry is in so much of the PHP community, there's a tendency to default to complexity rather than fight for it. So in this case, if I'm just building this for my little app, is there any real justifiable adult reason to make this final? You know, we can read about it in blogs all day, but is it really necessary here? And if you're not familiar, final means you can't subclass this. Inheritance is bad, so I'm going to force you to use composition instead.
Challenging final and Types1:51
And if you're not familiar, final means you can't subclass this. Inheritance is bad, so I'm going to force you to use composition instead. Yep, I'm not your dad. I hate that. So maybe we can get rid of that entirely. Next, we have these type hints or PHP types. Scalar type hint, we have the callable type hint. It's fine. A lot of people swear by them. There's no doubt that it does provide some good documentation when you're reviewing a piece of code. But these are relatively new things, and at the same time, duck typing has been a thing for a very, very long time.
