I’ve been making MVC programs for work (I’m an intern) and I feel like I’m doing a pretty good job at abstraction, single responsibility, etc. But I have this feeling about how I keep making objects properties of other objects and I’m not sure if it’s a bad thing.
Example:
User
{
String Username;
Int32 UserID;
.
.
.
BusinessLogicClass Variable;
}
BusinessLogicClass
{
AnotherClass Variable;
AndAnother Variable2;
}
AnotherClass
{
IThinkYoureGetting ThePoint;
}
All my Classes are properties of the others in one massive hierarchy, It’s kind of what the business logic calls for but I can’t help but wonder if I should be trying to prevent something like this. So I end up effectively with one variable that I control the children of, but the classes are separate.
Is this something common? Is it bad? If it is bad, what should I do about it?
3
No, that is not necessarily bad. That is object-oriented programming: objects contain other objects. Each one is responsible for its own piece of the program, which often means encapsulating other objects.
For example, a car contains a transmission. That could be a complex class containing a bunch of other objects such as gears, clutch plates, etc. which could be abstracted as classes.
In an MVC framework, you should be careful to keep different concerns separate. For example, a view should not generally contain model objects: normally, the view communicates requested model updates through events, decoupling the two layers. But a view object could definitely contain other view objects, for example a panel containing buttons, text boxes, etc.
Business logic that pertains to program flow is strictly a concern for the Controller layer. Business logic that pertains to updating the model is a little more open to debate. In your example, it may be appropriate to put limited business logic in the User model, but only if that logic pertains to tasks such as validation, updating dependent fields, etc. in other words, tasks that are tightly coupled to the data contained in the User. It would not be appropriate for the User to contain logic that interacts with the UI or program flow.
8