Software architecture design: Number of classes [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 6 years ago.

Improve this question

I will try to explain my question more clearly because the title is a little bit blurry. I have base class that has some properties. Let's say something like this:

public class BaseClas
{
    public int Property1 { get; set; }
    public bool Property2 { get; set; }
    ..............................
}

And I have approximately 70 classes that inherit from the base class, most of these classes just add one or two fields, for example:

public class DerivedClas1 : BaseClass
{
    public bool PropertyNew1 { get; set; }
}

public class DerivedClas2:  BaseClass
{
    public bool PropertyNew2 { get; set; }
}

My problem is that I have 70 classes that each of which has just one new field of type bool or int or datetime, etc. My question is: Is it a good architecture design to combine these classes somehow? And if so how should I combine them? I could use some kind of Dictionary<string,object> but this is not such a good idea. Any suggestions?

(I am using .Net 2.0)

Edit: These classes are used for filtering queries for reporting purposes.Base class defines base filters an开发者_JAVA技巧d every class defines filters specific for the report.

---

It all depends on your Architecture. I can think of at least one class in the core framework that has dozens, possibly hundreds of derived classes, many of which only add one or two fields, and many which don't even do that and only subclass in order to provide a nicer name or a base class for it's own application-specific abstractions. The name of this class? System.Exception

Another Example could be System.Web.Mvc.Controller, although that's stretching it even more than System.Exception (and I purposely left out System.Object and System.ValueType already).

You don't provide any real examples, so the answer is that yes, it can be appropriate, but maybe it isn't. If you are trying to do a generic data entry where you have "Manager" and "Employee" which derive from "Person", which in turn derives from "DataObject", that may be appropriate, but I would look at other ways, e.g. getting rid of "DataObject" and having multiple, specialized Services that provide database operations, but again, it depends on the picture as a whole.

Edit: You just clarified it's for filtering. In this case, can't you use a system where you only define the types of filters?

public abstract class Filter {

}

public class OrFilter : Filter {
    public string Clause1 {get; set;}
    public string Clause2 {get; set;}
}

public class ItemMustExistFilter : Filter {
     public string ItemName {get; set;}
}

public class Report {
    // For the sake of the example, I know that public setters on Lists are not
    // best practice
    public IList<Filter> Filters {get;set;}
}

That way, you only need concrete classes for Filters itself, and each report would have a list of them. Combine that with the use of Generics (see ram's answer) and you should have a pretty 'lightweight' system. Shame you're on .net 2, otherwise Dynamic LINQ would be useful. Sure that you can't use .net 3.5, which still runs on the 2.0 CLR?

---

Don't know the exact nature of your problem. It is not a question of whether you need 70 classes, its more a question of accurate description of the problem at hand, good design and maintainability. Does generics help ?

public class BaseClass
{
/* some basic properties go here*/
}

public class BaseClass<T>:BaseClass
{

T SomeSpecificProperty {get;private set;}
}

So when you need a "specific" class, you will have

var myObj = new BaseClass<Bool>();

You should also look into Decorator pattern if you want to "Decorate" your classes. Take a look at DoFactory Example

My 2 cents, hope it helps

---

What you are describing sounds fine to me - each of your reports has a class that describes the filters specific to that report and so if you have 70 reports then you are going to have 70 classes.

Like you say the alternative would be to do something like having a dictionary instead, which has its own set of drawbacks (to start with it isn't strongly typed).

Its tricky to suggest other alternatives without knowing more about the archetecture (does each report have its own class for displaying / retrieving the report? If so perhaps you could refactor so the properties are on that class instead, using attributes to identify filter parameters).

In short - if you don't have an alternative then it can't be bad design! :-)