I see a lot of classes that look like:

class Student extends Model {
    public string major;
    public string minor;

class Employee extends Model {
    public string department;
    public string building;

These kind of classes are mostly used to hold data. My question is, should these aliases for Model class exist just because they have different properties? At most, the differences between them are accessors. Are these kinds of classes good or bad? Why don't I see more of:

student = Model::fromArray(['major' => 'a', 'minor' => 'i']);
employee = Model::fromArray(['department' => 'd', 'building' => 'b']);

This is more about style rather than specific application. I see that when it comes to presentation/view, people don't care much about types, a lot of time data is passed as arrays to template subsystem and don't create Presentation Models.

Data Transfer Objects also don't have behaviours and I get some answer from this article LocalDTO about why DTO shouldn't be used locally (only for type checking?). I'm looking for more general case on when to use (or not) these behaviour less classes.

  • 3
    There's not enough information in your question to provide a meaningful answer. It would depend on your application's specific requirements. – Robert Harvey Dec 11 '15 at 7:02
  • What "behavior" those two objects have? Is there none? Or is all behavior inside the Model class? – Euphoric Dec 11 '15 at 7:06
  • @Euphoric yes, all behaviour is from the Model class. – imel96 Dec 11 '15 at 14:36
  • @RobertHarvey I edited my question – imel96 Dec 11 '15 at 15:42
  • 1
    when it comes to presentation/view, people don't care much about types -- I dispute that assertion. People use View Models all the time. – Robert Harvey Dec 11 '15 at 16:21

Yes, they should exist, and they are a good thing.

The value of types is providing information on what values of that type contain and how they can be accessed. If you didn't define classes for Employee and Student, you would not have this information present in the type, and therefore would rely on the programmer to not only keep track of when they are working on an Employee or a Student, but also to keep track of which properties exist and what their types is. The burden of validating correct usage is placed then on the programmer, not on the language and its compiler.

You don't necessarily need this information. After all, the programmer can just try to keep it in their head or look it up somewhere else in the code. Having it just makes it much easier to maintain a codebase, because the additional type information provided to code that works with values of that type assists the programmer to ensure correctness by letting the compiler, interpreter or linter do some of the work.

|improve this answer|||||
  • I am aware of how they can be useful for type checking. On the other hand, one of the reason I raise the question is because I feel burdened with the abundance of these kind of classes. I also can't remember specific reference on why it should be done that way, I only remember that it's common to do it in C, e.g. typedef Student { string major; string minor }, which doesn't have any behaviour. Would be great if you can point to any reference. – imel96 Dec 11 '15 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.