سورس ویژه پخش فیلم و سریال با درگاه زرین پال

آشنایی با قوانین SOLID در برنامه نویسی اندروید

اردیبهشت 23, 1399| سنا عبادی
آشنایی با قوانین SOLID در برنامه نویسی اندروید | وبلاگ مارکت اندروید ریور

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

SOLID چیست و چرا باید با آن آشنا شویم؟

در اصل ، SOLID یکی از مهمترین کلمات اختصاری در مفاهیم برنامه نویسی شی گرا است.استفاده از اصول SOLID در توسعه اندروید می تواند به داشتن کد تمیز و اصولی کمک شایانی کند.

بنابراین ، اگر توسعه دهندگان اندروید بدون استفاده از اصول طراحی ساختاری مانند اصول SOLID کدهای خود را طراحی و پیاده سازی کنند ،با مشکلات فراوانی رو به رو خواهند شد و نگهداری و توسعه هزینه بر خواهد بود.

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

SOLID چیست ؟!

SOLID مخفف اصولی برای پنج اصل طراحی در توسعه نرم افزار Object-Orient است که هدف آن ایجاد طرح های نرم افزاری انعطاف پذیر و قابل حفظ است. این پنج اصل توسط رابرت سی مارتین شرح داده شده است. اصول SOLID به طور خلاصه به شرح زیر است:

  • S — Single Responsibility Principle 
  • O –Open/Closed Principle
  • L –Liskov’s Substitution Principle
  • I — Interface Segregation Principle
  • D — Dependency Inversion Principle

که به اختصار :

  • SRP
  • OCP
  • LSP
  • ISP
  • DIP

آن ها را به کار میبریم .

چرا باید در توسعه نرم افزار از اصول SOLID استفاده کنیم؟

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

برخی از علائم برای شناسایی نرم افزار بد

  • Rigidity : سختی در کد به این معنی که تغییرات کوچک در کد و نرم افزار منجر به بازسازی کل پروژه می شود.

  • Fragility : شکنندگی در کد به این معنی که هر موقع تغییری در سیستم ایجاد می کنید در بخش یا بخش های دیگری از سیستم که حتی هیچ ربطی به آن قسمت ندارد با خطا و مشکل مواجه می شود. در واقع با مفهومش با Rigidity بسیار نزدیک است که علت و معلول هم هستند.

  • Immobility : عدم تحرک در کد به این معنی که نتوانیم آن قسمت از کد یا کامپوننت را در دیگر بخش های سیستم استفاده کنیم.

  • Viscosity : چسبناکی در کد به این معنی که مقاومت در مقابل در تغییر خواهد بود . وقتی که ساخت مجدد و تست سیستم برای ما سخت می شود و ترجیح می دهیم که از تغییراتی که در نظر داشتیم صرف نظر کنیم .

1.اصل تک وظیفه ایی یا SRP :

اصل تک وظیفه ایی نشان می دهد که هر کلاس باید یک و تنها یک مسئولیت داشته باشد. به عبارت دیگر ، اگر کلاس ما بیش از یک مسئولیت را انجام دهد ، باید عملکردها و مسئولیتها را در کلاسهای مختلف تقسیم کنیم. بنابراین ، این باعث می شود کلاس قوی تر شود.

همچنین بخوانید :  آموزش Flutter : ویجت چیست ؟

به عنوان مثال در مثال زیر ، اگر کلاس User شامل ویژگی ها و رفتارهای کلاس UserType باشد ، طراحی خوبی برای این کلاس نخواهد بود زیرا در این شرایط کلاس بیش از یک مسئولیت دارد. بنابراین ، اگر می خواهیم هر مسئولیتی را تغییر دهیم ، احتمالاً باید مسئولیت های دیگر را تغییر دهیم.

public class User{

    private String firstName;
    private String lastName;

    public String getFirstName(){
        return firstName;
    }

    public void setFirstName(String firstName){
        this.firstName = firstName;
    }

    public String getLastName(){
        return lastName;
    }

    public void setLastName(String lastName){
        this.lastName = lastName;
    }
}

public class UserType extends User{
    private int selecting;
    public int getSelecting(){
        return selecting;
    }

    public void setSelecting(int selecting){
        this.selecting = selecting;
    }
  
    public boolean isSpecialUser(){
        return selecting == 7;
    }
}

2. اصل باز- بسته

در مفاهیم شی گرا ، اصل Open / Closed بیان می کند “اجزای نرم افزاری مانند کلاس ها ، کامپوننت ها ، ماژول ها باید برای گسترش باز باشند اما برای ویرایش بسته هستند”.

احتمالاً ، این دو بخش از اصل Open / Closed متناقض به نظر می رسند ، اما اگر به طور صحیح و دقیق کلاسهای خود و وابستگی های آنها را بسازید ، می توانید بدون ویرایش کد موجود ، عملکردی را اضافه کنید. علاوه بر این ، می توان با ایجاد کلاس های جدیدی که رابط ها را پیاده سازی می کند ، عملکردی را اضافه کرد. با استفاده از این روش می توانید خطر بروز باگ های جدید را به کد موجود کاهش دهید و منجر به کاربردهای قوی تر شود. به عنوان مثال ، کلاسهای زیر می توانند با استفاده از این اصل تغییر یابند.

