2 ms·
> Powerful IDEs can tell you just fine what is a class and what is an interface. Yes, but if one is simply reading code from a book or code sample online no su
by DaiPlusPlus 6y ago
> Powerful IDEs can tell you just fine what is a class and what is an interface.
Yes, but if one is simply reading code from a book or code sample online no such IDE benefit exists. Program code should be comprehensible as plaintext. This is why I'm not a fan of overuse of the `var` keyword in C# - or `auto` in C++. (Many people feel forced to use `var` and `auto` in C# and C++ respectively when their program uses horribly complicated generics or template instantiations - this wouldn't be necessary if C# permitted more flexibility with type-aliases.
> List is the general concept of a List in Java
But that's a huge design-issue in itself: Interfaces should not describe what something "is": they should describe what something is capable of - this is doubly essential when using reified generics because of type parameter variance (Java skirts this one because of type-erased generics - which is another discussion). A distinct advantage of interfaces describing capabilities is the "I" prefix can be replaced with a rule requiring interface names to be adjectives (i.e. class/struct = noun, method = verb, interface = adjective+noun).
Rather than having this (invariant) interface:
interface List<T> {
void add( T item );
void remove( T item );
int length { get; }
T get( int index );
}
We'd have these variant interfaces:
interface ReadableList<out T> {
int length { get; }
T get( int index )
}
interface MutableBag<in T> {
void add( T item )
void remove( T item )
}
Which is great because then we can do type-safe stuff like this:
class Vector<T> implements ReadableList<T>, MutableBag<T> {
// etc
}
class Employee extends Person {}
class Boss extends Employee {}
Vector<Employee> list = new Vector<Employee>();
ReadableList<Person> people = list;
MutableBag<Boss> appendOnlyBossesFromHere = list;