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

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

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

Answer 1

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.