Understanding SOLID Principles: Interface Segregation Principle

This sounds a little like an intro to writing "Enterprise" code. Essentially each function has to be its own interface. And you probably need some factory functions in addition.

Why not provide a set of static functions for ByteUtils that behave in a specified way and be done with it?

There's more than one language that will quite happy type convert back and forth between a function and an equivalent single-method interface e.g. "a function that returns an int" and "an interface with one method, a function that returns an int".

Though "one method per interface" isn't the aim of the Interface Segregation Principle.

Oh good example. It shows everything that's wrong with OO thinking

I could split the file interface like this, thinking that some modules will want to read only, some people will want to write only (in rare cases you want trim only, but that is obvious except to "enterprise architects" apparently)

Except it's splitting hairs. And my readers can ignore the write interface and my writers can ignore the read interface and that works in most languages.

> This gives the flexibility for the clients to combine the abstractions as they may see fit and to provide implementations without unnecessary cargo.

Your compiler won't let you call an abstract method. It's that simple.

It's not increasing flexibility, it's increasing red tape and maintenance costs.

One of the reasons C# feels more fluid is that they reduced the level of lunacy created by this way of thinking where you create two or three classes to solve a problem that's solvable in 2 lines in other languages

I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas.

S -> don’t write spagetti code.

O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality.

L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’t break stuff.

I -> Make your interfaces tiny.

D -> Dependency inversion to make things testable; because testing is good right?

Well, DI is always a bit contraversial, but at least its easy to say why its good; its just a bit of pain to setup.

The interface segregation has always been the odd one out for me.

One method interfaces? I know the golang best practice folk love that stuff too, but I just find it irritating when I have to work on code that uses it extensively.

Anyone actually explain tangibly why its a good idea?

If you’re using it to defend against workmates who might abuse an interface with too many functions on it... well, thats kind of lame imo.

Sure, mega-interfaces are bad... I guess... but so are objects with massive sets of methods on them. Why the special focus on interfaces?

I don't think the push is for 1 method interfaces.

In C#, a good example is that many many APIs use the IList interface to pass lists around. But that interface contains methods like .Add .Remove .RemoveAt .Insert... So while in most cases, you'd be just fine passing a IReadOnlyList, using the IList interface means that as a user of the API, you have to implement these methods which may have no sense for what you're doing.

And so more often than not, you see things like:

void Add(T element) { throw new Exception("Shouldn't go in there"); }

And actually I've just checked, the ReadOnlyList object itself implements IList (cause IList is so used), and so has these exceptions all over the place: https://goo.gl/G6L9Ko