When I write clean code this is the single most important rule that I follow.
So if you are intrigued make sure to hit that SUBSCRIBE button because today we are going to
tackle the first principle in the SOLID Principles and that is the Single Responsibility Principle.
So let's open up Xcode and let's dive in. The Single Responsibility Principle is one of the
five of the SOLID Principles and I adhere to the SOLID Principles each and every day.
So I highly encourage you to take a look at this video about its first principle it is
the Single Responsibility Principle and make sure to check out the link in the description for the
whole playlist. ow before we dive into the Single Responsibility Principle and why it matters quite
a lot for you to write clean code let me remind you about DEV_FACTORY. It is at rebeloper.com/mentoring.
A 60-minute Zoom call with yours truly where you can ask questions about Swift, SwiftUI
and maybe if you have a bug in your code I can help you with that. Again it's at rebeloper.com/mentoring.
And let's just take a look at what the single responsibility principle is all about.
Well it states that there should never be more than one reason for a class to change. Now we are going
to dive deep into this explanation, we are going to have a before and after code. So make sure you take
a look at this video till the end but let me just remind you what actually SOLID is. So SOLID is the
five golden rules of clean code that I use. Now what is SOLID? SOLID is one of the most popular
sets of design principles in object-oriented software development and as you know
I has been object oriented for a while, now with SwiftUI it's a little bit different but all
of these principles do apply. Now what is solid? The principles are a subset of many principles
promoted by american software engineer Robert C Martin slash uncle Bob first introduced in his
2000 paper design principles and design patterns. Now SOLID is an acronym introduced
later around 2004 by Michael Feathers. Now what does the SOLID stand for? These are the five
golden rules, five design principles. Single Responsibility Principle which we will cover
today. Open Closed, Liskov Substitution, Interface Segregation and Dependency Inversion. Now if you do
want to take a look at these most importantly the second one, Open Close Principle make sure
to watch this video till the end where I tell you where you can find the next video for the
Open Closed Principles. Now why do we want to have SOLID? Well we want to avoid bad architecture and
it's all about fragility, immobility, and rigidity and I talked a lot about
this in the first video of this series. So go ahead and check out the playlist on this part.
These principles establish practices that lend to developing software with considerations
for maintaining and extending as the project goes. So if you do want to write some code
that is maintainable and extendable you do want your adear or to all over these
principles and the first one that we are going to cover today with a before and after example in
Swift is the Single Responsibility Principle there should never be more than one reason for
a class to change. Now here's the Wikipedia extract in some of his talks he Robert C Martin
also argues that the principle is in particular about roles or actors. For example while they might
be the same person the role of an accountant is different from a database administrator.
Hence, each module should be responsible for each role. Now this might be cryptic for now but
let's jump into Xcode and let's find out how all of this plays out in code. So what I've done here
is just open up a brand new vanilla SwiftUI Xcode project and it doesn't really matter you
could just use playgrounds for this but make sure that you are going to download the resources.
The link is in the description and what you have to do is just drag and drop this folder
right over here and let's just click on finish. Now this is just structure. So there aren't,
there isn't any code. We are going to fill all of this out throughout this series. Now as you can
see there is a before and after. There are these two files here and basically that's it, before
and after. Now in the after I do have a little bit of explanation what
the principle is all about. Now let's take a look at how we would just write out this before and for
this principle the Single Responsibility Principle to be really understandable we are going to create
a data handler and I'm going to have a file private class so we can just use the
data handler class name in the other file also. So what would this data handler do? Well it would
just first of all load some data. So func load data and that would just give us back some data
and let's just go and return some data. So this is just kind of fictional. So it's not going to be
real code but it will be of course valid code. So we are going to load that data and
maybe we want to also parse the data. So parse and let's just add in here the data of type
data and that will throw us back any. So return us any not throwing it and let's just return
an empty string for simplicity and finally we want to save. Save that model. So save our
model that we got from the data and that is of type any and yeah we are going to save here.
Okay! So these are the three things that I do want to the data handler to do and therefore I just
create a function that will encompass all of these three and handle, well handle.
That's fine. Data handler handles the data. So first of all we create our data. So let data equals load data.
So now that we've got this we want to parse it. So let list we are going to let's say
parse that data like so and then finally we want to save that. So save our list, okay. So actually
if you hit Command + B this will build successfully this is, okay this is fine. There's no issues here
with the actual code parsing, but it violates the single responsibility principle meaning that this
class has more than one responsibility. So it's responsible loading for loading the data parsing
that data and saving the model code from that data. So it's not good. So this will not be maintainable
and of course expandable. So let's take a look at the after code how we would need to actually write
this and I highly encourage you to learn this if you are learning anything from the single,
from the SOLID Principles this first one is a must. So the Single Responsibility Principle and
maybe you already are aware of this but yeah this is what what you definitely need to know. So again
let's recap. There should never be more than one reason for a class to change. Meaning a module or a
class should have only one responsibility and that responsibility should be entirely encapsulated
by that module. So you need to encapsulate it, okay. So first of all let's create our, let's we
are having an API handling parsing and then let's say saving to storage. So let's create our create
those three separate entities that are encapsulating at that functionality.
So again I'm going to have file private classes here. So file private class and let's just go
API handler. So this is where we are going to load the data. So let's just go func and it will
return us back our data, okay. I just missed that arrow there, okay. So we are going to return
some data, okay. So that's our API handler. It does one thing and it does it encapsulated.
So the next up is our parse handler. So again let's have a file private class and parse
handler will be our class name. Here we are going to add our function of parsing the data. So parse
data of type data and it will give us back something anything actually and
let's just return that empty string again like we did in the previous example.
Finally you most probably are expecting this, it should be a class of let's say storage
handler and handler, there we go. And that will save it.
So func save our model
of type any and we are going to save here, okay. So as you can see they are
really encapsulating one functionality. So this entity, these entities actually they
are all responsible for one thing and one thing only. Now of course we do want to have these in
sequence, so let's create grade our data handler. So file private class again and that is data
handler and now it comes handy that I'm making these file privates. So the data handler class
name will not complain Xcode will not complain about duplicate class names here.
So what do we want to do here? Well we want to actually create all of these handlers and maybe
create an initializer for that and then create one thing that this class does and that is handle.
So we're just handling the data. So let me just type it out, it will be straightforward once you
see the code. So we want to ASPI handler and that is of type API handler and we also want a parse
and that is of type parse handler and finally we want to have a storage and
there we go. Storage handler let's just initialize this so I really like classes to be initialized
with our custom initializer. As you can see it's also if because we are not giving it some default
values. We could give them default values but yes we want to have an init right over here.
So init and let's just have our API handler. I'm just going to copy this out so we won't waste time
typing all of these properties out in the initialiser. So we have our parse handler and
then storage, there we go. A typo there and I think I have also a typo on the storage.
So storage handler, there we go. Storage handler, great. So now that we got our storage handlers
let me just copy and paste it in here we want to go, oh storage handler, so we want to go self dot
API handler equals API handler next up is self dot parse handler, parse handler
and finally the storage. So storage handler equals our storage handler, okay. All of our properties
had been initialized and now it's time to take a look at the one thing that this class does
and class does it encapsulate it into this class and that is handled. So func
handle and then we just go and we create let data create our data API handler dot load data
then we just create our model, model equals our parse handler dot, okay we want to parse this.
Parse the data that we got and finally we want to go and save that with the storage.
Storage handler dot save our model, okay. And this is really neat. It's nice, it's understandable
what it does and of course these functionalities are encapsulated into their
own entities, yeah in our cases classes. It's really, really nice. Let's just take a look at the before
just to summarize this. We have a handle that has all of these free things that also are coupled
with this like they are limited to this class only. This breaks the Single Responsibility Principle
because we have multiple responsibilities right over here. So let's create all of these three
classes with one responsibility only and then also kind of the encompassing class which also has
one single responsibility is to handle. So go through all of them. All of the loading
parsing and saving of that data, okay. So there you have it Single Responsibility Principle.
Now this is the first in the SOLID Principles. If you are interested in the next one and that is
the Interface Segregation Principle go ahead and watch this video till the end where I will tell
you where you can find this on our playlist, on our YouTube Channel. Now if you do like these types
of videos go ahead and check out rebeloper.com/mentoring where I can help you with your
Swift code or SwiftUI code for that matter or if you do want to learn SwiftUI or you
just want to chat with me on a 60 minute Zoom code let me know I'm available at rebeloper.com/mentoring.
This is the rule that I follow in all of my coding. The Single Responsibility Principle
is one of the golden rules that I obey to each and every day. So if you do liked it
and you are using it in your code make sure to hit that LIKE button because it helps with the YouTube
algorithm and while you are at it make sure to hit that notification bell so you get notified
of new videos as they do come out. New videos like the next one in the SOLID Principle series and
that is the Open Closed Principle. Go ahead and check it out it's right over here. And if you are
interested in the whole playlist it's right over here and as usual I will see you in the next one.