Well this si not about implementing the interface or extending a class. I thoses cases, you know anyway what you are doing.

However, when a third party code (another module of the application for exemple) manipulate you data, this code should not care if you are presenting an interface or a class.

This is the whole point of abstraction. You are presenting to this third party code an object of a given type. This given type as some member function you can call. That's enough.

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

By the way, interfaces and classes are reference types at the end. And this is what matter. So this is what your naming convention must emphasys.

Well this is not about implementing the interface or extending a class. In thoses cases, you know anyway what you are doing.

However, when third party code (another module of the application for exemple) manipulates you data, this code should not care if you are presenting an interface or a class.

This is the whole point of abstraction. You are presenting to this third party code an object of a given type. This given type has some member function you can call. That's enough.

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code to this third party code.

By the way, interfaces and classes are reference types at the end. And this is what matters. So this is what your naming convention must emphasize.

Well this si not about implementing the interface or extending a class. I thoses cases, you know anyway what you are doing.

However, when a third party code (another module of the application for exemple) manipulate you data, this code should care if you are presenting an interface or a class.

This is the whole point of abstraction. You are presenting to this third party code an object of a given type. This given type as some member function you can call. That's enough.

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

By the way, interfaces and classes are reference types at the end. And this is what matter. So this is what your naming convention must emphasys.

Well this si not about implementing the interface or extending a class. I thoses cases, you know anyway what you are doing.

However, when a third party code (another module of the application for exemple) manipulate you data, this code should not care if you are presenting an interface or a class.

This is the whole point of abstraction. You are presenting to this third party code an object of a given type. This given type as some member function you can call. That's enough.

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

By the way, interfaces and classes are reference types at the end. And this is what matter. So this is what your naming convention must emphasys.