Kan noen beskrive den eksakte forskjellen mellom løs kobling og tett kobling i det objektorienterte paradigmet?
Tett kobling er når en gruppe klasser er svært avhengige av hverandre.
Dette scenariet oppstår når en klasse påtar seg for mye ansvar, eller når en bekymring er spredt over mange klasser i stedet for å ha sin egen klasse.
Løs kobling oppnås ved hjelp av et design som fremmer enkeltansvar og separasjon av bekymringer.
En løst koblet klasse kan brukes og testes uavhengig av andre (konkrete) klasser.
Grensesnitt er et effektivt verktøy for frikobling. Klasser kan kommunisere gjennom grensesnitt i stedet for gjennom andre konkrete klasser, og enhver klasse kan være i den andre enden av kommunikasjonen ved å implementere grensesnittet.
Eksempel på tett kobling:
class CustomerRepository
{
private readonly Database database;
public CustomerRepository(Database database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
class Database
{
public void AddRow(string Table, string Value)
{
}
}
Eksempel på løs kobling:
class CustomerRepository
{
private readonly IDatabase database;
public CustomerRepository(IDatabase database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
interface IDatabase
{
void AddRow(string Table, string Value);
}
class Database : IDatabase
{
public void AddRow(string Table, string Value)
{
}
}
Et annet eksempel her.
I objektorientert design refererer graden av kobling til hvor mye utformingen av en klasse avhenger av utformingen av en annen klasse. Med andre ord, hvor ofte fører endringer i klasse A til tilsvarende endringer i klasse B? Tett kobling betyr at de to klassene ofte endres sammen, mens løs kobling betyr at de stort sett er uavhengige. Generelt anbefales løs kobling fordi det er enklere å teste og vedlikeholde.
Du kan finne denne artikkelen av Martin Fowler (PDF) nyttig.
Løs kobling er svaret på gamle tiders hardkodede avhengigheter og relaterte problemer som hyppig rekompilering ved endringer og gjenbruk av kode. Den legger vekt på å implementere arbeidslogikken i komponenter og unngå løsningsspesifikk kode der.