Using the code below as an example
public abstract class Foo<T,V>{
// ...some methods
public interface IFoo<S,U>{
S doSomething(U input);
}
}
class MyClass implements Foo.IFoo<String, Integer>{}
Is calling the interface like that bad OOP or there is nothing wrong with that. Note the interface has different generic parameters from the abstract class.
If I'm writing a class that inherits from another, which implement an interface, should I implement this interface in the child?
class FatherClass implements MyInterface
{
...
}
public class ChildClass extends FatherClass { // Should I implement MyInterface here?
...
}
Implemented interfaces in Parent class are just inherited
so there's no need to copy and paste "implements SomeInterface" on the children classes. It's not necessary, smarter.
Having both the child and the parent implement the same Interface has no additional effect.
It is equivalent to having the parent only implement that interface.
If you have a abstract class and you inherit that class so you have to implement its abstract method. But is this possible to inherit abstract class and don't implements its abstract method.
I got his question in interview and I said No.
It's possible, but the inheriting class will be abstract too.
As all private and public attributes and methods are inherited into a child class from its parent class then why would constructors and destructors be inherited into a child class?
Is there a real life scnario?
In most programming languages constructors and descructors are not inherited automatically. Usually base class can provide one set of constructors and child class can provide another set of constructors.
I think that in most cases abstract derived class should provide the same set of constructor as base class do (i.e. "inherit" constructors from the base class), but concrete derived class can resolve some of base class's constructor arguments and provide more usable set of constructors:
Consider following case. Let suppose we have a base class called BaseWCFProxy that requires string as endpoint name:
abstract class BaseWCFProxy
{
public BaseWCFProxy(string endpointName)
{}
}
class ConcreteProxy : BaseWCFProxy
{
public ConcreteProxy() : base("ConcreteProxyEndPoint") {}
}
But you decide to add additional abstract class between BaseProxy and ConcreteProxy than you should provide the same set of constructors as base class:
class DualChannelBaseProxy : BaseWCFProxy
{
public DualChannelBaseProxy(string enpointName) : base(endpointName) {}
}
So the rule of thumb is: if you write a abstract child you should consider to "inherit" all base classes constructors. If you write a concrete child you can provide separate set of constructors that would be appropriate for your clients.
P.S. We don't have the same issue with destructors because there is no such notion like destructors overloading. And they're inherited by default: i.e. descendant can provide some additional logic but it definitely should call base version.
i have Abstract class
Public class Abstract baseClass
{
public abstract string GetString();
public abstract string GetString1();
}
public class DerivedClass : baseClass
{
public override string GetString()
{
return "test data";
}
public override string GetString1()
{
throw new NotImplementedException();
}
}
In above line of code, i have to implement both abstract method in derived class. But due to some reason i don't want to implement all methods, just one of them like GetString() only. How can it be done?
Thanks
If DerivedClass is going to offer common functionality to other classes, you can mark it as abstract, implement one of the methods here, and then inheritors will only have to implement the remaining method.
If you aren't going to support the other method in a given implementation, you still have to expose the method in your class, but similar to what you have here, you would typically throw a NotSupportedException. For void methods, you could simply return (do nothing).
Finally, if you want to separate out the things that have both methods and those that have only one, you can use interfaces.
public interface IBase
{
string GetString();
}
public interface IBasePlus : IBase
{
string GetStringPlus();
}
You can have one class that implements IBasePlus, but you can supply this to methods that take a parameter of type IBase, in which case you won't see the extra method.
Generally, if you don't implement all the abstract methods then your new class is also an abstract class. To get a concrete class, you need all the methods to be implemented. If you only want/need to implement a subset of the methods, consider using multiple interfaces (one interface with GetString and another with GetString1) rather than an abstract class. Then you can just implement the interfaces with the methods you want to use in the class.
Take the abstract keyword off the other method and provide a default implementation in the base class