Instructor: Let's continue
with these important principles, though,
as mentioned before, we already covered
the two most important ones
when it comes to writing clean code.
Nonetheless, let's next have a look
at the interface segregation principle.
What is this principle about?
The interface segregation principles says
that many client-specific interfaces are better
than one general purpose interface.
Now, again, as always, what does this mean?
I got another example for you.
I got a class SQLDatabase
which implements an interface called Database.
Interfaces are a common thing
in object-oriented programming, of course.
Interfaces are contracts which force classes
to implement certain behaviors.
In this case, we are forced to add a connect
and store data method if we implement this interface.
And the SQLDatabase does implement this interface.
Now, everything looks all right here,
but now let's say we don't just have the SQLDatabase,
but instead, we also have is InMemoryDatabase,
which, of course, also is a database,
and therefore, it also makes sense
that we implemented the Database interface.
Hence, we are forced to add a connect and store data method.
And now the problem is that it might make sense
to have a stored data method
because no matter if we are storing data in a SQLDatabase
or in memory, we want to be able to store data
at the end of the day,
but connect, that does not necessarily make sense here.
And InMemoryDatabase, which uses the local memory
for storing data,
doesn't really need to connect anywhere.
So in the end, we have the wrong interface here.
And if that kind of reminds you
of the Liskov substitution principle we had a look at
in the last lecture, that would actually not be a surprise
because here we have the problem
with modeling our data incorrectly
and using the wrong base class in the end.
Now with the interface segregation principle,
we have the problem of having a wrong interface,
which we force onto multiple classes,
even if these classes are not using inheritance at all.
The problem is that our database interface
is a general purpose interface here.
It's tries to cover too many use cases,
connecting and storing data, to be precise.
And we should avoid general purpose interfaces
when following the interface segregation principle.
Instead, we should have multiple,
smaller clients-specific interfaces.
For example, here we could have a database interface
if we wanna keep that name.
But in addition, we could have an interface
which is called RemoteDatabase.
And the connect method, forcing classes
to have a connect method would go into RemoteDatabase.
Then the SQLDatabase class could implement Database
and RemoteDatabase, which in TypeScript, is done like this,
simply by separating interfaces by a comma,
and the InMemoryDatabase only implements
the Database interface and not the RemoteDatabase interface.
Hence, we can delete connect here.
We're not forced to implement it anymore,
and hence, we now have code
which does follow the interface segregation principle.
Now just as with the Liskov substitution principle,
obviously the interface segregation principle
is an important principle
when it comes to writing maintainable and extensible code,
when it comes to writing clean code.
Where it, of course, matters that humans
can read the code quite well,
and that it's easy to understand,
this rule doesn't help us too much.
It also doesn't hurt, and it certainly helps a bit,
but it's not super important.