public class Condition
{
public Condition(string field)
{
this.field = field;
}
readonly string field;
}
public class StringCondition : Condition
{
public StringCondition(string field, string value, SOperator op)
: base(field)
{
this.value = value;
this.op = op;
}
public enum Operator
{
SC_EQUALS,
SC_NOT_EQUALS,
SC_CONTAINS,
SC_DOESNT_CONTAIN
}
readonly Operator op = Operator.SC_EQUALS;
readonly string value;
}
[.net] class organization in c#
Author
I am writing a class to help me look in a database for entries that meet certain conditions. I want to be able to test for various kinds of conditions (strings, integers, etc). I have a Condition class, and inheriting from that will have my various other classes. For example:
What I want to know is, rather than having a separate "Operator op" in each subclass, can I (should I?) just put an "object op" in the Condition class, and just box the string/int/whatever into the object in the subclasses? Can enums "inherit"? i.e. could I say something like public enum StringOperator : Operator { /* values */ }, and then just have Operator op in the base class, and assign to it in the subclasses? Same for value... rather than having "string value" in one class, "int value" in another, etc, can I just have "object value", and just assign to it in the constructor?
Should I even do that at all? It just seems ugly to me to have all these different subclasses with basically the same 3 members (field, op, value), but have to redeclare 2 of them in every one of the subclasses. Is there a better way to write this?
Author
I want to use the Condition objects to find entries in my database that pass certain criteria. More specifically, I have a searchDB function that I want to pass an array/vector of Condition objects to. Then, the search function will look for all entries in my database where each Condition holds. e.g. one StringCondition might have {field="Name", op=SC_CONTAINS, value="Bob"}. Then it will look for all entries in the database that have "Bob" somewhere in the Name field.
Ah, I see now. Your concern is the duplicated code you'll be putting in each of the derived classes for int, double, long, boolean, and so on? In C# 1.1 there isn't a particularly elegant solution for this, though you might consider just having "ObjectCondition" (which accepts objects) and letting ToString() work its magic.
However, in C# 2.0, it's a whole different story since you can use generics. For instance, instead of StringCondition, IntCondition, and so on, you might have a GenericCondition<T> that can handle all the identical logic in the same way, with no duplication.
I'm moving this to the .NET forum in the hopes that the smart people over there can give you a leg up.
However, in C# 2.0, it's a whole different story since you can use generics. For instance, instead of StringCondition, IntCondition, and so on, you might have a GenericCondition<T> that can handle all the identical logic in the same way, with no duplication.
I'm moving this to the .NET forum in the hopes that the smart people over there can give you a leg up.
Using an object would solve the problem of duplicate code, but the boxing operation might be a bit expensive (I just guessed that there will be some iterating over a larger amount of data). I'm not quite sure I understand exactly what you want to do, since there's no public functions or properties in the example code. Could you please add some code to show how you want to use the operator class?
Author
I don't have any public functions or properties because the class will only be used internally in my assembly.
As far as the operator, I was hoping to have something like this:
Then I could create one:
StringCondition sc = new StringCondition("Name", "Bob", SC_CONTAINS);
and read the values from it doing something like:
string blah = (string) sc.value;
As far as the operator, I was hoping to have something like this:
public class Condition { public Condition(string field) { this.field = field; } readonly string field; readonly Operator op; readonly object value; } public class StringCondition : Condition { public StringCondition(string field, string value, SOperator op) : base(field) { this.value = (object) value; this.op = (Operator) op; } public enum SOperator : Operator { SC_EQUALS, SC_NOT_EQUALS, SC_CONTAINS, SC_DOESNT_CONTAIN } }Then I could create one:
StringCondition sc = new StringCondition("Name", "Bob", SC_CONTAINS);
and read the values from it doing something like:
string blah = (string) sc.value;
but then I suspect you'll handle the comparing in the objects that uses the class?
Have you thought about using a virtual function to handle the comparing?
You didn't show any code where you actually use the comparing object.. That would be nice. Now you're just setting/getting a variable.
Have you thought about using a virtual function to handle the comparing?
You didn't show any code where you actually use the comparing object.. That would be nice. Now you're just setting/getting a variable.
Author
I'm not really sure what you're asking. I'm going to be using the Conditions to build an SQL query that will be passed to an SQL database to retrieve the answer. I'm not doing the "comparing" in any of my classes, just using the Condition objects to build the appropriate SQL query.
Well.. how you build the query, then. It seems like you shouldn't need to expose the variable. The object could generate the query for you using a virtual method. This way the way each inherited class stores their data will be transparent to the outside.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
