3 ms·
Interfaces tend to be hard to change, anyway. The more code that relies on them, the harder it is to change them. This includes unit tests. In design, they are
by 6ren 16y ago
Interfaces tend to be hard to change, anyway. The more code that relies on them, the harder it is to change them. This includes unit tests. In design, they are supposed to represent the things that aren't anticipated to change anyway, while allowing change in what's hidden behind them. A huge benefit of interfaces not changing is that everyone else who relies on them is safer. One could argue that difficulty in changing interfaces is a net benefit to the platform, as a whole; and this may be one reason why java (harder to change interfaces) has more 3rd party libraries than lisp (easier to change interfaces).
A huge detriment of interfaces, along with other such back-compatibility, is horrible, horrible, inefficient ugly inelegant stupid code. This is the problem that intel's x86 has, windows has, and java has.
It's a bit like "rich people's problems".
- signa11 16y ago> Interfaces tend to be hard to change, anyway... "taste" matters a lot here imho. starting from a bare minimum set, and growing it organically seems to be one way out of the tar pit.
- deleted 16y ago[deleted]
- singular 16y agoSure, but the big problem with a static structure is that once you are down the road the inevitable 'unknown unknowns' creep in, no matter how tastefully you've designed your interfaces (whether they are literally java/c#/etc. interface types, or class definitions, hierarchies, etc.), and it becomes incredibly difficult to modify things without there being a lot of work involved in fixing things up. I really do think go's 'real interfaces' i.e. types being implicitly convertible to interfaces which have matching method sigs is a tasteful stroke of brilliance, especially for a lowish level language.