Arrive.
So we're going to begin our discussion of the solid design principles by looking at the Single Responsibility
Principle.
So what Single Responsibility Principle basically states is that a class should have a single reason
to change.
In other words a class should have a primary responsibility and it should not take up other responsibilities.
Let me give you an example from the real world let's suppose that I'm a programmer so I'm getting paid
to actually program stuff.
Now this is my primary responsibility of course I can break down my programming efforts into the different
parts.
But my primary responsibility is to program so if somebody comes up to me and asks me to make coffee
for them well that's not my primary responsibility somebody else should make coffee or maybe they should
just go to the coffee machine and make the coffee themselves.
But it's not my responsibility and it's the same idea being propagated to software engineering as well.
So let's suppose that you decide to make a journal class you decided to make a class for replicating
a journo and storing your most intimate thoughts so that you might for example have a title and you
might also have a number of entries which will keep as a vector of strings here.
So having made this kind of journal what we can do is well we can first of all initialize it so make
a constructor which sets the title for example.
But in addition to that what we might want to do is to have functionality for actually adding entries
to the journals so you might have for example a function called an entry which takes a string for the
entry and you might also want to try and be smart about it and actually sort of get the entries numbers.
So you might want to have some sort of counter count like this.
And then when you do add the entries so when you say entries they'll push back you actually constructing
a string which uses not just the entry parameter that we get as part of the function but you also use
this count.
So here I can use the boost lexical cast to cast something into a string just take the count plus set
and give the previous value into a string and then let's put a colon in here and then add the entry.
So this way we get a more informative entry into our journal.
So what I'm doing right now is I'm adding things which are actually relevant to working with a journal
and you would typically initialize it like the following.
So you would make a journal.
So we may as well codea diary not dead diary diary.
That's much better.
And then you would say join those dots join Odiot add entry add entry like so and you would maybe have
an entry.
Let me just scroll down being obscure here.
See you might have an entry called a bug.
And another entry called.
I cried today something I.
So we've got two entries.
They are added to the journal and it is in fact the journo's of responsibility to keep the entries inside
the journal.
However at some point in time let's suppose you want to actually save the journal in a file for example
so what do you do.
Well the wrong way to go about it is to add the load and save functionality right inside the journal.
So in addition to the journal just keeping the entries and maybe allow you to add entries modify entries
remove entries and so on you decide to add another concern.
Another idea called persistence.
So you add a function called Save.
So you go a function called Safe which takes a file name and what it does is it creates an output file
stream with the file name.
And then it goes through all of the entries and somehow saves them to a database so you might have something
for auto e in entries and you would say outbuild file stream E followed by and then line for example
something to that effect.
So the problem with this approach is you now have a separate concern a concern called persistence So
you're adding persistence code into your journal.
Now imagine if you have in addition to a Journo You also have a dozen other the main objects that you
work with and you give every one of them a function called Save in a function called Load and so on
and so forth.
Now the problem with this is that when you want to change persistence you would have to change persistence
in 10 or 20 or however many classes are actually using it instead.
If you want to for example stop stop loading from files and stop saving files and you want to start
using databases instead.
You would have to go through all of this code and change it everywhere which is not good.
So essentially what we do is we do something called separation of concerns.
So essentially we're saying that the journal should take care of the journal entries and the journal
title and it's kind of like a storage mechanism but if you want to Piscis things you need to have a
separate component to separate class so you might for example have a persistence manager like so and
this will be the one central location where the different objects such as journo's for example are loaded
and saved.
And here is where you would add a function similar to this function.
So you would have a function which kind of goes in the same way you might even make it static for example
but you would also specify that you can save a journal so you would see Konst journo Jay.
And then when you go through the entries you go through the entries from that particular journal.
So this is a more robust a more reliable way of actually implementing persistence because what happens
as your persistence manager grows.
You have all the persistence code in a single place and as a result if you did decide to make a change
if you decide that instead of using foster homes for example you go for a database instead what you
simply do is you go into persistence manager and you you refactor it.
You may be make the persistence part of the parts related to where you save the elements you might want
to make in general and have it somewhere else as part of the persistence manager.
So this is the gist of the Single Responsibility Principle.
So the journal has to be responsible for its own title and entries and the way that you work with them
but when it comes to persistence it makes more sense to separate out this concern.
And we have this additional term in programming called separation of concerns.
So the concern related to persistence is actually moved into a separate component and then of course
you can use this component whenever you want to actually save something so instead of saying journal
and not save a sort of diary directx.
So instead of doing this what we essentially do is we make a persistence manager.
So we say persistence manage your PM for example and then we use A.P.M. that save we provide the journo
here and we provide the name of the actual file.
So this is a much better approach and it's made better by adhering to the Single Responsibility Principle.