Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Please consider the below:
public class A
{
public string MethodA()
{
return "Hello from Class A";
}
}
public class B
{
public void MethodB()
{
ClassA classAObj = new ClassA();
Console.WriteLine(classAObj.MethodA());
}
}
public class C : A
{
public void MethodC()
{
Console.WriteLine(MethodA());
}
}
My question here is, under what circumstance do I create an instance of Class A (as shown in Class B) or inherit the members of the parent class (Class A) as shown in Class C.
I know OOP concepts say use inheritence whenever you want to share the behavior of the members of a parent class in the child class. In this case I'm not changing nor overriding the base class' default definition.
Should I create an object reference to class A or simply inherit Class A?
Both patterns are okay in different situations. Inheritance is an "is" relationship... a dog is an animal. Composition is a has or can relationship. A dog can bark and a dog has four legs.
Practically speaking, it is usually better to prefer composition over inheritance because a class can be composed of several classes while it can only inherit one.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 days ago.
This post was edited and submitted for review 8 days ago.
Improve this question
My question is related to inheritance it.
Let say we have a class called Animal. All animals share some behaviour like walking, pooping, hunting, etc. After few days I decided to add a Fish class that extend Animal class. But here fish swims but does not hunt or walk.
Is it OK to use only some parts of the base class? Because Fish class can still calls walk and hunt but does not execute the behaviour, I guess.
I could go around the problem where i make a function called behaviour in base class and let the child class override it.
Like this:
public class Animal
{
public virtual void behaviour() {
Console.WriteLine("//do something");
}
}
public class GoldFish : Animal
{
public override void behaviour() {
Console.WriteLine("goldfish swims");
}
}
Any suggestion on how should go about this with best practices of programming?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Given the following types:
public interface Interface { }
public abstract class Abstract { }
Why is this:
typeof(Interface).IsAbstract == true;
Note the IsInterface exists to check if it is an interface:
typeof(Abstract).IsInterface == false;
From the docs:
The IsAbstract property returns true in the following cases:
The current type is abstract; that is, it cannot be instantiated, but can only serve as the base class for derived classes. In C#,
abstract classes are marked with the abstract keyword; in Visual
Basic, they are marked with the MustInherit keyword.
The current type is an interface.
So an interface is considered abstract because it cannot be instantiated.
If you want to determine that a type is an abstract class, you should do the following:
typeof(YourType).IsClass && typeof(YourType).IsAbstract
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We Have following interface which contains some methods.
interface MyInterface
{
string FirstName();
string LastName();
string City();
string Location();
}
and this interface we have implemented in our required classes. However, We want to implement Location method only in specific class and not in others. So, which will be the best way to achieve this.
We have tried like below
Create Interface with common methods.
Create abstract class and implement interface in it
Write specific method in abstract class as Virtual
Then override the method in actual class
But the problem here is implementation for other method is going in abstract class and not in the implementation class where we wants it.
Whichever the way we are going to achieve this it has to be same for all classes.
Any help on this appreciated.
Separate your 'MyInterface' into 2 Interfaces and for all classes you don't want the City method they will implement the one without the city method ,example:
interface MyInterface1
{
string FirstName();
string LastName();
string City();
}
interface MyInterface2 : MyInterface1
{
string Location();
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Imagine we have an interface like below:
public interface ISome
{
void MethodOne();
int MethodTwo();
string MethodThree();
}
A class implements the interface:
public class Some : ISome
{
// Implementation...
}
Here is how it may be used:
public class App
{
public App(ISome)
{
// This class needs the whole interface: All three methods
}
}
I have a new requirement and it only needs one method from it: MethodThree and it can use the implementation provided by Some. Now I have 2 options:
Use ISome in the new class, like App uses it. The problem with this is that the new class does not really depend on the whole interface but only one method.
Split the interface like this using inheritance:
public interface INewSome
{
string MethodThree();
}
public interface ISome : INewSome
{
void MethodOne();
int MethodTwo();
}
The benefits of the 2nd option are:
The new class will depend on INewSome
Some still implements the whole interface so existing code will not break.
Unit testing will be much clearer since we know we just need to mock/stub one method in INewSome
Questions
I cannot think of a benefit for option 1 aside from not having to introduce a new interface. Do you know of a benefit with option 1?
Do you have another suggestion?
Am I overlooking anything and is this good/bad design?
what you have done in the option 2 is correct and goes perfectly with the fourth goal which is Interface Segregation Principle
From Wikipedia many client-specific interfaces are better than one general-purpose interface
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have several classes that all implementing an interface:
interface ISample
{
}
class A:ISample
{
}
class B:ISample
{
}
class C:ISample
{
}
and another class that create them based on some situation for example:
class CreateISample
{
ISample Create(string situation )
{
switch(situation )
{
case "create A":
return new A();
case "Create B":
return new B();
case "Create C":
return new C();
}
}
}
What is the best name for this class?
Create ISample is not good, as then I have:
CreateISample.Create("Create A");
which has two Create as part of name. Also CreateISample may do some other things (for example hold some constant values that relates to all instances, or hold a list of created instances and so on). Then CreateISample is not a good name.
Is there any standard for this? I remember that I read a book about design patterns and they suggested a suitable name for this factory pattern.
you are describing the factory pattern http://en.wikipedia.org/wiki/Factory_method_pattern
generally the convention we use is SampleFactory
But don't overthink it. It's really hard to make names like this from samples. for example it is obvious to most people that a square inherrits from shape. so
ShapeFactory.Create("Square");
would make a lot of sense. so look at your problem to see what kind of thing ISample really is. If i makes sense from a business/problem side other programmers who understand the problem can figure it out.