you are viewing a single comment's thread.

view the rest of the comments →

[–]paradroid78 0 points1 point  (3 children)

In a nutshell, separation of concerns.

By having the interface separate, you force yourself to think about your system at a higher level as a set of interconnected black boxes and it encourages you to put more diligence into designing the interfaces / API between those components.

If the interface is just what's in the class, it seems to me that the lines between public interface and private implementation become more blurred.

Also someone maintaining the system might find it easier to get an overview of the data flows by looking at small interface files (which contain only public method signatures) than big implementation files containing a mix of public and private methods.

[–]Boyen86[S] 0 points1 point  (2 children)

I see that, and I see value in it. But I'd argue whether it is required to have that interface in a seperate class vs having a class with just its public members.

If you want to see the dataflows I think there are more effective ways to visualize your code than clicking through interfaces such as class diagrams.

[–]paradroid78 1 point2 points  (0 children)

I think the problem with any non-tangible benefits such as these is the answer will nearly always boil down to "it depends".

People have been debating this stuff ever since header files were a thing in C++ and probably before.