1- اصل single responsibility (مسئولیت واحد)

اصل single responsibility بیان می کند که هر class باید تنها یک مسئولیت داشته باشد.

 data class User( var id:Long, var name:String, var password:String ){ Fun signIn(){      //this method will do signing in operation } Fun signOut(){      // this method will do signing out operation } } } 

 data class User( var id:Long, var name:String, var password:String ) Class AuthentivationService(){ Fun signIn(){  //this method will do signing in operation } Fun signOut(){ // this method will do signing out operation } } 

اگر

حالا فرض کنیم که ما باید در متدهای sign-in و sign-out ، فرایند authentication تعدادی تغییر ایجاد کنیم (شکل 1) ، در این صورت کلاس user ما تحت تأثیر قرار می گیرد.

آنگاه

برای حل مسئله باید کلاس جدیدی (شکل 2) ایجاد کنیم تا فرآیند authentication را مدیریت کرده و متدهای sign-in و sign-out را در آن کلاس move کنیم.

2- اصل open-closed

open: این بدان معناست که ما می توانیم feature های جدیدی را به کلاس های خود اضافه کنیم.

closed: این بدان معناست که feature های اصلی کلاس نباید تغییر کند.

 class Rectangle{ 	private var length 	private var height 	//getters / setters  … } class Circle{ 	private var radius  	//getters / setters  … }  class AreaFactory{ 	public fun calculateArea(shapes:ArrayList<Object>):Double{ 	var area = 0 	for (shape in shapes){ 		if(shape is Rectangle) { 		var rect = shape as Rectangle 		area += (rect.getLength()*rect.getHeight()) } else if (shape is Circle){ 	var circle = shape as Circle 	area += (circle.getRadius()*circle. getRadius ()*Math.PI) } else{ 	throw new RunTimeExeption(“shape not supported”)	 } } return area } } 

 Public interface Shape { 	fun getArea() } class Rectangle : Shape { 	private var length 	private var height 	//getters / setters  … override  fun getArea():Double { return (length*height) } class Circle: Shape { 	private var radius  	//getters / setters  … override  fun getArea():Double{ return (radius * radius *Math.PI) } class AreaFactory{ 	fun calculateArea(shapes:ArrayList<String>):Double{ 	var area:Double = 0.toDouble() 	for (shape in shapes){ 		area += shape.getArea() } return area } 	      } 

اگر

در شکل 1 می بینیم که یک دستور if else برای جدا کردن shape ها داریم ، و با افزایش shape ها ، آنها نیز به همان ترتیب به رشد خود ادامه می دهند ، زیرا کلاس برای modification (اصلاح) بسته نشده است ، یا برای extention (گسترش) نیز باز نیست.

آنگاه

ما با کمک interface این مشکل را برطرف می کنیم. در صورت نیاز به افزودن shape های بیشتر ، کلاس area factory به هیچ تغییری نیاز ندارد زیرا این کلاس از طریق اینترفیس shape ، برای توسعه باز است.

3- اصل جایگزینی liskov

کلاس فرزند (child) باید جایگزین کلاس پدر (parent) شود.

 abstract class Vehicle { protected var isEngineWorking = false abstract fun startEngine() abstract fun stopEngine() abstract fun moveForward() abstract fun moveBack() } class Car:Vehicle() {  override fun startEngine() { println("Engine started")  isEngineWorking = true } override fun stopEngine() { println("Engine stopped")  isFngineWorking = false } override fun moveForward() { println("Moving forward") } override fun moveBack() { println("Moving back!") } } class Bicycle:Vehicle(){ override fun startEngine() { TODO("Not yet implemented") } override fun stopEngine() { TODO("Not yet implemented") } override fun moveForward() { println("Moving forward") } override fun moveBack() { println("Moving back!") } } 

 interface Vehicle { fun move forward()  fun moveBack } abstract class VehicleWithEngine:Vehicle { private var isEngineWorking = false  open fun startEngine(){isEngineWorking = true}  open fun stopEngine(){isEngineWorking = false) } class Car:VehicleWithEngine(){  override fun startEngine() { super.startEngine()  println("Engine started") } override fun stopEngine() { super.stopEngine()  println("Engine stopped") } override fun moveForward() { println("Moving forward") } override fun moveBack() { println("Moving back!") } }  class Bicycle:Vehicle{  override fun moveForward() { println("Moving forward") } override fun moveBack() {  println("Moving back!") } } 

اگر

در شکل 1 هنگام ایجاد کلاس دوچرخه ، متدهای startEngine و stopEngine بی فایده خواهند بود زیرا دوچرخه موتور ندارد.

آنگاه

برای رفع این حالت ، ما می توانیم یک کلاس فرزند (child) جدید ایجاد کنیم (شکل 2) که از Vehicle ، extend می شود. این کلاس دارای موتور خواهد بود

4- اصل Interface segregation (تفکیک Interface)

این اصل بیان می کند که آن دسته از interface هایی که بسیار شلوغ و بزرگ(دارای متدهای اضافه) هستند ، باید به interface های کوچکتر تقسیم شود.

 interface Animal { fun eat()  fun sleep()  fun fly() } class Cat : Animal {  override fun eat() { println("Cat is eating fish") } override fun sleep() { println("Cat is sleeping on its owner's bed") } override fun fly() { TODO ( "Not yet implemented")   //cat can not fly!! } } class Bird : Animal { override fun eat() { println("Bird is eating forage") } override fun sleep() { println("Bird is sleeping in the nest") } override fun fly(){ println("Bird is flying in so high" } }	 

 interface Animal { fun eat() fun sleep() } interface FlyingAnimal { fun fly() } class Cat : Animal {  override fun eat() { println("Cat is eating fish") } override fun sleep() {  println("Cat is sleeping on its owner's bed") } } class Bird : Animal, FlyingAnimal { override fun eat() {   println("Bird is eating forage") } override fun sleep() { println("Bird is sleeping in the nest") } override fun fly() { println("Bird is flying in so high") } 

اگر

همانطور که در شکل 1 مشاهده می کنید برخی از حیوانات مانند گربه ها نمی توانند پرواز کنند . در حالی که implement و اجرای متد fly در آن ضروری است.

آنگاه

برای رفع این مشکل ، یک interface جدید (شکل 2) برای حیوانات پرنده ایجاد می کنیم و متد fly را از اینترفیس animalحذف می کنیم

5- اصل Dependency Inversion (وارونگی وابستگی)

این اصل بیان می کند که ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند.

 class AndroidDeveloper {  fun developerMobileApp(){ println("developing Android Application by using kotlin") } } class IosDeveloper {  fun developerMobileApp(){ println("developing iOS Application by using swift") } } fun main(){ val androidDeveloper = AndroidDeveloper()  val iosDeveloper = IosDeveloper()  androidDeveloper.developerMobileApp() iosDeveloper.developerMobileApp() } 

 interface MobileDeveloper{ fun developerMobileApp()  } class AndroidDeveloper (var mobileService: MobileServices): MobileDeveloper {     override fun developerMobileApp(){  println("developing Android Application by using kotlin." + "application will work with ${mobileService.serviceName}")  } enum class MobileServices (var serviceName: String) { HMS( serviceName: "Huawei Mobile Service"), GMSC serviceName: "Google Mobile Service"), BOTH( ServiceName: "Huawei Mobile Service and Google Mobile Service") } } class IosDeveloper : MobileDeveloper { override fun developerMobileApp({ println("developing iOS Application by using swift") } } fun main{ val developers = arrayListof (AndroidDeveloper (AndroidDeveloper. MobileServices.HMS) , IosDeveloper()) developers.forEach { developer -> developer.developerMobileApp() } } 

اگر

بیایید فرض کنیم که ما باید یک اپلیکیشن را برای Android و ios در شکل 1 توسعه دهیم.

آنگاه

برای رفع مشکل ، می توانیم یک interface (شکل 2) ایجاد کنیم و کلاس های AndroidDeveloper و IosDeveloper این interface را implement (پیاده سازی) خواهند کرد.

نوشته اصول S.O.L.I.D در کاتلین اولین بار در آموزشگاه اندروید ایران. پدیدار شد.