Why inherit a class and not add properties?
up vote
4
down vote
favorite
I found an inheritance tree in our (rather large) code base that goes something like this:
public class NamedEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
public class OrderDateInfo : NamedEntity { }
From what I could gather, this is primarily used to bind stuff on front-end.
For me, this makes sense as it gives a concrete name to the class, instead of relying on the generic NamedEntity
. On the other hand, there is a number of such classes that simply have no additional properties.
Are there any downsides to this approach?
object-oriented-design inheritance
add a comment |
up vote
4
down vote
favorite
I found an inheritance tree in our (rather large) code base that goes something like this:
public class NamedEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
public class OrderDateInfo : NamedEntity { }
From what I could gather, this is primarily used to bind stuff on front-end.
For me, this makes sense as it gives a concrete name to the class, instead of relying on the generic NamedEntity
. On the other hand, there is a number of such classes that simply have no additional properties.
Are there any downsides to this approach?
object-oriented-design inheritance
8
Upside not mentioned: You can distinguish methods that are only relevant toOrderDateInfo
s from those that are relevant to otherNamedEntity
s
– Caleth
6 hours ago
1
For the same reason that if you happened to have, say, anIdentifier
class having nothing to do withNamedEntity
but requiring both anId
andName
property, you wouldn't useNamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.
– Neil
2 hours ago
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I found an inheritance tree in our (rather large) code base that goes something like this:
public class NamedEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
public class OrderDateInfo : NamedEntity { }
From what I could gather, this is primarily used to bind stuff on front-end.
For me, this makes sense as it gives a concrete name to the class, instead of relying on the generic NamedEntity
. On the other hand, there is a number of such classes that simply have no additional properties.
Are there any downsides to this approach?
object-oriented-design inheritance
I found an inheritance tree in our (rather large) code base that goes something like this:
public class NamedEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
public class OrderDateInfo : NamedEntity { }
From what I could gather, this is primarily used to bind stuff on front-end.
For me, this makes sense as it gives a concrete name to the class, instead of relying on the generic NamedEntity
. On the other hand, there is a number of such classes that simply have no additional properties.
Are there any downsides to this approach?
object-oriented-design inheritance
object-oriented-design inheritance
asked 6 hours ago
robotron
1885
1885
8
Upside not mentioned: You can distinguish methods that are only relevant toOrderDateInfo
s from those that are relevant to otherNamedEntity
s
– Caleth
6 hours ago
1
For the same reason that if you happened to have, say, anIdentifier
class having nothing to do withNamedEntity
but requiring both anId
andName
property, you wouldn't useNamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.
– Neil
2 hours ago
add a comment |
8
Upside not mentioned: You can distinguish methods that are only relevant toOrderDateInfo
s from those that are relevant to otherNamedEntity
s
– Caleth
6 hours ago
1
For the same reason that if you happened to have, say, anIdentifier
class having nothing to do withNamedEntity
but requiring both anId
andName
property, you wouldn't useNamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.
– Neil
2 hours ago
8
8
Upside not mentioned: You can distinguish methods that are only relevant to
OrderDateInfo
s from those that are relevant to other NamedEntity
s– Caleth
6 hours ago
Upside not mentioned: You can distinguish methods that are only relevant to
OrderDateInfo
s from those that are relevant to other NamedEntity
s– Caleth
6 hours ago
1
1
For the same reason that if you happened to have, say, an
Identifier
class having nothing to do with NamedEntity
but requiring both an Id
and Name
property, you wouldn't use NamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.– Neil
2 hours ago
For the same reason that if you happened to have, say, an
Identifier
class having nothing to do with NamedEntity
but requiring both an Id
and Name
property, you wouldn't use NamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.– Neil
2 hours ago
add a comment |
2 Answers
2
active
oldest
votes
up vote
12
down vote
This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names
The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
add a comment |
up vote
9
down vote
This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity
as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo
. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo)
and hope and pray no one abuses the type system to shove a FooBazNamedEntity
in there. Or you could just write void MyMethod(OrderDateInfo foo)
. Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.
Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e)
. More likely you want to catch a SqlException
or a FileNotFoundException
or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception
class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.
Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object
, but that would just make your job harder, wouldn't it?
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names
The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
add a comment |
up vote
12
down vote
This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names
The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
add a comment |
up vote
12
down vote
up vote
12
down vote
This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names
The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.
This is my favorite use of inheritance. I use it mostly for exceptions that could use better, more specific, names
The usual issue of inheritance leading to long chains and causing the yo-yo problem doesn't apply here since there is nothing to motivate you to chain.
edited 5 hours ago
answered 5 hours ago
candied_orange
51.1k1692180
51.1k1692180
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
add a comment |
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
Hmm, good point re exceptions. I was going to say it was a horrible thing to do. But you have persuaded me otherwise with an excellent use case.
– David Arno
3 hours ago
add a comment |
up vote
9
down vote
This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity
as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo
. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo)
and hope and pray no one abuses the type system to shove a FooBazNamedEntity
in there. Or you could just write void MyMethod(OrderDateInfo foo)
. Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.
Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e)
. More likely you want to catch a SqlException
or a FileNotFoundException
or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception
class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.
Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object
, but that would just make your job harder, wouldn't it?
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
add a comment |
up vote
9
down vote
This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity
as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo
. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo)
and hope and pray no one abuses the type system to shove a FooBazNamedEntity
in there. Or you could just write void MyMethod(OrderDateInfo foo)
. Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.
Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e)
. More likely you want to catch a SqlException
or a FileNotFoundException
or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception
class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.
Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object
, but that would just make your job harder, wouldn't it?
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
add a comment |
up vote
9
down vote
up vote
9
down vote
This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity
as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo
. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo)
and hope and pray no one abuses the type system to shove a FooBazNamedEntity
in there. Or you could just write void MyMethod(OrderDateInfo foo)
. Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.
Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e)
. More likely you want to catch a SqlException
or a FileNotFoundException
or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception
class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.
Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object
, but that would just make your job harder, wouldn't it?
This is something that I use to prevent polymorphism from being used. Say you have 15 different classes that have NamedEntity
as a base class somewhere in their inheritance chain and you are writing a new method that is only applicable to OrderDateInfo
. You could just write the signature as void MyMethodThatShouldOnlyTakeOrderDateInfos(NamedEntity foo)
and hope and pray no one abuses the type system to shove a FooBazNamedEntity
in there. Or you could just write void MyMethod(OrderDateInfo foo)
. Now that is enforced by the compiler. Simple, elegant and doesn't rely on people not making mistakes.
Also, as @candied_orange pointed out, exceptions are a great case of this. Very rarely (and I mean very, very, very rarely) do you ever want to catch everything with catch (Exception e)
. More likely you want to catch a SqlException
or a FileNotFoundException
or a custom exception for your application. Those classes often times don't provide any more data or functionality than the base Exception
class, but they allow you to differentiate what they represent without having to inspect them and check a type field or search for specific text.
Overall, it's a trick to get the type system to allow you to use a narrower set of types than you could if you used a base class. I mean, you could define all your variables and arguments as having the type Object
, but that would just make your job harder, wouldn't it?
answered 4 hours ago
Becuzz
3,4361221
3,4361221
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
add a comment |
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
Pardon my newness but I’m curious why it wouldn’t be a better approach to make OrderDateInfo HAVE a NamedEntity object as a property?
– Adam B
10 mins ago
1
1
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
@AdamB That's a valid design choice. Whether it is better or not depends on what it will be used for among other things. In the exception case, I can't create a new class with an exception property because then the language (C# for me) won't let me throw it. There might be other design considerations that would preclude using composition rather than inheritance. Many times composition is better. It just depends on your system.
– Becuzz
1 min ago
add a comment |
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f382882%2fwhy-inherit-a-class-and-not-add-properties%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
8
Upside not mentioned: You can distinguish methods that are only relevant to
OrderDateInfo
s from those that are relevant to otherNamedEntity
s– Caleth
6 hours ago
1
For the same reason that if you happened to have, say, an
Identifier
class having nothing to do withNamedEntity
but requiring both anId
andName
property, you wouldn't useNamedEntity
instead. The context and proper usage of a class is more than just the properties and methods which it holds.– Neil
2 hours ago