Lets say that one has a class like Person that has associated with it some default settings implemented in a Setting class. Those settings might be things like "Default Title" or "First Name Required". Correspondingly, other classes like an Address class might also have some default settings. The Setting class persists each setting into a persistent store.
Should one implement a static method in each class like "SetDefaults()" that contains these settings so that an external method can call SetDefaults() on each object type? e.g. Person.SetDefaults() and then Address.SetDefaults()?
Or is there some better object oriented way of doing this?
[Update: this can't be in the constructor because SetDefaults() should be called from an external class at a particular point in time, rather than each time the object is constructed.]
I can't think of many occasions where defaults are truly spanning... given all the different use-cases that an object may go through (not least, things like deserialization - which could end up setting the defaults even though that isn't what was intended).
One option here is IoC; IoC containers like StructureMap have the ability to set properties after initialization, and that is then abstracted from the calling code.
Another option might be some kind of template instance (static), that instances can copy values from. But I think this is risky in a few scenarios. You also get problems if different threads (perhaps requests on a web-server) need different defaults. [ThreadStatic] isn't a good option (although it is an option).
Another option (that provides the greatest flexibility) would be to provide a user-settable factory... perhaps via a delegate or event mechanism - but I struggle to see why you might want this scenario. It isn't one I've seen very often...
re update: if it is only used by the external class; could it perhaps use something like an extension method (rather than the Person class having to know anything about this):
public static class PersonExt {
public static void SetDefaults(this Person person) {
// your code
}
}
Since it sounds like the original Person class doesn't care about SetDefaults, this divorces the logic from Person neatly.
Why not set these defaults when you create the object (in the constructor).
A default is -imho- a value that should be assigned to a property when no specific value is given to that property, so, I think it is a good idea to set those default-values when the object is created (in the constructor, or via a factory).
Or, am i missing something ?
I'd put them in the constructor.
class Person
{
public Person()
{
this.Settings = MakeDefault();
}
public Person(Settings settings)
{
this.Settings = settings;
}
}
You could create a settings class that encapsulate settings for all classes (Person, Address).
You could set default settings for say Person:
// Injected
Settings settings;
Setting personSetting = new ...;
...
settings.StoreSettingsFor(typeof(Person), personSettings);
You could also use a singleton to store this data if you wished, especially if the values are retrieved from storage somewhere as this would cut down on the number of times that the storage is accessed.
(In this instance storage can be datafile, registry, database.)
You can also implement Abstract factory pattern and configure factories with your settings. Or you can alternatively use IoC for injecting dependency into this factory classes.
Simple Factory class for Preson can look following:
public class PersonFactory
{
private readonly ISettings settings;
public PersonFactory(ISettings settings)
{
this.settings = settings;
}
public Person Create()
{
Person p = new Person();
// ... you code for populating person's attributes form settings.
return p;
}
}
Related
I am trying to develop my application using the DDD approach and I should set all of my properties private. I need to use Aerospike as my database and there is no ORM to fill my properties magically like EntityFramework with a private default constructor.
Now, How can I fill this reach model without exposing a full property constructor that can be accessible everywhere and can breach the rule of encapsulation business domain rules?
making all properties protected and creating an internal inherited class inside the repository namespace that can act as a proxy object to fill property can be a solution But I have no idea about the best practice and acceptable design.
I'm not familiar with Aerospike, but here are my thoughts. First, EF is able to set private properties because it uses reflection to do so. And it needs a parameterless constructor for this. So you could do it the same way: create an object and set properties via reflection.
Or, as others pointed out in the comments, you will anyway need methods to set your private properties, so just use them to instantiate your model. You use private setters and methods in order to ensure that the state of your DDD object is valid and do some internal checks, e.g.:
public class Whatever {
private int age;
public int Age { get; private set; }
public void UpdateAge(int a) {
if (a > 0) {
this.age = a;
}
throw new MyException();
}
}
So just use UpdateAge() and the like. On the other hand it's not necessary to run extra validations if you are instantiating from a database, because all the data in the DB is valid. You could introduce some private variable, like needsValidation, and set it to false in case you are instantiating from the DB via e.g. an internal constructor. Whether it's really worth the effort depends on your use case.
I'm trying to work Domain Specific Language constructs into my api. What I would really love to do is be able to add a static method to a class via extension, but i have researched that this is not possible from this site. So let's talk about what i really want to do by example.
Say you have some class that serves as a data service (could be a database, or rest or whatever).
The class requires you to initialize it with some, let's say, location data so that it knows where to point. This location information is not going to be known till runtime.
Normally you would do . . .
DataService service = new DataService( locationData );
Order = service.getOrderDetails( orderId );
However, in almost all cases, the user will just need to ask on question of the DataService and then move on, close scope. I would like some idiom that makes this friendlier to the user. When I learned of extension methods by wish was to do this . . .
Order = DataService.at(location).getOrderDetails(orderId);
This, of course, is also possible, but I would like to put this pattern/idiom on to many classes that have this notion of a location. I have tried extension methods (cant be static). I have tried inheriting from a GenericClass that provides an at method:
public class DSL<T>
where T : new()
{
public T at( Location location )
{
return new T(location);
}
}
you can not pass args to a constructor for a variable type :(
I dislike doing the following:
public class DSL<T>
where T : ILocationable, new()
{
public T at( Location location )
{
T result = new T();
result.setLocation( location );
return result;
}
}
because i do not like classes that can be instantiated and not initialized.
What alternatives do you guys have out there, either to add this "at" method or to provide a better idiom for handling this type of api.
UPDATE:
I came up with a mechanism that does what I need:
First I have this in a file in my library/tools area. The file is called DSL.cs
contents below:
namespace R3
{
static public class DSL
{
static public Services.CloudConnection Cloud( string cloud )
{
return Services.CloudFactory.get(cloud);
}
}
}
When I declare a method I want to use this with technique
static public void fixSequenceError(this CloudConnection cloud, OrderId id )
{
if( inSequenceError(cloud, id ) )
{
cloud.db.setOrderStatus(id, BLAH);
cloud.db.setOrderItemsStatus(id, BLAHBLAH);
}
}
then in any file i want to use this idiom in I need to do something funky instead of a standard include:
using static R3.DSL;
Now I can type stuff like:
Cloud( locationData ).fixSequenceError
or
Cloud(orderInfo.cloudLocation).db.changeAppOrderStatus
For efficiency, the CloudFactory is returning a statically allocated object that is associated with that cloudLocation, think many different singletons hashed to identifier. When Cloud( location ).foobar(orderId) is invoked I'm calling foobar using the object specific to that location. I'm doing so without having to prepend every action with Cloud cloud = CloudFactory.getCloud(location)
You could use reflection like this:
public static class DSL
{
public static T at<T>(Location location)
{
return (T)typeof(T).GetConstructor(new[]{typeof(Location)})?.Invoke(new object[] {location});
}
}
This method tries to get a ConstructorInfo and invokes it with the provided Location argument.
When the type T does not have a constructor taking only a Location argument, at will return null.
UPDATE: Decided to make the class static, so you don't need to create an instance when you just want to call it like this:
Order order = DSL.at<DataService>(location).getOrderDetails(orderId);
You could adopt a builder pattern perhaps to avoid classes which are constructed but not valid (although the builder itself might fall into this category):
Order order = new OrderBuilder().using(dataService).at(location).getOrderById(id).Build();
This gives the sort of fluent api you're looking for. I have recently used this for a project.
I would like some idiom that makes this friendlier to the user.
In your case it appears you don't want to use the Object Oriented Programming the way it was designed in c# but would rather use any a Fluent that allows for friendlier code for another programmer (not user).
In this case it seems your only solution would be to use the factory pattern. It's typically used to validate parameters as they are passed in, but in this case can be used to encapsulate the creation of a class to prevent uninitialized classes.
(I'll also mention that lowercased methods are against Microsoft guidelines for naming conventions, so I'll be using Pascal casing in my code.)
DataService.at(location).getOrderDetails(orderId);
Could be coded like:
public class DataService
{
private DataService(Location location)
{
//
}
public static DataService At(Location location)
{
var result = new DataService(location);
return result;
}
public Order GetOrderDetails(int orderId)
{
}
}
Then the code would look exactly like your example:
DataService.At(myLocation).GetOrderDetails(1);
This is only good assuming DataService does not derive from IDisposable.
I'm refactoring a class that represents the data in some XML. Currently, the class loads the XML itself and property implementations parse the XML every time. I'd like to factor out the XML logic and use a factory to create these objects. But there are several 'optional' properties and I'm struggling to find an elegant way to handle this.
Let's say the XML looks like this:
<data>
<foo>a</foo>
<bar>b</bar>
</data>
Assume both foo and bar are optional. The class implementation looks something like this:
interface IOptionalFoo
{
public bool HasFoo();
public string Foo { get; }
}
// Assume IOptionalBar is similar
public class Data : IOptionalFoo, IOptionalBar
{
// ...
}
(Don't ask me why there's a mix of methods and properties for it. I didn't design that interface and it's not changing.)
So I've got a factory and it looks something like this:
class DataFactory
{
public static Data Create(string xml)
{
var dataXml = new DataXml(xml);
if (dataXml.HasFoo())
{
// ???
}
// Create and return the object based on the data that was gathered
}
}
This is where I can't seem to settle on an elegant solution. I've done some searching and found some solutions I don't like. Suppose I leave out all of the optional properties from the constructor:
I can implement Foo and Bar as read/write on Data. This satisfies the interface but I don't like it from a design standpoint. The properties are meant to be immutable and this fudges that.
I could provide SetFoo() and SetBar() methods in Data. This is just putting lipstick on the last method.
I could use the internal access specifier; for the most part I don't believe this class is being used outside of its assembly so again it's just a different way to do the first technique.
The only other solution I can think of involves adding some methods to the data class:
class Data : IOptionalFoo, IOptionalBar
{
public static Data WithFoo(Data input, string foo)
{
input.Foo = foo;
return input;
}
}
If I do that, the setter on Foo can be private and that makes me happier. But I don't really like littering the data object with a lot of creation methods, either. There's a LOT of optional properties. I've thought about making some kind of DataInitialization object with a get/set API of nullable versions for each property, but so many of the properties are optional it'd end up more like the object I am refactoring becomes a facade over a read/write version. Maybe that's the best solution: an internal read/write version of the class.
Have I enumerated the options? Do I need to quit being so picky and settle on one of the techniques above? Or is there some other solution I haven't thought of?
You can think of such keywords as virtual/castle dynamic proxy/reflection/T4 scripts - each one can solve the problem on a slightly different angle.
On another note, this seems perfectably reasonable, unless I misunderstood you:
private void CopyFrom(DataXml dataXml) // in Data class
{
if (dataXml.HasFoo()) Foo = dataXml.Foo;
//etc
}
What I did:
I created a new class that represented a read/write interface for all of the properties. Now the constructor of the Data class takes an instance of that type via the constructor and wraps the read/write properties with read-only versions. It was a little tedious, but wasn't as bad as I thought.
I have a class that upon construction, loads it's info from a database. The info is all modifiable, and then the developer can call Save() on it to make it Save that information back to the database.
I am also creating a class that will load from the database, but won't allow any updates to it. (a read only version.) My question is, should I make a separate class and inherit, or should I just update the existing object to take a readonly parameter in the constructor, or should I make a separate class entirely?
The existing class is already used in many places in the code.
Thanks.
Update:
Firstly, there's a lot of great answers here. It would be hard to accept just one. Thanks everyone.
The main problems it seems are:
Meeting expectations based on class names and inheritance structures.
Preventing unnecessary duplicate code
There seems to be a big difference between Readable and ReadOnly. A Readonly class should probably not be inherited. But a Readable class suggests that it might also gain writeability at some point.
So after much thought, here's what I'm thinking:
public class PersonTestClass
{
public static void Test()
{
ModifiablePerson mp = new ModifiablePerson();
mp.SetName("value");
ReadOnlyPerson rop = new ReadOnlyPerson();
rop.GetName();
//ReadOnlyPerson ropFmp = (ReadOnlyPerson)mp; // not allowed.
ReadOnlyPerson ropFmp = (ReadOnlyPerson)(ReadablePerson)mp;
// above is allowed at compile time (bad), not at runtime (good).
ReadablePerson rp = mp;
}
}
public class ReadablePerson
{
protected string name;
public string GetName()
{
return name;
}
}
public sealed class ReadOnlyPerson : ReadablePerson
{
}
public class ModifiablePerson : ReadablePerson
{
public void SetName(string value)
{
name = value;
}
}
Unfortunately, I don't yet know how to do this with properties (see StriplingWarrior's answer for this done with properties), but I have a feeling it will involve the protected keyword and asymmetric property access modifiers.
Also, fortunately for me, the data that is loaded from the database does not have to be turned into reference objects, rather they are simple types. This means I don't really have to worry about people modifying the members of the ReadOnlyPerson object.
Update 2:
Note, as StriplingWarrior has suggested, downcasting can lead to problems, but this is generally true as casting a Monkey to and Animal back down to a Dog can be bad. However, it seems that even though the casting is allowed at compile time, it is not actually allowed at runtime.
A wrapper class may also do the trick, but I like this better because it avoids the problem of having to deep copy the passed in object / allow the passed in object to be modified thus modifying the wrapper class.
The Liskov Substitution Principle says that you shouldn't make your read-only class inherit from your read-write class, because consuming classes would have to be aware that they can't call the Save method on it without getting an exception.
Making the writable class extend the readable class would make more sense to me, as long as there is nothing on the readable class that indicates its object can never be persisted. For example, I wouldn't call the base class a ReadOnly[Whatever], because if you have a method that takes a ReadOnlyPerson as an argument, that method would be justified in assuming that it would be impossible for anything they do to that object to have any impact on the database, which is not necessarily true if the actual instance is a WriteablePerson.
Update
I was originally assuming that in your read-only class you only wanted to prevent people calling the Save method. Based on what I'm seeing in your answer-response to your question (which should actually be an update on your question, by the way), here's a pattern you might want to follow:
public abstract class ReadablePerson
{
public ReadablePerson(string name)
{
Name = name;
}
public string Name { get; protected set; }
}
public sealed class ReadOnlyPerson : ReadablePerson
{
public ReadOnlyPerson(string name) : base(name)
{
}
}
public sealed class ModifiablePerson : ReadablePerson
{
public ModifiablePerson(string name) : base(name)
{
}
public new string Name {
get {return base.Name;}
set {base.Name = value; }
}
}
This ensures that a truly ReadOnlyPerson cannot simply be cast as a ModifiablePerson and modified. If you're willing to trust that developers won't try to down-cast arguments in this way, though, I prefer the interface-based approach in Steve and Olivier's answers.
Another option would be to make your ReadOnlyPerson just be a wrapper class for a Person object. This would necessitate more boilerplate code, but it comes in handy when you can't change the base class.
One last point, since you enjoyed learning about the Liskov Substitution Principle: By having the Person class be responsible for loading itself out of the database, you are breaking the Single-Responsibility Principle. Ideally, your Person class would have properties to represent the data that comprises a "Person," and there would be a different class (maybe a PersonRepository) that's responsible for producing a Person from the database or saving a Person to the database.
Update 2
Responding to your comments:
While you can technically answer your own question, StackOverflow is largely about getting answers from other people. That's why it won't let you accept your own answer until a certain grace period has passed. You are encouraged to refine your question and respond to comments and answers until someone has come up with an adequate solution to your initial question.
I made the ReadablePerson class abstract because it seemed like you'd only ever want to create a person that is read-only or one that is writeable. Even though both of the child classes could be considered to be a ReadablePerson, what would be the point of creating a new ReadablePerson() when you could just as easily create a new ReadOnlyPerson()? Making the class abstract requires the user to choose one of the two child classes when instantiating them.
A PersonRepository would sort of be like a factory, but the word "repository" indicates that you're actually pulling the person's information from some data source, rather than creating the person out of thin air.
In my mind, the Person class would just be a POCO, with no logic in it: just properties. The repository would be responsible for building the Person object. Rather than saying:
// This is what I think you had in mind originally
var p = new Person(personId);
... and allowing the Person object to go to the database to populate its various properties, you would say:
// This is a better separation of concerns
var p = _personRepository.GetById(personId);
The PersonRepository would then get the appropriate information out of the database and construct the Person with that data.
If you wanted to call a method that has no reason to change the person, you could protect that person from changes by converting it to a Readonly wrapper (following the pattern that the .NET libraries follow with the ReadonlyCollection<T> class). On the other hand, methods that require a writeable object could be given the Person directly:
var person = _personRepository.GetById(personId);
// Prevent GetVoteCount from changing any of the person's information
int currentVoteCount = GetVoteCount(person.AsReadOnly());
// This is allowed to modify the person. If it does, save the changes.
if(UpdatePersonDataFromLdap(person))
{
_personRepository.Save(person);
}
The benefit of using interfaces is that you're not forcing a specific class hierarchy. This will give you better flexibility in the future. For example, let's say that for the moment you write your methods like this:
GetVoteCount(ReadablePerson p);
UpdatePersonDataFromLdap(ReadWritePerson p);
... but then in two years you decide to change to the wrapper implementation. Suddenly ReadOnlyPerson is no longer a ReadablePerson, because it's a wrapper class instead of an extension of a base class. Do you change ReadablePerson to ReadOnlyPerson in all your method signatures?
Or say you decide to simplify things and just consolidate all your classes into a single Person class: now you have to change all your methods to just take Person objects. On the other hand, if you had programmed to interfaces:
GetVoteCount(IReadablePerson p);
UpdatePersonDataFromLdap(IReadWritePerson p);
... then these methods don't care what your object hierarchy looks like, as long as the objects you give them implement the interfaces they ask for. You can change your implementation hierarchy at any time without having to change these methods at all.
Definitely do not make the read-only class inherit from the writable class. Derived classes should extend and modify the capabilities of the base class; they should never take capabilities away.
You may be able to make the writable class inherit from the read-only class, but you need to do it carefully. The key question to ask is, would any consumers of the read-only class rely on the fact that it is read-only? If a consumer is counting on the values never changing, but the writable derived type is passed in and then the values are changed, that consumer could be broken.
I know it is tempting to think that because the structure of the two types (i.e. the data that they contain) is similar or identical, that one should inherit from the other. But that is often not the case. If they are being designed for significantly different use cases, they probably need to be separate classes.
A quick option might be to create an IReadablePerson (etc) interface, which contains only get properties, and does not include Save(). Then you can have your existing class implement that interface, and where you need Read-only access, have the consuming code reference the class through that interface.
In keeping with the pattern, you probably want to have a IReadWritePerson interface, as well, which would contain the setters and Save().
Edit On further thought, IWriteablePerson should probably be IReadWritePerson, since it wouldn't make much sense to have a write-only class.
Example:
public interface IReadablePerson
{
string Name { get; }
}
public interface IReadWritePerson : IReadablePerson
{
new string Name { get; set; }
void Save();
}
public class Person : IReadWritePerson
{
public string Name { get; set; }
public void Save() {}
}
The question is, "how do you want to turn a modifiable class into a read-only class by inheriting from it?"
With inheritance you can extend a class but not restrict it. Doing so by throwing exceptions would violate the Liskov Substitution Principle (LSP).
The other way round, namely deriving a modifiable class from a read-only class would be OK from this point of view; however, how do you want to turn a read-only property into a read-write property? And, moreover, is it desirable to be able to substitute a modifiable object where a read-only object is expected?
However, you can do this with interfaces
interface IReadOnly
{
int MyProperty { get; }
}
interface IModifiable : IReadOnly
{
new int MyProperty { set; }
void Save();
}
This class is assignment compatible to the IReadOnly interface as well. In read-only contexts you can access it through the IReadOnly interface.
class ModifiableClass : IModifiable
{
public int MyProperty { get; set; }
public void Save()
{
...
}
}
UPDATE
I did some further investigations on the subject.
However, there is a caveat to this, I had to add a new keyword in IModifiable and you can only access the getter either directly through the ModifiableClass or through the IReadOnly interface, but not through the IModifiable interface.
I also tried to work with two interfaces IReadOnly and IWriteOnly having only a getter or a setter respectively. You can then declare an interface inheriting from both of them and no new keyword is required in front of the property (as in IModifiable). However when you try to access the property of such an object you get the compiler error Ambiguity between 'IReadOnly.MyProperty' and 'IWriteOnly.MyProperty'.
Obviously, it is not possible to synthesize a property from separate getters and setters, as I expected.
I had the same problem to solve when creating an object for user security permissions, that in certain cases must be mutable to allow high-level users to modify security settings, but normally is read-only to store the currently logged-in user's permissions information without allowing code to modify those permissions on the fly.
The pattern I came up with was to define an interface which the mutable object implements, that has read-only property getters. The mutable implementation of that interface can then be private, allowing code that directly deals with instantiating and hydrating the object to do so, but once the object is returned out of that code (as an instance of the interface) the setters are no longer accessible.
Example:
//this is what "ordinary" code uses for read-only access to user info.
public interface IUser
{
string UserName {get;}
IEnumerable<string> PermissionStrongNames {get;}
...
}
//This class is used for editing user information.
//It does not implement the interface, and so while editable it cannot be
//easily used to "fake" an IUser for authorization
public sealed class EditableUser
{
public string UserName{get;set;}
List<SecurityGroup> Groups {get;set;}
...
}
...
//this class is nested within the class responsible for login authentication,
//which returns instances as IUsers once successfully authenticated
private sealed class AuthUser:IUser
{
private readonly EditableUser user;
public AuthUser(EditableUser mutableUser) { user = mutableUser; }
public string UserName {get{return user.UserName;}}
public IEnumerable<string> PermissionNames
{
//GetPermissions is an extension method that traverses the list of nestable Groups.
get {return user.Groups.GetPermissions().Select(p=>p.StrongName);
}
...
}
A pattern like this allows you to use code you've already created in a read-write fashion, while not allowing Joe Programmer to turn a read-only instance into a mutable one. There are a few more tricks in my actual implementation, mainly dealing with persistence of the editable object (since editing user records is a secured action, an EditableUser cannot be saved with the Repository's "normal" persistence method; it instead requires calling an overload that also takes an IUser which must have sufficient permissions).
One thing you simply must understand; if it is possible for your program to edit the records in any scope, it is possible for that ability to be abused, whether intentionally or otherwise. Regular code reviews of any usage of the mutable or immutable forms of your object will be necessary to make sure other coders aren't doing anything "clever". This pattern also isn't enough to ensure that an application used by the general public is secure; if you can write an IUser implementation, so can an attacker, so you'll need some additional way to verify that your code and not an attacker's produced a particular IUser instance, and that the instance hasn't been tampered with in the interim.
I would like to write code without a lot of switch, if/else, and other typical statements that would execute logic based on user input.
For example, lets say I have a Car class that I want to assemble and call Car.Run(). More importantly, lets say for the tires I have a chocie of 4 different Tire classes to choose from based on the user input.
For the, i dunno, body type, letS say i have 10 body type classes to choose from to construct my car object, and so on and so on.
What is the best pattern to use when this example is magnified by 1000, with the number of configurable parameters.
Is there even a pattern for this ? Ive looked at factory and abstract factory patterns, they dont quite fit the bill for this, although it would seem like it should.
I don't think the factory pattern would be remiss here. This is how I would set it up. I don't see how you can get away from switch/if based logic as fundamentally, your user is making a choice.
public class Car {
public Engine { get; set; }
//more properties here
}
public class EngineFactory {
public Engine CreateEngine(EngineType type {
switch (type) {
case Big:
return new BigEngine();
case Small:
return new SmallEngine();
}
}
}
public class Engine {
}
public class BigEngine : Engine {
}
public class SmallEngine : Engine {
}
public class CarCreator {
public _engineFactory = new EngineFactory();
//more factories
public Car Create() {
Car car = new Car();
car.Engine = _engineFactory.CreateEngine(ddlEngineType.SelectedValue);
//more setup to follow
return car;
}
}
The problem you tell of can be solved using Dependency Injection.
There're many frameworks implementing this pattern (for example, for .NET - excellent Castle.Windsor container).
I think elder_george is correct: you should look into DI containers. However, you might want to check the builder pattern (here too), which deals with "constructing" complex objects by assembling multiple pieces. If anything, this might provide you with some inspiration, and it sounds closer to your problem than the Factory.
You can get around having to use a lot of if or switch statements if you introduce the logic of registration in your factory, a registration entry would add a binding to your dictionary in your factory:
Dictionary<Type,Func<Engine>> _knownEngines;
In the above line, you bind a type to a factory function for example like so:
private void RegisterEngine<TEngineType>(Func<T> factoryFunc) where TEngineType : Engine
{
_knownEngines.Add(typeof(TEngineType), factoryFunc);
}
This would allow you to call:
RegisterEngine<BigEngine>(() => new BigEngine());
on your factory
So now you have a way of allowing your factory to know about a large number of engines without needing to resort to if/switch statements. If all your engines have a parameterless constructor you could even improve the above to:
public void RegisterEngine<TEngineType>() where TEngineType : Engine, new()
{
_knownEngines.Add(typeof(TEngineType), () => new TEngineType());
}
which would allow you to register your engines that your factory can create like so:
RegisterEngine<BigEngine>();
Now we simply need a way of associating a user input to the right type.
If we have some sort of enumeration then, we might might want to map the enum values to their corresponding type. There are many ways to achieve this, either with a dictionary in a similar way as we have done already, but this time it is an enum as a key and a type as a value or by decorating the enum values with their corresponding type as demonstrated here (If you have a very large number of values, this possibility could be interesting)
But, we can skip all this and just take a shortcut and associate the enumeration with the factory function directly.
So we would make our Dictionary look like this:
Dictionary<MyEngineEnumeration,Func<Engine>> _knownEngines;
You would register your engines
public void RegisterEngine<TEngineType>(MyEngineEnumeration key) where TEngineType : Engine, new()
{
_knownEngines.Add(key, () => new TEngineType());
}
like so:
RegisterEngine(MyEngineEnumeration.BigEngine);
And then you would have some sort of create method on your factory class that takes your enumeration value as key:
public Engine ResolveEngine(MyEngineEnumeration key)
{
// some extra safety checks can go here
return _knownEngines[key]
}
So your code would set your
Car.Engine = EngineFactory.ResolveEngine((MyEngineEnumeration)ddlEngine.SelectedValue)
You could follow the same pattern with wheels and so on.
Depending on your requirements, following a registration/resolution approach would allow you to potentially configure your available engines externally in an xml file or a database and allow you to make more engines available without modifying the release code file but by deploying a new assembly which is an interesting prospect.
Good luck!
You could use something like this:
Define a class representing an option within a set of options, ie. a TireType class, BodyType class.
Create an instance of the class for each option, get the data from a store. Fill a collection, ie TireTypeCollection.
Use the collection to fill any control that you show the user for him to select the options, in this way the user selects actually the option class selected.
Use the obejcts selected to build the class.
If any functionality requires chnges in behavior, you could use lamdas to represent that functionality and serialize the representation of the code to save it the store; or you could use delegates, creating a method for each functionality and selecting the correct method and saving it into a delegate on object creation.
What I would consider important in this approach is that any option presented to the user is fully functional, not only a list of names or ids.
You can try the policy class technique in C++.
http://beta.boost.org/community/generic_programming.html#policy
Are you simply asking if you can create an instance of a class based on a string (or maybe even a Type object)?
You can use Activator.CreateInstance for that.
Type wheelType = Type.GetType("Namespace.WheelType");
Wheel w = Activator.CreateInstance(wheelType) as Wheel;
You'd probably want to checking around the classes that you wind up creating, but that's another story.