Say I have two classes such as:
public class Pineapple
{
public bool Ripe{get;set;}
public string State{get;set;}
}
and:
public class Bean
{
public string Type{get;set;}
public bool Bloats{get;set;}
}
I want to return an observable collection of those two classes in one method. This is what I mean rather than have:
public ObservableCollection<Pineapple> GetPineapples()
{
//some code that fetches pine apples
}
and yet another method:
public ObservableCollection<Bean> GetBeans()
{
//some code that fetches beans
}
what do I put #T ie ObservableCollection that refers to both of those classes
You can have base class, for example Plant, that both of Pineapple and Bean should be inherited from (or interface, for example IPlant, both should implement).
Then you can do something like:
public class Plant {}
public class Pineapple : Plant ...
public class Bean: Plant ...
public ObservableCollection<Plant> GetPlants()
You can also use something called ViewModel (it's generally used for web though and is just a proxy-class that provides some information about different classes) and you can add c'tors for every class you have;
public class Info
{
public string Info1 { get; set; }
public bool Info2 { get; set; }
public Info(Pineapple p)
{
this.Info1 = p.State;
this.Info2 = p.Ripe;
}
public Info(Bean b)
{
this.Info1 = b.Type;
this.Info2 = b.Bloats;
}
}
P.S.
But if you have many classes you should really consider using abstract class / interface.
I wrote the following console app to test static properties:
using System;
namespace StaticPropertyTest
{
public abstract class BaseClass
{
public static int MyProperty { get; set; }
}
public class DerivedAlpha : BaseClass
{
}
public class DerivedBeta : BaseClass
{
}
class Program
{
static void Main(string[] args)
{
DerivedBeta.MyProperty = 7;
Console.WriteLine(DerivedAlpha.MyProperty); // outputs 7
}
}
}
As this console app demonstrates, the MyProperty property exists once for all instances of BaseClass. Is there a pattern to use which would allow me to define a static property which will have allocated storage for each sub-class type?
Given the above example, I would like all instances of DerivedAlpha to share the same static property, and all instances of DerivedBeta to share another instance of the static property.
Why am I trying to do this?
I am lazily initializing a collection of class property names with certain attributes (via reflection). The property names will be identical for each derived class instance, so it seems wasteful to store this in each class instance. I can't make it static in the base class, because different sub-classes will have different properties.
I don't want to replicate the code which populates the collection (via reflection) in each derived class. I know that one possible solution is to define the method to populate the collection in the base class, and call it from each derived class, but this is not the most elegant solution.
Update - Example of what I'm doing
At Jon's request, here's an example of what I'm trying to do. Basically, I can optionally decorate properties in my classes with the [SalesRelationship(SalesRelationshipRule.DoNotInclude)] attribute (there are other attributes, this is just a simplified example).
public class BaseEntity
{
// I want this property to be static but exist once per derived class.
public List<string> PropertiesWithDoNotInclude { get; set; }
public BaseEntity()
{
// Code here will populate PropertiesWithDoNotInclude with
// all properties in class marked with
// SalesRelationshipRule.DoNotInclude.
//
// I want this code to populate this property to run once per
// derived class type, and be stored statically but per class type.
}
}
public class FooEntity : BaseEntity
{
[SalesRelationship(SalesRelationshipRule.DoNotInclude)]
public int? Property_A { get; set; }
public int? Property_B { get; set; }
[SalesRelationship(SalesRelationshipRule.DoNotInclude)]
public int? Property_C { get; set; }
}
public class BarEntity : BaseEntity
{
public int? Property_D { get; set; }
[SalesRelationship(SalesRelationshipRule.DoNotInclude)]
public int? Property_E { get; set; }
public int? Property_F { get; set; }
}
Desired end result
Accessing FooEntity.PropertiesWithDoNotInclude returns a List<string> of:
{
"Property_A",
"Property_C"
}
Accessing BarEntity.PropertiesWithDoNotInclude returns a List<string> of:
{
"Property_E"
}
Two possible approaches:
Use attributes; decorate each subclass with an attribute, e.g.
[MyProperty(5)]
public class DerivedAlpha
{
}
[MyProperty(10)]
public class DerivedBeta
{
}
That only works when they're effectively constants, of course.
Use a dictionary:
var properties = new Dictionary<Type, int>
{
{ typeof(DerivedAlpha), 5) },
{ typeof(DerivedBeta), 10) },
};
EDIT: Now that we have more context, Ben's answer is a really good one, using the way that generics work in C#. It's like the dictionary example, but with laziness, thread-safety and simple global access all built in.
Jon has a good solution as usual, although I don't see what good attributes do here, since they have to be explicitly added to every subtype and they don't act like properties.
The Dictionary approach can definitely work. Here's another way to do that, which explicitly declares that there will be one variable per subclass of BaseEntity:
class FilteredProperties<T> where T : BaseEntity
{
static public List<string> Values { get; private set; }
// or static public readonly List<string> Values = new List<string>();
static FilteredProperties()
{
// logic to populate the list goes here
}
}
The drawback of this is that it's rather difficult to pair with a GetType() call such as you might use in methods of BaseEntity. A Dictionary, or wrapper thereto which implements lazy population, is better for that usage.
I just recently needed this same thing and came across this question. I think Jon's and Fried's ideas to use a Dictionary are on the right track but don't quite hit what I was looking for so I thought I'd show my own complete and very easy to extend implementation.
public class TypeStaticProperty<T>
{
T _defaultValue;
Dictionary<Type, T> _values = new Dictionary<Type, T>();
public TypeStaticProperty(T defalutValue = default)
{
_defaultValue = defalutValue;
}
public T Get(object caller)
{
lock (_values)
{
if (_values.TryGetValue(caller?.GetType(), out T val))
return val;
else
return _defaultValue;
}
}
public void Set(object caller, T val)
{
lock (_values)
_values[caller?.GetType()] = val;
}
}
And to demonstrate:
class TestBaseClass
{
static TypeStaticProperty<int> _property = new TypeStaticProperty<int>();
public int Property
{
get => _property.Get(this);
set => _property.Set(this, value);
}
}
class TestClass1 : TestBaseClass
{
}
class TestClass2 : TestBaseClass
{
}
class Program
{
static void Main(string[] args)
{
TestClass1 test1a = new TestClass1();
TestClass1 test1b = new TestClass1();
test1a.Property = 1;
test1b.Property = 2;
TestClass2 test2a = new TestClass2();
TestClass2 test2b = new TestClass2();
test2a.Property = 3;
test2b.Property = 4;
Console.WriteLine($"test1a.Property = {test1a.Property}");
Console.WriteLine($"test1b.Property = {test1b.Property}");
Console.WriteLine($"test2a.Property = {test2a.Property}");
Console.WriteLine($"test2b.Property = {test2b.Property}");
}
}
Output:
test1a.Property = 2
test1b.Property = 2
test2a.Property = 4
test2b.Property = 4
So while you still need a class instance to access and set the property, the value will always be the same across all instances of that precise type. (This includes generics too; Foo<int> will be seen as a different type than Foo<string>). This has the huge advantage over Fried's example in that you don't need to know at compile time the precise type whose "static" value you're looking for when accessing or setting.
PS - For full disclosure, this was heavily inspired by the WPF source code, which uses a very similar pattern for DependencyProperty's and all kinds of other internal bells and whistles designed to improve performance and reduce memory footprint.
I have a public class
public class Interview
{
public int InterviewId;
public string ApplicantName;
...
public List<AnsweredQuestions> AnsweredQuestions;
public Questionnaire questionnaire;
}
and use it in a main program like this:
Interview interview = new Interview();
interview.InterviewId = 1;
and a Questionnaire class
public class Questionnaire
{
public int questionnaireId;
public string outputFile;
...
}
How can I prevent modifying the attribute int the main program:
interview.questionnaire.outputFile
I found I was able to use the DocumentManager class in the main program like this:
interview = documentManager.GetInterviewSession();
interview.questionnaire = documentManager.GetQuestionnaireManagement();
interview.AnsweredQuestions = documentManager.GetInterviewAnsweredQuestions();
by using this
public class DocumentManager
{
private readonly Interview _interview;
...
public DocumentManager(Interview interview)
{
_interview = interview;
}
I'm sure I should be encapsulating, but I'm not sure how. Any help would be appreciated.
Thanks!
I'm not sure I entirely get the question, but this is the usual method for read-only encapsulation:
public class Questionnaire
{
public string OutputFile { get; private set; }
}
This creates a property named OutputFile that can be read publically, but only written by the Questionnaire class.
Alternatively, you may want to use protected set; if you want classes deriving from Questionnaire to be able to set OutputFile.
If you need certain properties to be immutable then you can supply those properties in the constructor of the class.
Also instead of using fields, you can use properties that allow you to dictate whether the property getter and setter are private/public/internal/protected.
In your sample, you could have InterviewId as a property with a public get accessor and a private only set accessor. This means that only the class itself can set the interviewId. If the only way to set the interviewId is at the constructor of the class, then there is no way for the consuming code to change it (other than by using reflection of course)
public class Questionnaire
{
public Questionnaire(int questionnaireId, string outputFile)
{
QuestionnaireId = questionnaireId;
OutputFile = outputFile
}
public int QuestionnaireId {get; private set;}
public string OutputFile { get; private set; }
...
}
Suppose I have a the following code:
Container.cs
public class Container
{
public readonly string IdType;
public Container( string aIdType )
{
IdType = aIdType;
}
}
SuperContainerA .cs
public class SuperContainerA : Container
{
public SuperContainerA( /*x parameters*/ ) : base("A") {}
}
SuperContainerB.cs
public class SuperContainerB : Container
{
public SuperContainerB( /*y parameters*/ ) : base("B") {}
}
SuperContainerToTheInfinityAndBeyond.cs
public class SuperContainerB : Container
{
public SuperContainerB( /*y parameters*/ ) : base("It's Over 9000!") {}
}
Based on that, what I'm trying to retrieve is the "A" and "B" that are being sent to the TypeId from the constructor.
The catch here is... I need to retrieve those values during the initialization of the program, before creating an instance of those classes, so I thought that using reflection is my best bet here. (Note: Creating an instance of the classes to retrieve the value would be valid if the number of parameters for each constructor would be the same, but they can change. :()
Is it possible to use reflection to check the literals of my source code and/or Assemblies? (If I can see something like the source code, then I can use Regex to get the value.)(Note: Including the sources as resource files to my program is not an option :P)
I'm thinking of declaring constants to hold the value and force an naming rule on then, so that I could use reflection later to grab then back. Something like ...
public class SuperContainerA
{
public const string ctIdType = "A";
}
public class SuperContainerB
{
public const string ctIdType = "B";
}
... But I'm not sure if this is the best approach to this problem, since I won't have anything to help me check if these consts have been declared and if they got the proper name during compile time.
Actually, if the language had some kind of static inheritance, this would help a lot in this situation, but I hear some programmers complaing that static inheritance is more of an head ache than a cure.
Anyway, I'm searching for alternatives. Any idea is welcome.
Attributes to the rescue!
public class IdTypeAttribute: Attribute
{
public string IdType { get; private set; }
public IdTypeAttribute(string idType)
{
IdType = idType;
}
}
[IdType("B")]
public class SuperContainerB: Container
{
// whatever you like...
}
You can then access the Attribute via reflection. Easy enough to do...
var type = typeof(SuperContainerB);
var attribute = (IdTypeAttribute)type.GetCustomAttributes(
typeof(IdTypeAttribute), false)[0];
var idType = attribute.IdType;
Why not simply use the concrete type to look up the string value that you seem to want associated with it?
public class SuperA : Container
{
public string IdType { get { return IdTypeFactory.Get( GetType() ); } }
}
public static class IdTypeFactory
{
public static string Get( Type containerType ) { ... }
}
The primary benefit of this solution would be to gather all your string literals in one central location. Alternatively, go with the abstract super class.
Overloading constructors and methods seems messy, i.e. simply differentiating them by the order and number of parameters. Isn't there a way, perhaps with generics, to do this cleanly so that, even if you just have one parameter (e.g. string idCode / string status) you could still differentiate them?
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
TheForm tf1 = new TheForm("online", DateTime.Now);
TheForm tf2 = new TheForm(DateTime.Now, "form1");
}
}
public class TheForm
{
public TheForm(string status, DateTime startTime)
{
//...
}
public TheForm(DateTime startTime, string idCode)
{
//...
}
}
}
If you need that many overloads, perhaps your types are handling too much (see Single Responsibility Principle). Personally I rarely need more than one or a few constructors.
You could consider having a Fluent Builder for the class instead, although it's more work. This would allow you to write something like this:
var form = new TheFormBuilder().WithStatus("foo").WithStartTime(dt).Build();
It's more explicit, but not necessary better. It's definitely more work.
In C# 4, you can optionally write the parameter names when you invoke the constructor:
var form = new TheForm(status: "Foo", startTime: dt);
The new object initialization feature of .NET 3.0 is more flexible than an overloaded constructor. Here is a simple example:
public class Item
{
public string Name {get; set;}
public int Index {get; set;}
public string Caption {get; set;}
}
As it is written now, we can do the following in code:
var x = new item {Name=”FooBar”};
var x = new item {Name=”FooBar”, Index=”1”, Caption=”Foo Bar”};
I would only add an overloaded constructor to the class Item if I want to add functionality during property initialization. For example:
public class Item
{
public Item() {}
public Item(string name)
{
Name = name;
Caption = name; //defaulting name to caption
}
public Item(string name, int index) : this(name)
{
Index = index;
}
public Item(string name, int index, string caption) : this(name, int)
{
Caption = caption;
}
public string Name {get; set;}
public int Index {get; set;}
public string Caption {get; set;}
}
Note: If this was a child class, I could have chained to a parent constructor with the “base” keyword.
If I am writing a “configuration” type of class, I use Fluent Methods in place of Overloaded constructors.
For example, if I added these methods to the Item class:
public Item WithName(string name)
{
Name = name;
return this;
}
public Item WithIndex(int index)
{
Index = index;
return this;
}
public Item WithCaption(string caption)
{
Caption = caption;
return this;
}
I could write code like this:
var x = new Item().WithName(“FooBar”).WithIndex(“99”).WithCaption(“Foo Bar”);
The only way I can think of to differentiate the construction with a single parameter of a given type is to use a non-instance factory method, either on the type itself or in a factory class.
e.g. (on the type itself)
(untested)
public class TheForm
{
public static TheForm CreateWithId(string idCode)
{
}
public static TheForm CreateWithStatus(string status)
{
}
}
Before Fluent builders we sometimes managed to get around with parameter objects or setup objects:
public class FormSetup {
public string Status ...
public string Id ...
}
var frm = new MyForm(new FormSetup { Status = "Bla", ... });
Constructor Forwarding!
Use helper initialization classes to communicate the semantics of your overloads.
So, for instance, define
public class TheForm
{
public class TheForm(ById initializer)
{
//...
}
public class TheForm(ByStatus initializer)
{
//...
}
// ...
public class ById
{
public ById(DateTime startTime, string idCode)
// ...
}
public class ByStatus
{
public ByStatus(string status, DateTime startTime)
// ...
}
}
However, prefer using classes which are more generally usable if you can, not just for initalialization. You may want to factor your classes in a different way instead. I sense the possibility of a code smell: does your TheForm class contain too much business logic? Might you want to split out an MVC Controller, for instance?
In C# (like in many other programming languages) in this case you should use Factory Methods. Something like this:
class TheForm
{
public static TheForm CreateFromId(string idCode);
public static TheForm CreateFromStatus(string status);
}
or fiction parameters:
class TheForm
{
public TheForm(string idCode, int);
public TheForm(string status);
}
Or you can use Eiffel ;):
class THE_FORM create
make_from_id, make_from_status
feature
...
end
We use properties instead of overloading constructors, it's quite clean and easy to implement:
public class x {
public string prop1 {get;set;}
public DateTime prop2 {get;set;}
...
}
and then fill just the properties you need at instantiation time (and/or later)
var obj = new x() {
prop1 = "abc",
prop2 = 123
};
The benefit with this is it works with .Net 3.5 and makes it really clear what is being set. (as opposed to var obj = new x("abc", 123, true, false, ... etc) where you have to guess the meaning of each value, which can get really hairy when there are many overloads)
Here's an example:
Timespan.FromMilliseconds(double)
Timespan.FromSeconds(double)
Timespan.FromMinutes(double)
Timespan.FromHours(double)
Timespan.FromDays(double)
Isn't this where inheritence comes in?
Just have TheForm as a base class and then TheFormWithID and TheFormWithStatus child classes.
Have their constructors take string ID and string Status respectively passing back the DateTime value to the base class.
I haven't got any coding tools infront of me so please excuse the syntax. I'm sure that you'll figure it out.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
TheForm tf1 = new TheFormWithStatus(DateTime.Now, "online");
TheForm tf2 = new TheFormWithID(DateTime.Now, "form1");
}
}
public class TheForm
{
public TheForm(DateTime startTime)
{
//...
}
}
public class TheFormWithID : TheForm
{
public TheFormWithID (DateTime startTime, string idCode) : TheForm (startTime)
{
//...
}
}
public class TheFormWithStatus : TheForm
{
public TheFormWithStatus (DateTime startTime, string status) : TheForm (startTime)
{
//...
}
}
}
Or have TheForm as an abstract class.
Whether you're talking about constructors or not, overloading's pretty limited, and when you start to run up against its limits, that's a hint that it's not the right tool for the job.
It's worth looking at a well-designed API that uses overloading to get a sense of what kind of job the tool is good for. XmlReader.Create is a good example: It supports twelve different overloads. Twelve! And yet, it's actually completely sensible: when you look at them all, they boil down to what would, in Python, be a single calling signature with optional parameters:
XmlReader.Create(input [, settings [, parser_context]])
input, to this method, can be a string containing a URL or filename, a TextReader, or a Stream. But irrespective of its data type, it's still fundamentally the same thing: the source of the data that the XmlReader is going to read.
Now let's look at your case. Forget about data types for a moment. There's clearly some functional difference between a status and an idCode in your application. Your form is going to behave one way if it's given a status and another if it's given an idCode. The API that you're proposing conceals this functional difference. It should be illuminating it.
I would first consider the simplest possible approach, which uses no overloads at all:
TheForm(string idCode, string status)
Make your constructor throw an exception if both values are provided (or if both are null). Note that they're mutually exclusive in the documentation. Call it a day.
My second choice would be:
enum FormType
{
IdCode,
Status
};
TheForm(FormType type, string data)
This is less concise, but it has the very great merit of making the fact that this method supports multiple mutually-exclusive modes explicit.
I called that enum FormType because it seemed like a sensible name, given what I know so far, and the fact that this method's a constructor. But whenever you contemplate creating an enum to determine the type of an instance, you should at least consider the possibility that you should really be creating a type to determine the type of an instance:
class TheFormWhatUsesIdCode : TheForm {...}
class TheFormWhatUsesStatus : TheForm {...}
The functional difference between idCode and status probably relates to a functional difference between a form instantiated with idCode and a form instantiated with status. And that strongly suggests that they should be subclasses.
In all of this analysis, I've never once considered the possibility of doing what you actually asked for, which is to provide multiple overloads. I don't think overloading is the right tool for this job. If idCode were an int and status were a string I still wouldn't think that overloading were the right tool for this job, though I probably wouldn't have ended up noticing it until I had a lot of code I needed to refactor.
I am not getting what "messy" you found in multiple constructors. I felt the static methods for returning an instance of the object also a probable alternate.
But, if somebody want to have the fancy of a single constructor and still have different implementations, we can think of passing an object derived from some interface as the input to the constructor and might check the type of the input to create an instance. This is kind of an abstract factory in this case.
In one place we have a class like the following:
using System;
namespace MyApplication
{
class Program
{
static void Main(string[] args)
{
base1 t1 = new type1();
class1 c1 = new class1(t1);
base1 t2 = new type2();
class1 c2 = new class1(t2);
//.....
}
}
public class class1
{
public class1(base1 mytype)
{
switch(mytype.type)
case mytype.types.type1
return createObjectOftype1();
case mytype.types.type2
return createObjectOftype2();
case mytype.types.type3
return createObjectOftype3();
}
public class1 createObjectOftype1()
{
//....
}
public class1 createObjectOftype2()
{
//...
}
public class1 createObjectOftype2()
{
//...
}
}
public class base1
{
publlic Enum Types {0 "type1",....
}
public class type1:base1
{
//.....
}
public class type2:base1
{
//.....
}
}
I personally dont like the idea of other classes being able to set my properties
so this allows my properties to be protected or private, but still have alot of the functionality described by other answers:
public class FooSettings
{
public bool Prop1 { get; set; }
public bool Prop2 { get; set; }
public TimeSpan Prop3 { get; set; }
public FooSettings()
{
this.Prop1 = false;
this.Prop2 = false;
this.Prop3 = new TimeSpan().ExtensionMethod(CustomEnum.Never);
}
public FooSettings BoolSettings
(bool incomingFileCacheSetting, bool incomingRuntimeCacheSetting)
{
this.Prop1 = incomingFileCacheSetting;
this.Prop2 = incomingRuntimeCacheSetting;
return this;
}
public FooSettings Prop3Setting
(TimeSpan incomingCustomInterval)
{
this.Prop3 = incomingCustomInterval;
return this;
}
public FooSettings Prop3Setting
(CustomEnum incomingPresetInterval)
{
return this.Prop3Setting(new TimeSpan().ExtensionMethod(CustomEnum.incomingPresetInterval));
}
}
public class Foo
{
public bool Prop1 { get; private set; }
public bool Prop2 { get; private set; }
public TimeSpan Prop3 { get; private set; }
public CallTracker
(
FooSettings incomingSettings
)
{
// implement conditional logic that handles incomingSettings
}
}
could then be consumed as:
FooSettings newFooSettings = new FooSettings {Prop1 = false, Prop2 = true}
newFooSettings.Prop3Setting(new TimeSpan(3,0,0));
Foo newFoo = new Foo(newFooSettings)
or
FooSettings newFooSettings = new FooSettings()
.BoolSettings(false, true)
.Prop3Setting(CustomEnum.Never)
Foo newFoo = new Foo(newFooSettings)
obviously a bit overkill for a simple class, but it gives alot of control over the types of data that can be funneled down to a single property, IE: TimeSpan can be parsed from a custom enum type using an extension method