کاربرد اصول SOLID در طراحی برنامه‌نویسی اندروید

1401-01-20
ارسال شده توسط
اندروید
اصول solid در کاتلین

اصول SOLID مجموعه‌ای از پنج اصل طراحی شی‌گرا هستند که به بهبود کیفیت کد، کاهش پیچیدگی و افزایش قابلیت نگهداری کمک می‌کنند. در برنامه‌نویسی اندروید، این اصول باعث می‌شوند کد تمیزتر، قابل تست‌تر و منعطف‌تر باشد، به طوری که توسعه‌دهندگان بتوانند راحت‌تر آن را تغییر دهند یا گسترش دهند.

با رعایت این اصول:

  • کدها خواناتر و درک آن‌ها ساده‌تر خواهند بود.
  • وابستگی‌های بین کلاس‌ها کاهش می‌یابد.
  • قابلیت تست‌پذیری افزایش می‌یابد.
  • توسعه و نگهداری کد آسان‌تر خواهد شد.

تعریف هر یک از اصول SOLID با مثال کد

1. اصل تک مسئولیتی (Single Responsibility Principle – SRP)

هر کلاس باید فقط یک دلیل برای تغییر داشته باشد، یعنی تنها یک مسئولیت مشخص را بر عهده داشته باشد.

1
2
3
4
5
6
7
8
9
10
11
class FileManager {
    fun saveFile(fileName: String, content: String) {
        // ذخیره محتوا در فایل
    }
}
 
class Logger {
    fun log(message: String) {
        // ثبت لاگ در سیستم
    }
}

در اینجا، مدیریت فایل و ثبت لاگ از هم جدا شده‌اند تا هر کلاس فقط یک مسئولیت داشته باشد.

2. اصل باز-بسته (Open/Closed Principle – OCP)

کلاس‌ها باید برای توسعه باز و برای تغییر بسته باشند. به این معنا که باید بتوان عملکرد جدیدی را بدون تغییر در کد موجود اضافه کرد.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
abstract class Payment {
    abstract fun pay(amount: Double)
}
 
class CreditCardPayment : Payment() {
    override fun pay(amount: Double) {
        println("پرداخت از طریق کارت اعتباری: $amount")
    }
}
 
class PayPalPayment : Payment() {
    override fun pay(amount: Double) {
        println("پرداخت از طریق PayPal: $amount")
    }
}

در اینجا، برای اضافه کردن روش پرداخت جدید، فقط یک کلاس جدید ایجاد می‌شود و نیازی به تغییر کلاس‌های موجود نیست.

3. اصل جایگزینی لیسکوف (Liskov Substitution Principle – LSP)

معرفی 10 اپلیکیشن آموزشی خوب برای کودکان
خواندن این مقاله

هر کلاس فرزند باید بتواند بدون تغییر در رفتار برنامه، جایگزین کلاس والد شود.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
open class Bird {
    open fun fly() {
        println("پرواز می‌کنم")
    }
}
 
class Sparrow : Bird() {
    override fun fly() {
        println("گنجشک در حال پرواز است")
    }
}
 
class Penguin : Bird() {
    override fun fly() {
        throw UnsupportedOperationException("پنگوئن نمی‌تواند پرواز کند")
    }
}

در اینجا، Penguin اصل LSP را نقض می‌کند زیرا رفتار متفاوتی دارد. بهتر است کلاس پایه تغییر کند تا فقط پرندگان پرنده را شامل شود.

4. اصل جداسازی واسط‌ها (Interface Segregation Principle – ISP)

یک کلاس نباید مجبور به پیاده‌سازی متدهایی شود که به آن نیاز ندارد.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
interface Worker {
    fun work()
    fun eat()
}
 
class HumanWorker : Worker {
    override fun work() {
        println("انجام کار")
    }
 
    override fun eat() {
        println("خوردن غذا")
    }
}
 
class RobotWorker : Worker {
    override fun work() {
        println("ربات در حال کار کردن است")
    }
 
    override fun eat() {
        throw UnsupportedOperationException("ربات‌ها غذا نمی‌خورند")
    }
}

اینجا RobotWorker متدی را پیاده‌سازی کرده که نیازی به آن ندارد، بنابراین باید اینترفیس‌ها را تفکیک کنیم:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
interface Worker {
    fun work()
    fun eat()
}
 
class HumanWorker : Worker {
    override fun work() {
        println("انجام کار")
    }
 
    override fun eat() {
        println("خوردن غذا")
    }
}
 
class RobotWorker : Worker {
    override fun work() {
        println("ربات در حال کار کردن است")
    }
 
    override fun eat() {
        throw UnsupportedOperationException("ربات‌ها غذا نمی‌خورند")
    }
}

اینجا RobotWorker متدی را پیاده‌سازی کرده که نیازی به آن ندارد، بنابراین باید اینترفیس‌ها را تفکیک کنیم:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
interface Workable {
    fun work()
}
 
interface Eatable {
    fun eat()
}
 
class HumanWorker : Workable, Eatable {
    override fun work() {
        println("انجام کار")
    }
 
    override fun eat() {
        println("خوردن غذا")
    }
}
 
class RobotWorker : Workable {
    override fun work() {
        println("ربات در حال کار کردن است")
    }
}

5. اصل وابستگی معکوس (Dependency Inversion Principle – DIP)

ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند، بلکه هر دو باید به انتزاع وابسته باشند.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
interface NotificationService {
    fun sendNotification(message: String)
}
 
class EmailNotification : NotificationService {
    override fun sendNotification(message: String) {
        println("ارسال ایمیل: $message")
    }
}
 
class SMSNotification : NotificationService {
    override fun sendNotification(message: String) {
        println("ارسال پیامک: $message")
    }
}
 
class NotificationManager(private val notificationService: NotificationService) {
    fun notifyUser(message: String) {
        notificationService.sendNotification(message)
    }
}

در اینجا NotificationManager وابسته به NotificationService است، نه کلاس‌های پیاده‌سازی خاص. این باعث افزایش انعطاف‌پذیری و تست‌پذیری کد می‌شود.

Notification در اندروید
خواندن این مقاله

نتیجه‌گیری

اصول SOLID در طراحی برنامه‌نویسی اندروید به توسعه‌دهندگان کمک می‌کنند تا کدهای تمیزتر، مقیاس‌پذیرتر و قابل نگهداری‌تر بنویسند. با رعایت این اصول، پروژه‌ها منعطف‌تر شده و تغییرات در آن‌ها بدون تخریب ساختار کلی انجام می‌شود. یادگیری و به‌کارگیری این اصول یکی از مهم‌ترین مهارت‌هایی است که هر توسعه‌دهنده‌ی اندروید باید داشته باشد.

برچسب ها:

دیدگاهتان را بنویسید