برچسب: دیزاین پترن php

  • دیزاین پترن singleton در PHP

    در ادامه بحث هامون در مورد دیزاین پترن ها امروز میخوام بصورت خلاصه در مورد singleton design pattern بنویسم که فکر میکنم به درد خیلی هاتون بخوره و خیلی از پیچیدگی کد نویسی رو براتون کمتر کنه. بصورت خلاصه و مفید اگه بخوام بگم این دیزاین پترن همونطور که از اسمش پیداست از تکرار جلوگیری میکنه و جاهایی استفاده میشه که بخوایم یه کد تکراری رو فقط یکبار بنویسیم. پس سینگلتون جاهایی به کارمون میاد که ما به یه نمونه از شی بصورت گلوبال میخوایم دسترسی داشته باشیم. مثلا شما ممکنه مجبور باشید توی یک سیستم بارها به دیتابیس وصل بشید. یا ممکنه بخواید از api یه سایت دیگه هر چند بار پشت سر هم استفاده کنید یا هر چیز دیگه ای که خودتون صلاح میدونید… با مثال توضیح میدم که ایده ی این الگو چطور هست. در زیر یه پیاده سازی پایه از این الگو رو میبینیم :

    class Database
    {
        public static function Instance()
        {
            static $inst = null;
            if ($instnce === null) {
                $instnce = new Database();
            }
            return $instnce;
        }
    
        public function getUsers()
        {
            return 'users...';
        }
        
        public function getPosts()
        {
            return 'posts...';
        }
    }
    
    $users = Database::Instance()->getUsers();
    $posts = Database::Instance()->getPosts();

    همونطور که میبینید Instance  به صورت متد استاتیک تعریف شده و بصورت استاتیک بهش دسترسی پیدا میکنیم.

  • دیزاین پترن Simple Factory در PHP

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

    Design patternها یا فارسیش میشه احتمالا الگوهای طراحی نرم افزار توی همه زبان ها خیلی خیلی مهمن. معمولا وقتی کدی مینویسیم که قرار نیست در آینده گسترش داده بشه خیالمون راحته و از یجای کار شروع میکنیم و یجا تموم میکنیم و کار رو تحویل میدیم، ولی وقتی کارفرما میگه که “در آینده قراره امکانات زیادی از قبیل فلان۱ و فلان۲ و… به سیستم اضافه بشه”، اونجا باید یه فکر پایه ای تر برای سیستم داشته باشیم. طوری که اگه قرار شد یه بخش جدید رو به سیستم اضافه کنیم مجبور نباشیم تو بخشای قبلی دست اندازی کنیم یا حداقل کم مجبور باشیم(!).

    فرض کنید که میخواید یه فروشگاه بنویسید که ادمین روزی چند تا محصول از نوع اسباب بازی به سیستم اضافه میکنه. ابتدایی ترین روشی که به فکر همه ما میرسه اینه که یه کلاس ایجاد کنیم تحت نام Product  و توی اون درج، اصلاح، حذف و … محصول که فعلا اسباب بازی هست رو انجام بدیم. یه چیزی شبیه این :

    <?php
    class Product {
        public function __construct($name) {}
    
        public function save() {}
    }
    $product = new Product('first toy');
    $product->save();

    تا اینجا همه چی خوبه و شما در آرامش قبل از طوفان به سر میبرید! مشکل زمانی پیش میاد که مجبور بشید مثلا بجز اسباب بازی ، کتاب هم در فروشگاهتون بفروشید. اینجا دیگه روش ایجاد و اصلاح و … فرق میکنه و نمیتونید همین متد های قبل رو استفاده کنید. توی دیزاین پترن بالا شما مجبورید یه $type  زمان نمونه گیری از کلاس بگیرید و توی هر متد if و else بذارید و بگید اگه این دسته بود این کارو بکن و اگه… که قطعا روش خوبی نیست و مثلا وقتی چنتا دسته دیگه بعدها اضافه بشه کدمون خیلی داغون میشه.

    نحوه ی پیاده سازی دیزاین پترن Simple Factory در PHP

    سیمپل فکتوری دیزاین پترن میگه که شما این کارو بکنید :

    اول یه کلاس factory بسازید :

    class ProductFactory {
      public function __construct(){ }
    
      public static function create($type){
         if ($type == '')
            throw new Exception('invalid product type');
         else {
            $className = 'product_' . ucfirst($type);
            if (class_exists($className))
               return new $className;
            else
               throw new Exception('Product type not found');
         }
      }
    }
    

    حالا واسه ساخت اسباب بازی از روش خیلی ساده زیر استفاده کنید :  

    class product_Toy
    {
      public function __construct(){
         echo "toy is creating";
      }
    }
    $toy = ProductFactory::create('toy');
    

    حالا اگه یه دسته جدید مثل کتاب به محصولاتون اضافه شه خیلی راحت میتونید کلاسش رو بسازید محصولتون رو اضافه کنید :

    class product_Book
    {
      public function __construct(){
         echo "book is creating";
      }
    }
    $book = ProductFactory::create('book');
    

    در مجموع simple factory method خیلی ایده ی سختی نداره. میگه وقتی داری از یه کلاس نمونه میگیری که خودش میتونه انواع مختلفی داشته باشه یدونه فکتوری واسش درست کن و از فکتوری نمونه بگیر که هر بار مجبور نشی هزار تا جایی که ازش نمونه گرفتی رو تغییر بدی. بعد برو توی فکتوری و چک کن که با توجه به کانفیگت کدوم کلاس رو نمونه بگیری.

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

    امیدوارم کمکتون کرده باشم و خوشحال میشم نظراتتون رو بشنوم 🙂

  • مفهوم و کاربرد اینترفیس – interface در PHP

    قبلا در مورد کلاسهای abstract در PHP مطلبی نوشتم ، کلاسهای انتزاعی یا abstract کلاسهایی هستند که قابل نمونه گیری نیستند و میتونیم درون کلاسهای انتزاعی متد هایی بنویسیم و در کلاسهایی که از اون مشتق شدن ازش استفاده کنیم. اینترفیس ها دقیقا مثل کلاسهای انتزاعی هستند ، با این تفاوت که در اینترفیس ها هیچ متدی نمیتونه دارای بدنه باشه. اولش خیلی عجیب به نظر میرسه… وقتی متدها بدنه نداشته باشن ، به چه دردی میخودن؟

    به خاطر داشته باشید که شما با تعریف یک متد در کلاس abstract نویسنده کلاسهای دیگه (که از این کلاس مشتق شدن) رو وادار نمیکردید که متدهای کلاس پدر رو بازنویسی کنه. ولی در اینترفیس ها اینطور هست، یعنی هر کلاسی که یک اینرفیس رو implement کنه ، باید تمام متدهای کلاس پدر رو بازنویسی کنه.

    مثلا شما میخواید کلاسی بسازید که یک تگ html رو رندر کنه و برای این کار نیاز هست که به تگ ، id و class داده بشه. شما میاید یه اینترفیس میسازید و درون اون دو تابع setID  و setClass  رو مینویسید. از اون به بعد هر کسی که کلاس خودش رو از اینترفیس شما مشتق کرد مجبوره که دو تا تابع رو بنویسه و این از خطای برنامه جلوگیری میکنه. شاید در پروژه های کوچیک زیاد به درد نخوره ، ولی پروژه هایی که تعداد زیادی توسعه دهنده روشون کار میکنند ، برای پیاده سازی design pattern ها در اکثر اوقات باید از اینترفیس ها استفاده کنن.

    نحوه ی تعریف interface ها در PHP

    برای تعریف اینترفیس ها از کلمه کلیدی interface استفاده میکنیم :

    interface abc
    {
        public function xyz($b);
    }

    در مثال بالا کلاسها رو مجبور میکنیم که متد xyz رو بنویسن. برای ارث بردن یا به اصطلاح پیاده کردن یک اینترفیس از کلمه کلیدی implements استفاده میکنیم:

    class test implements abc
    {
       public function xyz($b)
       {
           // The body of your function...
       }
    }

    نکته قابل توجه اینه که تمام متد ها و پراپرتی هایی که درون یک اینترفیس تعریف میشن باید بصورت عمومی یا public  تعریف بشن ، در غیر اینصورت با اررور مواجه میشیم.

    یک نکته دیگه اینکه یک کلاس میتونه بیش از یک اینترفیس رو implement کنه و همچنین یک اینترفیس میتونه از چند اینترفیس دیگه مشتق بشه.

    نوشتن کدهای Open-Closed با استفاده از اینترفیس ها

    ما در مفاهیم SOLID همیشه تشویق میشیم که کدهامون رو open-closed بنویسیم. ینی کدهامون برای تغییر بسته باشن و جوری کد بزنیم که کلاسها رو هی نیایم دستکاری کنیم همینطور باید کد رو جوری بنویسیم که به راحتی extendable باشه. دلیل این هم شاید برمیگرده به اینکه ریفکتور کردن کدهای اینجوری سخته و باعث بروز مشکلات میشه. من در ادامه یه مثال میارم و روی اون توضیح میدم:

    <?php
    
    interface DriverContract
    {
        public function connect();
        public function run();
        public function get();
    }
    
    
    class MySQL implements DriverContract
    {
        public function connect()
        {
            echo "Connecting to MySQL...\n";
        }
        public function run()
        {
            echo "Running MySQL...\n";
        }
        public function get()
        {
            echo "Getting MySQL...\n";
        }
    }
    
    class MongoDB implements DriverContract
    {
        public function connect()
        {
            echo "Connecting to MongoDB...\n";
        }
        public function run()
        {
            echo "Running MongoDB...\n";
        }
        public function get()
        {
            echo "Getting MongoDB...\n";
        }
    }
    
    
    function consume(DriverContract $driver)
    {
        $driver->connect();
        $driver->run();
        $driver->get();
    }
    
    consume(new MySQL());
    

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

    کدهای Testable با کمک interface ها

    اگه با مفاهیم تست نویسی و بخصوص mocking آشنا نیستید شاید این بخش یه خورده گنگ باشه واستون. ولی به هر حال در کد بالا میتونستیم بجای inject کردن اینترفیس مستقیما یک کلاس رو اینجکت کنیم و در ظاهر خیلی اتفاق بدی نمیفتاد. ولی مشکل اصلی زمانی پیش میاد که شما میخواید بدون تغییر در کد یا گرفتن ورودی اضافه کدتون رو تست کنید. اونجا برای تست تابع consume باید حتما ورودی رو از نوع مثلا MySQL میدادید که در این صورت نمیشد یه کلاس فیک برای تست نوشت ولی الان خیلی راحت میتونیم هر نمونه ای که اینترفیس رو پیاده کرده رو به عنوان ورودی به تابع بدیم و اون رو تست کنیم.

    در پایان من فرصت نکردم متن رو ریویو کنم اگه مشکلی بود ببخشید و توی کامنت ها بگید که اصلاح کنم 🙂