Coupling – Reasons to Avoid Tight Coupling to a Model Class

coupling

By this I mean something like Student, which is modeling a Student table row:

class Student
{
    public string lastname;
    public string firstname;
}

It doesn't make sense to me to program to an Interface or even inherit from a "regular" class. I really don't see where I have to worry about coupling here, if I am using something like the Entity Framework (or any other abstraction to the database), where I have a Separation of Concerns already.

Sooner or later I have to know which class I am supposed to be using, and I'm having a hard time seeing any problems I might have in the future with tight coupling to the model class.

Even if I have,

class Student extends Person
{
    public string lastname;
    public string firstname;
}

So later I can do,

public function myFunc (Person somestudent)
{
    Person myPerson = somestudent;
}

I do not see the benefit as I want to know if someone is really a Student object.

I have seen these,

How to manage coupling in model classes

Shared database vs tightly coupled message model

C# – Data-Driven Design & Coupling – Mother may I? (did not seem to resolve the issue)

Best Answer

The primary reason for using an interface is Liskov Substitution principle. If you adhere to LSP, you can substitute a different class for different scenarios, e.g. for unit testing.

That being said, if your model is merely a simple data container-- it contains only read/write properties and has no behavior-- there is very little to substitute. Your unit testing code can just use the original model instead of a mock or stub. It isn't absolutely essential to use an interface with this type of model. I don't.

Related Topic