This content has been marked as final. Show 4 replies
It's possible but the question indicates something wrong with your design. You shouldn't be trying to solve problems like this with the type system. It is rare for classes to represent real world objects like Professors, and that is because roles change: once the Professor was an undergraduate, then he became a post grad, then a tutor, a Master, maybe a Ph.D., a Lecturer, an Associate Professor, and maybe he will become an Emeritus Professor, a Dean, a Vice Chancellor, etc. Using a static type system to represent dynamic information like this cannot work. And devising local overrides of the type system to express the fact that some professors can employ and some can't is also wrong for much the same reason: it isn't what the type system is for. Generally speaking, classes in OO system represent computer abstractions like connections, collections, customers, vendors, invoices, etc.
T002 wrote:If you want to be able to instantiate an object all abstract methods need to be implemented. So no, you don't have any choice. Of course you're free to implement a method and make it do nothing at all, but when you start to do something like that you likely have a very wrong application design and need to rethink it.
I came with the example above to try to explain the concept. Basically what I want to know is.._.can you have a class which implements an interface, and choose whether to use the methods in the interface during instantiation of this class? Therefore having object A which uses the interface and object B which does not use it._
Sorry to make this more complicated, but a better design in this case would be to scrap the Interface class and use instead a super class professor, and then one subclasses, ProfessorA with employ() method?
Instantiating the super class would get us a professor without employment duties, while instantiating the subclass would get us a Professor with employment duties.