All right.
So let's try to summarize what we've learnt in this section of the course so we talked about the solid
design principles so it's a good place to summarize them first of all we looked at the Single Responsibility
Principle.
Basically this idea that A-class should only have one reason to change and it's also related to something
called separation of concerns in that if you have a system which is handling different kinds of concerns
it makes sense to put them in different classes so that these can be refactored independently for example
or replaced by something else.
Now the next principle we looked out is the open closed principle that's where we looked at the specification
pattern and we talked about this idea that the classes should be open for extension and closed for modification.
So essentially the idea here is that if you're coming back into an already written or you test the class
and modifying things in order to extend functionality This is probably not the best way to go and you
should consider using the object oriented paradigm and inheritance instead of just modifying existing
code.
Then we looked at the Liskov substitution principle the idea that you should always be able to substitute
a base type for a subtype and we looked at the situation where the violation of this principle leads
to rather unpleasant results.
Then we talked about the interface segregation principle the idea that you shouldn't be putting too
much into an interface.
In the case of swithe That's a protocol that you shouldn't be overloading and you should split a protocol
into separate protocols separate interfaces and thereby you don't force the implementor to put lots
of stubs and throwing exceptions out if not implemented methods.
So this is also related to something called the jargony which is this idea of you ain't going to need
it.
Meaning that you are going to need certain methods implemented so why force other people to implement
the interface in the first place.
Now finally we looked at the dependency inversion principle.
Nothing to do with dependency injection.
Basically this idea that high level modules should not depend on low level ones that you should abstractions
instead and have everything done through abstraction.
So we looked at how code can be refactor to do exactly that.