Episode Details

Okay today. I want to talk about a new principal object oriented principle. I just made up called SFP the single file principle and this is also sort of my way of communicating something without saying SRP single responsibility principle which tends to get people with their torch and pitchforks out or the stone tablets and preach from the mountaintops or be mad about the people preaching for the mountaintops or whatever, you know, there's been a lot of discussion around it.

So I don't really want to talk about it. But basically this is a really practical principle that I'm going to State as such if you are implementing a feature or if you recognize a I'm just going to use the word feature the fancy term would be a reason to change but if you recognize a feature or you're adding a feature in your app, see if you can keep it all to one file if the file is too big.

Then maybe you'd have to think about this in smaller terms and see if there's some features you can keep to one file. This sounds so silly and so obvious but I'm telling you this is actually one of the most valuable patterns that I employ when I'm writing code. So I'll give you a few practical examples and hopefully it'll start to sink in.

So when I started writing Livewire basic, I mean there's a whole other episode to talk about how. How code design emerges rather than as like planned like I don't really plan designs almost ever. I just start writing code that feels right and I just keep following that right feeling and a couple principles and patterns and I start to see when patterns emerge and then I tackle them and refactor and things like that.

I don't think you can really do much planning up front. But anyway started to build Live Wire and certain pattern started to emerge and here was one eye when I was we're going to talk about the make Command the famous make Command where you type artist and. Artisan make Livewire and then the component name.

I had to turn the component name into a class name space because I need to create that file and I also need to convert it into a view name like a blade file name. There's a bunch of other stuff I need to do. What is the name of the component? Is it you know, if it's counter, it's just counter.

What's the name of the class? What's the name of the class name space the full name space the file path the view the view name like Livewire dot counter and the view file clap path like resources views Live Wire, right? So there's a lot of these things so and there's relative paths and there's absolute past.

There's just it goes on and on and I recognized so for the first iteration, I wrote all this logic inside of the command class inside of the class. I wrote called Livewire may come in. And but I forget exactly where I needed it next but maybe I wrote the Livewire component discover, which we can talk about another episode but inside the discoverer I needed to I needed to use a lot of this logic.

So, you know, I had I had an option you have a fork in the road. I could just copy and paste the logic from the command. Or I could make an abstraction abstraction. And what would that be? I don't know. Maybe it would be a trait. Maybe it would be some helper functions. I'm not really sure yet. And as a rule of thumb, I generally just start with copy and pasting I think j-mac talks about the rule of three.

I don't know if that's something he coin, but I've definitely heard it before. And the idea is that an abstraction or something is not duplicated or like you live with one level of duplications. So if you copy and paste code once that's fine, but if you need it for the third time, then you should think about an abstraction.

It's a good rule of thumb and I try to follow that myself but in this instance, so I did that and then another I forget the next thing but I needed it again. Then the meeting in a lot of places and so the question is, how am I going to do? Yo