اصل چهارم: Starve for loosely coupled designs
"به دنبال طراحی با اتصال سست بین اجزا باش"
اتصال بین اجزای برنامه نویسی باعث سخت‌تر شدن مدیریت تغییرات میشود؛ چرا که با تغییر یک بخش، بخش‌های متصل نیز دچار مشکل خواهند شد. اتصال‌ها از لحاظ نوع قدرت متفاوتند و اساسا سیستمی بدون اتصال وجود ندارد. لذا باید به دنبال یک طراحی با کمترین میزان قدرت اتصال یا همان سست اتصال باشیم.
تا به اینجا، اصل‌های دوم و سوم ما را در کاهش وابستگی و اتصال قوی کمک کرده‌اند. استفاده از واسط‌ها، باعث کاهش وابستگی به نوع پیاده سازی میشود. استفاده از ترکیب نیز به نوعی باعث از بین رفتن وابستگی قوی بین کلاسهای فرزند و کلاس والد میشود و با روشی دیگر (استفاده از شیء در برگرفته شده برای پیاده سازی وظیفه‌ی تغییر کننده) وظایف را در کلاسها پیاده سازی میکند. در زیر نمونه‌ی اتصال قوی و نتیجه‌ی آن را می‌بینیم:
public class StrongCoupledConcreteA
{
public string GenerateString(string s) { return s + " from" + this.GetType().ToString(); }
}
public class StrongCoupledConcreteB
{
public void GenerateString(ref string s) { s += " from" + this.GetType().ToString(); }
}
public class Printer
{
bool condition;
public Printer(bool cond)
{
condition = cond;
}
public void SetCondition(bool value) { condition = value; }
public void Print()
{
string result;
string input = " this message is";
if (condition)
{
var stringGenerator = new StrongCoupledConcreteA();
result = stringGenerator.GenerateString(input);
}
else
{
var stringGenerator = new StrongCoupledConcreteB();
result = input;
stringGenerator.GenerateString(ref result);
}
Console.WriteLine(result);
}
}
public class Context
{
Printer printer;
public void DoWork()
{
printer = new Printer(true);
printer.Print();
printer.SetCondition(false);
printer.Print();
}
} حال کد بازنویسی شده را با آن مقایسه کنید:
public interface IStringGenerator
{
string GenerateString(string s);
}
public class LooslyCoupledConcreteA : IStringGenerator
{
public string GenerateString(string s)
{
return s + " from " + this.GetType().ToString();
}
}
public class LooslyCoupledConcreteB : IStringGenerator
{
public string GenerateString(string s)
{
return s + " from " + this.GetType().ToString();
}
}
public class Printer
{
bool condition;
public Printer(bool cond)
{
condition = cond;
}
public void SetCondition(bool value) { condition = value; }
public void Print()
{
string result;
string input = " this message is";
IStringGenerator generator;
if (condition)
{
generator = new LooslyCoupledConcreteA();
}
else
{
generator = new LooslyCoupledConcreteB();
}
result = generator.GenerateString(input);
Console.WriteLine(result);
}
} با کمی دقت مشاهده میکنیم که در کلاسهای strongly coupled با اینکه هدف هر دو کلاس تولید یک رشته است، ولی عدم وجود پروتکل باعث شده است نحوه‌ی گرفتن ورودی و برگرداندن خروجی متفاوت شود و در نتیجه نیازمند به اضافه کردن پیچیدگی در کلاس فراخوانی کننده‌ی آنها می‌شویم. این در حالی است که در روش loosely coupled با ایجاد یک پروتکل (واسط IStringGenerator ) این پیچیدگی از بین رفته است. در اینجا نوع اتصال (وابستگی) از جنس اتصال (وابستگی) قوی به تعریف (prototype) و شاید به نوعی نحوه‌ی پیاده سازی متد میباشد.
SOLID Principles *
پنج اصل بعدی به اصول SOLID معروف هستند.
S: Single Responsibility
O: Open/Closed
L: Liskov’s Substitution
I: Interface Segregation
D: Dependency Injection
اصل پنجم: Single responsibility
"به دنبال ماژول‌های تک مسئولیتی باش"
در این قسمت مقصود از مسئولیت، «دلیلی است که کلاس باید تغییر کند» بدین معنا که اگر کلاسی با چند دلیل متفاوت مجبور به تغییر شود، آن کلاس چند مسئولیتی است. کلاسهای چند مسئولیتی عموما کد حجیمی دارند؛ نام آنها تعریف دقیقی را از مسئولیتشان ارائه نمی‌دهد و با عنوانی بسیار کلی نامگذاری میشوند و اشکال زدایی آنها بسیار طاقت فرساست. از طرفی، چند مسئولیتی بودن یک کلاس، باعث از بین رفتن مزایای توارث میشود. مثلا فرض کنید دو مسئولیت A,B در واسطی بیان میشوند که به یکدیگر مرتبط نبوده و مستقلند. برای مسئولیت A دو پیاده سازی و برای مسئولیت B، سه پیاده سازی در نظر گرفته شده است و جمعا برای پشتیبانی از تمامی حالات باید شش کلاس پیاده ساز، در نظر گرفته شود که توارث را سخت و بی معنی میکند زیرا قابلیت استفاده مجدد را از توارث سلب کرده است. با این وجود عملا رعایت همچین نکته‌ای در دنیای واقعی کار سختی است.
مثال زیر این مشکل را بیان می‌دارد:
// single responsibility principle - bad example
interface IEmail
{
void SetSender(string sender);
void SetReceiver(string receiver);
void SetContent(string content);
}
class Email : IEmail
{
public void SetSender(string sender)
{
throw new NotImplementedException();
}
public void SetReceiver(string receiver)
{
throw new NotImplementedException();
}
public void SetContent(string content)
{
throw new NotImplementedException();
}
} در این مثال کلاس Email دارای دو مسئولیت (دلیل برای تغییر) است: الف- نحوه مقداردهی فرستنده و گیرنده براساس پروتکل‌های مختلف مانند IMAP, POP3 ، بدین معنا که با تغییر پروتکل نیاز به تغییر پیاده سازی خواهیم شد. ب- تعریف محتوای پیام، بدین معنا که برای پشتیبانی از محتوای html, xml نیاز به تغییر کلاس Email داریم.
با تغییر طراحی خواهیم داشت:
// single responsibility principle - good example
public interface IMessage
{
void SetSender(string sender);
void SetReceiver(string receiver);
void SetContent(IContent content);
}
public interface IContent
{
string GetAsString(); // used for serialization
}
public class Email : IMessage
{
public void SetSender(string sender)
{
throw new NotImplementedException();
}
public void SetReceiver(string receiver)
{
throw new NotImplementedException();
}
public void SetContent(IContent content)
{
throw new NotImplementedException();
}
} در اینجا واسط IContent مسئولیت پشتیبانی از xml, html را
خواهد داشت و نیازی به تغییر کلاس Email برای
پشتیبانی از این فرمت‌های محتوای پیام را نخواهیم داشت.
اصل ششم: Open for
extension, close for modification : Open/Closed Principle
"پذیرای توسعه و
بازدارنده از تغییر هر آنچه که هست، باش"
ا ین اصل می‌گوید طراحی باید به گونه‌ای باشد که با
اضافه شدن یک ویژگی، کدهای قبلی تغییری نکنند و فقط کدهای جدید برای پیاده سازی
ویژگی جدید نوشته شوند.
public class AreaCalculator
{
public double Area(object[] shapes)
{
double area = 0;
foreach (var shape in shapes)
{
if (shape is Square)
{
Square square = (Square)shape;
area += Math.Sqrt(square.Height);
}
if (shape is Triangle)
{
Triangle triangle = (Triangle)shape;
double TotalHalf = (triangle.FirstSide + triangle.SecondSide + triangle.ThirdSide) / 2;
area += Math.Sqrt(TotalHalf * (TotalHalf - triangle.FirstSide) *
(TotalHalf - triangle.SecondSide) * (TotalHalf - triangle.ThirdSide));
}
if (shape is Circle)
{
Circle circle = (Circle)shape;
area += circle.Radius * circle.Radius * Math.PI;
}
}
return area;
}
}
public class Square
{
public double Height { get; set; }
}
public class Circle
{
public double Radius { get; set; }
}
public class Triangle
{
public double FirstSide { get; set; }
public double SecondSide { get; set; }
public double ThirdSide { get; set; }
} در اینجا کلاس AreaCalculator برای محاسبه مساحت تمام اشیاء ورودی، مساحت تک تک اشیاء را محاسبه میکند و نتیجه را برمی‌گرداند. در این مثال با اضافه شدن شکل هندسی جدید، باید کد این کلاس تغییر کند که با اصل Open/Closed مغایر است. برای بهبود این کد طراحی زیر پیشنهاد شده است:
public class AreaCalculator
{
public double Area(Shape[] shapes)
{
double area = 0;
foreach (var shape in shapes)
{
area += shape.Area();
}
return area;
}
}
public abstract class Shape
{
public abstract double Area();
}
public class Square : Shape
{
public double Height { get { return _height; } }
private double _height;
public Square(double Height)
{
_height = Height;
}
public override double Area()
{
return Math.Sqrt(_height);
}
}
public class Circle : Shape
{
public double Radius { get { return _radius; } }
private double _radius;
public Circle(double Radius)
{
_radius = Radius;
}
public override double Area()
{
return _radius * _radius * Math.PI;
}
}
public class Triangle : Shape
{
public double FirstSide { get { return _firstSide; } }
public double SecondSide { get { return _secondSide; } }
public double ThirdSide { get { return _thirdSide; } }
private double _firstSide;
private double _secondSide;
private double _thirdSide;
public Triangle(double FirstSide, double SecondSide, double ThirdSide)
{
_firstSide = FirstSide;
_secondSide = SecondSide;
_thirdSide = ThirdSide;
}
public override double Area()
{
double TotalHalf = (_firstSide + _secondSide + _thirdSide) / 2;
return Math.Sqrt(TotalHalf * (TotalHalf - _firstSide) * (TotalHalf - _secondSide) * (TotalHalf - _thirdSide));
}
} در این طراحی، پیچیدگی محاسبه مساحت هر شکل به کلاس آن شکل منتقل شده است و با اضافه شدن شکل جدید نیازی به تغییر کلاس AreaCalculator نداریم.
در مقاله‌ی بعدی به سه اصل دیگر اصول SOLID خواهم پرداخت.
