برنامه نویس موبایل (فلاتر ، اندروید ، یونیتی ، iOS)
اصل اول پیاده سازی SOLID با کدهای دارت برای فریم ورک Flutter
اصل تک مسولیتی “یا (Single Responsibility Principle) اولین اصل از SOLID است و می گوید که : یک کلاس باید بر روی یک هدف واحد تمرکز داشته باشد و به یک نگرانی مشخص رسیدگی کند. یعنی هر کلاس یا ساختار مشابه در کد شما باید فقط یک کار برای انجام دادن داشته باشد.
اگر کلاسهای شما چندین مسئولیت را به عهده بگیرند، دیگر مستقل از یکدیگر نیستند و شما در مقابل تغییرات باید کلاس های بیشتری را ویرایش کنید. و در نتیجه در مقابل یک تغییر کار جانبی بیشتری انجام می دهید و زمان بیشتری مصرف می کنید و پیچیدگی کد شما بیشتر می شود.
بنابراین، بهتر است با اطمینان از اینکه هر کلاس فقط یک مسئولیت دارد، از این مشکلات جلوگیری کنید.
فرض کنیم نرم افزاری داریم که با درخواست های تغییر مداوم مواجه است. شاید احساس کنید سادهترین و سریعترین روش، اعمال تغییرات در کلاس ها و یا اضافه کردن یک متد به کلاس مربوطه باشد. اما این کار در اغلب باعث ایجاد کلاس هایی با مسئولیت بیشتر می شود و نگهداری نرم افزار را بیش از پیش دشوارتر می کند.
بیایید با یک مثال عملی قضیه را از نزدیک و بهتر درک کنیم.
فرض کنید ما در حال نوشتن یک نرم افزار برای یک مشاور املاک هستیم. ما یک کلاس Home ایجاد خواهیم کرد که به مشاور اجازه می دهد تعداد اتاق ها و قیمت و آدرس را از هر خانه دریافت و تنظیم کند و خانه را از Repository جستجو کند.
کد ابتدایی به این شکل خواهد شد:
class Home {
String _address;
int _cost;
Home(this._address, this._cost);
get getAddress => _address;
get getCost => _cost;
set setAddressy(String address) {
_address = address;
}
set setCost(int cost) {
_cost = cost;
}
void searchHome() {
//logic to search home goes here
}
}
با این حال، کد بالا اصل مسئولیت واحد را نقض می کند، زیرا کلاس Home دو مسئولیت دارد.
ابتدا، ویژگیهای (قیمت و آدرس) مربوط به خانه را تنظیم میکند. دوم اینکه خانه را در Repository جستجو می کند. متدهای Setter، شی Home را تغییر می دهند، که ممکن است زمانی که بخواهیم همان خانه را در Repository جستجو کنیم، مشکل ایجاد کند.
برای اعمال اصل تک مسولیتی، باید این دو مسئولیت را از هم جدا کنیم. در کد ریفکتور شده، کلاس Home فقط مسئول دریافت و تنظیم خصوصیات شی Home خواهد بود. به کد زیر دقت کنید:
class Home {
String _address;
int _cost;
Home(this._address, this._cost);
get getAddress => _address;
get getCost => _cost;
set setAddressy(String address) {
_address = address;
}
set setCost(int cost) {
_cost = cost;
}
}
class RepositoryView {
final Home home;
RepositoryView(this.home);
void searchHome() {
//logic to search home goes here
}
}
ما کلاس خانه اولیه را که دو مسئولیت داشت به دو کلاس تقسیم کردیم که هر کدام مسئولیت خاص خود را دارند.
در مقالات بعدی جزئیات پیاده سازی هر بخش از سالید با کدهای دارت رو با همدیگر بررسی می کنیم.
توضیح اصل اول : Single Responsibility Principle
توضیح اصل دوم : Open Closed Principle
توضیح اصل سوم : Liskov Substitution Principle
مطلبی دیگر از این انتشارات
اصل دوم پیاده سازی SOLID با کدهای دارت برای فریم ورک Flutter
مطلبی دیگر از این انتشارات
قراردادهای زبان Dart
مطلبی دیگر از این انتشارات
ویجت FutureBuilder و بارگیری مجدد future در فلاتر