Why inherit a class and not add properties?











up vote
4
down vote

favorite
1












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?










share|improve this question


















  • 8




    Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
    – Caleth
    6 hours ago






  • 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















up vote
4
down vote

favorite
1












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?










share|improve this question


















  • 8




    Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
    – Caleth
    6 hours ago






  • 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













up vote
4
down vote

favorite
1









up vote
4
down vote

favorite
1






1





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?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 6 hours ago









robotron

1885




1885








  • 8




    Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
    – Caleth
    6 hours ago






  • 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














  • 8




    Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
    – Caleth
    6 hours ago






  • 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








8




8




Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
– Caleth
6 hours ago




Upside not mentioned: You can distinguish methods that are only relevant to OrderDateInfos from those that are relevant to other NamedEntitys
– 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










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.






share|improve this answer























  • 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


















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?






share|improve this answer





















  • 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











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















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

























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.






share|improve this answer























  • 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















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.






share|improve this answer























  • 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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












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?






share|improve this answer





















  • 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















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?






share|improve this answer





















  • 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













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?






share|improve this answer












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?







share|improve this answer












share|improve this answer



share|improve this answer










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


















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

Eduardo VII do Reino Unido