Skip to main content
gamedev.net
🔒 Locked

C# code reuse issue

Started by janta 5 replies 1.2k views
Original Post
janta
janta
Hi I have many classes, most of which either have a property called "Name" or a property called "ID", or both (and the appropriate private members to support that). As far as implementation details are concerned I can/could have: 1) retyped these for every new class I create, which is what I would like to avoid. 2) created 2 classes such as "Named" and "Identified" and inherited from one or both of them as needed, but C# does not permit multiple class inheritance. 3) ... copy-paste! For bigger chunks of code I would have used composition plus a bunch of methods to expose the functionality but in this situation that is just as much typing as reimplementing it every time. My goal here is not polymorphism, I just want to minimize the typing. Is there any recommended solution to this rather classic issue? Or am I stuck with option 3? Thank you for your time.
Codeka
Codeka
Depends on your version of .NET:

class Foo{    public string Name { get; private set; }    public Foo()    {        Name = "Foo";    }}


That's about as simple as you're going to get, I think.
azherdev
azherdev
What I did in my project is create a base class with the properties I needed and in the derived class would override the properties with a private visibility adding a note in the code that I'm hiding it.

Used the 80/20 rule and it worked well.
janta
janta
Thanks for providing what seems to be the shortest possible property "setup". Can you point me to some documentation where the behavior of such code is documented? (does it work with any data type, what's the property default value, etc.)

I thought it was necessary to always use something like:

public string Name { get { return mName; } }private readonly string mName;

PATrainwreck
PATrainwreck
I may be misunderstanding your problem but it sound like you are talking about a "has a" relationship instead of an "is a" relationship. So you should make two classes a "Name" and an "ID" class and whenever you have a class that needs one or both of those classes, include them in the class without using inheritance. Then you can either make them public or better yet a property, a simple get set would work without adding code into the property, have the data management done by the class "Name" or "ID".
janta
janta
Yes, I completely want a "has a" kind of relationship. I was asking if there was a simple way to have many classes have either a "Name", an "ID", or both, without redefining these properties for every new class.

Quote:
So you should make two classes a "Name" and an "ID" class and whenever you have a class that needs one or both of those classes, include them in the class without using inheritance. Then you can either make them public or better yet a property


Right, though instead of making a new class, I'll just use "string".

It seems like I'm looking for the C#'s equivalent to C++'s multiple. private inheritance. I think I'm going to live with the extra typing ;)
Codeka
Codeka
Quote:
Original post by janta
Thanks for providing what seems to be the shortest possible property "setup". Can you point me to some documentation where the behavior of such code is documented? (does it work with any data type, what's the property default value, etc.)

I thought it was necessary to always use something like:

public string Name { get { return mName; } }private readonly string mName;


They're called Automatic Properties (or Auto-Implemented Properties) and it's a feature of C# 3.0 (i.e. Visual Studio 2008). Basically:

public string Name { get; set; }


Is short-hand for:

private string _name;public string Name { get { return _name; } set { _name = value; } }


The only difference is that with automatic properties, you don't get access to private the backing "_name" variable (which is why "private set;" is useful for creating, essentially, read-only properties).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.