Me and two other colleagues are trying to understand how to best design a program. For example, I have an interface ISoda and multiple classes that implement that interface like Coke, Pepsi, DrPepper, etc....
My colleague is saying that it's best to put these items into a database like a key/value pair. For example:
Key | Name
--------------------------------------
Coke | my.namespace.Coke, MyAssembly
Pepsi | my.namespace.Pepsi, MyAssembly
DrPepper | my.namespace.DrPepper, MyAssembly
... then have XML configuration files that map the input to the correct key, query the database for the key, then create the object.
I don't have any specific reasons, but I just feel that this is a bad design, but I don't know what to say or how to correctly argue against it.
My second colleague is suggesting that we micro-manage each of these classes. So basically the input would go through a switch statement, something similiar to this:
ISoda soda;
switch (input)
{
case "Coke":
soda = new Coke();
break;
case "Pepsi":
soda = new Pepsi();
break;
case "DrPepper":
soda = new DrPepper();
break;
}
This seems a little better to me, but I still think there is a better way to do it. I've been reading up on IoC containers the last few days and it seems like a good solution. However, I'm still very new to dependency injection and IoC containers, so I don't know how to correctly argue for it. Or maybe I'm the wrong one and there's a better way to do it? If so, can someone suggest a better method?
What kind of arguments can I bring to the table to convince my colleagues to try another method? What are the pros/cons? Why should we do it one way?
Unfortunately, my colleagues are very resistant to change so I'm trying to figure out how I can convince them.