public class Triangle{
    public double base;
    public double height;
}
public class Square{
    public double side;
}
public class AreaCalculate{
public double getTriangleArea(Triangle triangle){
        return   area = (triangle.base * triangle.height)/2;
    }

    public double getSquareArea(Square square){
        return   square.side * square.side;
    }

بعد از استفاده از OCP :

public interface Shape{
    public double getArea();
}

public class Triangle implements Shape{
    double base;
    double height;
    public double getArea(){
        return (base * height)/2;
    }
}
public class Square implements Shape{
    public double side;
   public double getArea(){
        return side * side;
    }
}

public class AreaCalculate{
    public double getShapeArea(Shape shape){
        return shape.getArea();
    }
}

3.اصل جانشینی لیسکاو

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

public interface ClickListener{
    public void onClick();
  }

  
  public class SampleFragment implements ClickListener{
    @Override
    public void onClick(){
      decrementClickCount();
        //You should manage the logic here!          
    }
    
    public void decrementClickCount(){
        
    }    
  }
  
  public class TestFragment implements ClickListener{
    @Override
    public void onClick(){
        incrementClickCount();
        //You should manage the logic here!
    }
    
    public void incrementClickCount(){
        
    }
  }
  
  
  public void onButtonClick(ClickListener clickListener){
//Handling the changes and requirements here would be a wrong place     and an incorrect solution!
     clickListener.onClick();
  }

4 . اصل تجزیه اینترفیس

اصل تفکیک رابط (اینترفیس) ، کلاسهایی را نشان می دهد که اینترفیس ها را پیاده سازی می کنند ، نباید مجبور شوند فانکشن هایی را که از آنها استفاده نمی کنند ، پیاده کنند. این اصل به این واقعیت مربوط می شود که بسیاری از اینترفیس های خاص بهتر از یک اینترفیس کاربری عمومی و بزرگ که شامل کلی متد میشود , هستند. علاوه بر این ، این اولین اصل است که در اینترفیس استفاده می شود ، تمام اصول قبلی در کلاس ها اعمال می شود. به عنوان مثال ، اگر اینترفیس زیر را داشته باشیم ، کلاینت را مجبور می کند تا حتی در صورت عدم نیاز به کلیک های طولانی ، onLongClick را پیاده سازی کند. بنابراین ، می تواند منجر به روشهای بلااستفاده شود. در یک کلام ، می توان با داشتن دو اینترفیس جداگانه ،روش های بی استفاده را نادیده بگیریم.

public interface MyOnClickListener{
    void onClick(View v);
    boolean onLongClick(View v);
    void onTouch(View v, MotionEvent event);
}

بعد از استفاده از اصل :

public interface OnClickListener{
  
    void onClick(View v);
}

public interface OnLongClickListener{
  
    boolean onLongClick(View v);
}
public interface OnTouchListener{
 
    void onTouch(View v, MotionEvent event);
}

5.اصل وارونگی وابستگی :

این اصل نشان می دهد که ماژول های سطح بالا نباید به سطح پایین وابسته باشند. بنابراین ، هر دو باید به abstractions بستگی داشته باشند. علاوه بر این ، abstractions نباید به جزئیات بستگی داشته باشد. جزئیات باید به abstractions بستگی داشته باشد.
در یک کلام ، کلاسها باید به abstractions بستگی داشته باشند ، اما به پیوند بستگی ندارند. به عنوان مثال ، در مثال زیر ، یک لایه abstractions جدید از طریق رابط IEngine برای از بین بردن وابستگی بین دو کلاس اضافه می شود.

public class Engine{
 }

public class ToyCar{
    Engine engine;
    ToyCar(){
        Engine = new Engine();
    }
}

بعد از استفاده از اصل :

public interface IEngine{
}

public class Engine implements IEngine{
    double capacity;
}

public class ToyCar{
    IEngine iEngine;
    ToyCar(IEngine engine){
        iEngine = engine;
    }
}


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

همچنین بخوانید :  نحوه Import سورس اندروید از گیت هاب و گیت لب

در آخر شما را به یک ریپوزیتوری در گیت هاب اندروید ریور ارجاع می دهم . پیشنهاد میکنم حتما از آن استفاده کنید .

در آخر هم مانند همیشه خوشحال می شوم دیدگاهاتون رو درباره این مقاله برای من بفرستید حتما اونهارو مطالعه می کنم و برای شما پاسخ ارسال میکنم..

سنا عبادی نویسنده مقاله

توسعه دهنده موبایل به ویژه سیستم عامل اندروید ، هم بنیانگذار اندروید ریور و در تلاش برای تحقق یک رویا..



می تونی سنا عبادی رو توی شبکه های اجتماعی هم دنبال کنی ...

مقالات مرتبط را بخوانید :


سورس های اندروید شامل تخفیف رو ببین !

به این مقاله امتیاز دهید :
5/5 (2 Reviews)
  خرید سورس های حرفه ای بازی و اپلیکیشن اندروید

  تخفیف ها و اخبار ویژه رو در تلگراممون دنبال کن :)

دسته‌ها: آموزش برنامه نویسی اندروید

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

راهنما : برای نوشتن موارد مختلف در دیدگاه می توانید از راهنمای نگارش اندروید ریور استفاده کنید : نگارش کد کوتاه `your code`
نگارش کد بلند یا نگارش بخش عمده یک سورس کد :
[sourcecode lang="your code language"] your code here [/sourcecode]