When is a C# class with no methods poor design? [closed]

When is a class with no methods poor design?

From what I've read, a class with no methods (i.e. no behaviors) (AKA dumb class) is poor design, with the exception of Data Transfer Objects (DTOs). This is due to the purpose of DTOs being to reduce the overhead when transferring data to a remote interface (Local DTO). There appears to be some debate on DTOs and Plain Old Class Object (POCO VS DTO) and debate going further to anemic design (Anemic Model Domain).

So, where the dumb class in question is a local object (i.e. not for transferring data) are you generally better to refactor the attributes of the dumb class and implement them as a collection (e.g. Dictionary)? To quote Bill K (How can i write DAOs for resources with extensible properties), "Where you would have used an object, use a hashtable. For your attribute names use keys, for the attribute values, use the value in the hashtable."

My thinking when designing this dumb class was that of composition. Another class is composed of multiple dumb class objects (i.e. a collection of dumb class objects). Was my thinking wrong? If I am to implement the dumb class as a collection, I would have a collection of a collection of attributes.

I am of the understanding collections of collections of collections etc. is also poor design. Is there some guiding principle to balance these apparent choices of poor design?

As always any insight or guidance is appreciated.

Regards Shannon

If a class has no logic, then that would be considered a data-structure. For the question about whether to use a generic collection vs a type, I would choose creating types because of their expressiveness.

Take the following example.

var employee = new Dictionary<string, object>();
employee["FirstName"] = "Steve";
employee["LastName"] = "McQueen";
employee["DOB"] = new DateTime(1942, 1, 5);
employee["Salary"] = 215000m;

Here you have the problem of

being Stringly Typed
unable to implement logic within the "employee"
no possibility of being immutable
not being able to refactor

Contrast this with.

var employee = new Employee {
    FirstName = "Steve",
    LastName = "McQueen",
    DOB = new DateTime(1942, 1, 5),
    Salary = 215000m
};

You get the benefit of

being able to find references of employee
subclass employee
refactor employee (rename DOB to DateOfBirth without having to do a search and replace)
make properties immutable
compile time checking
add domain logic if ever needed
can impose invariants

Though the one downside to this is that you have to define a class, which means more typing, though I feel the benefits greatly outweigh the costs.

To elaborate on my examples above, suppose you wrote a method from a repository that returned an employee.

var employee = employeeRepository.GetById(25);

If employee were a dictionary in this example, I would have no Intellisense to know which attributes an employee has, let alone their types, this is also illustrated by @HighCore's comment. The only ways to determine this is to either

read the documentation (probably out-of-date or inaccurate)
execute the method and inspect with debugger (a waste of time and might not be possible in every scenario)

In the scenario of persisting a new employee, the dictionary runs into the same pitfalls and now you're at the peril of hoping the method you just executed returns meaningful error messages.

Recommended topics

Hot tags