3 ms·

I too enjoy C# a lot and find Typescript close to perfect (obviously it is constrained by its relation to Javascript past, present and future). That said, a bi

I too enjoy C# a lot and find Typescript close to perfect (obviously it is constrained by its relation to Javascript past, present and future). That said, a bit more about why the I feel the I convention is unneeded and even a problem: - If one doesn't use a powerful IDE when using either C#, Java or even Typescript there is a fair chance one is doing something wrong. (I allow for exceptions for people who are so insanely smart that they need the lack of support as a brake for their brains ;-) Powerful IDEs can tell you just fine what is a class and what is an interface. - In what I think of as well written Java projects (and C# many projects for that matter) you'll often feel what is an interface and what is a list just by the name anyway: Javas List that you mention is a perfect example: List is the general concept of a List in Java. ArrayList, LinkedList etc are implementations of that. Once you get used to this convention it is hard to even recognize it until you sit down and try to explain it to someone.) - Contrary, prefixing with I (typical .Net style) or suffixing with Interface (something I've seen in older Java projects) these days[1] encourages lazy naming and unnecessary duplication: If there is only one interface, just write a class and let the interface be implicit. Especially in Java, but also in C# and Typescript refactoring is so trivial (unless you are changing an external API that other people already depend on) that you can just create an interface with the same name and rename the class later if you need it; there's no reason to worry about it up front. [1]: "these days" added as a qualifier since it used to be that certain older systems required you to write one or more interfaces for each class.

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;

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;