لطفا صبر کنید ...

آشنایی با الگوهای طراحی یا دیزاین پترن ها و معرفی انواع آن‌ها

سعید هوشیار

توسط سعید هوشیار

دیدگاه ها: 0
بازدید ها : 68
رایگان
هدف ما این است که شما، در بالاترین سطح طراحی و توسعه وب باشید.

ثبت نام کنید

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


در دنیای برنامه نویسی شئ گرایی، کمتر برنامه نویسی که حرفه‌ای باشد را می‌توان یافت که با چیزی تحت عنوان Design Patterns (دیزاین پترن یا الگوهای طراحی) آشنا نباشد. به صورت خلاصه، منظور از دیزاین پترن راه کارهایی اصولی و در عین حال تست شده است که در پاسخ به چالش‌هایی ایجاد شده‌اند که در توسعه نرم‌ افزار با آن‌ها مواجه خواهیم شد. از یک بعد دیگر، دیزاین پترن‌ها را می‌توان به عنوان یکسری Best Practices نیز در نظر گرفت.

 
در برنامه نویسی یا به طور کلی در هر مهارتی، Best Practices به یکسری اصول و قوانینی گفته می‌شود که توسط جامعه گسترده‌ای از کاربران حرفه‌ای مورد استفاده قرار می‌گیرد و همین مسأله منجر گشته تا به صورت یک قانون کلی نانوشته درآیند که توصیه می‌شود افراد مبتدی نیز از این قوانین تبعیت کنند. برای روشن شدن این مسأله مثالی می‌زنیم. یک Best Practice در نامگذاری کلاس‌ها این است که آن‌ها را به صورت PascalCase بنویسیم. به عبارت دیگر، حرف اول کلیه کلمات در نام کلاس به صورت بزرگ نوشته شود. توجه داشته باشید که اگر از این قانون تبعیت نکنیم هیچ مشکلی به وجود نمی‌آید اما بهتر آن است که نامگذاری‌های ما به این شکل باشند.

 الگوی طراحی یا دیزاین پترن‌ چیست؟

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

انواع الگوهای طراحی (دیزاین پترن‌ها)

مطالعه بیشتر:

 الگوهای طراحی (دیزاین پترن‌ها) بر اساس هدف در۳ دسته طبقه‌بندی می‌شوند:

  1. الگوهای ساختاری (Structural): به طور کلی با روابط بین موجودیت‌ها سروکار دارند، این الگوها کار موجودیت‌ها با یکدیگر را ساده‌تر می‌کنند.
  2. الگوهای ایجادی (Creational): مکانیزم‌های نمونه‌سازی (instantiation mechanisms) ارائه می‌کنند، ساخت آبجکت‌ها را به روشی مناسب ساده‌تر می‌کنند. الگوهای ایجادی به جای اینکه مستقیما از آبجکت‌ها نمونه‌سازی (instantiate) کنید، برای شما آبجکت می‌سازند. اینکار به برنامه شما انعطاف‌پذیری بیشتری در تصمیم‌گیری درباره اینکه کدامیک از آبجکت‌ها باید برای یک مورد خاص ایجاد شود را می‌دهد.
  3. الگوهای رفتاری (Behavioral): در ارتباطات بین موجودیت‌ها استفاده می‌شوند. ارتباط بین موجودیت‌ها را ساده‌تر و انعطاف‌پذیرتر می‌سازد. به طور کلی، برای مدیریت الگوریتم‌ها، روابط و مسئولیت‌ها بین آبجکت‌ها استفاده می‌شود.

 معرفی الگوهای ساختاری

  • Adapter: رابط یک کلاس را به رابط دیگری که مورد انتظار یک مشتری است تبدیل می‌کند. این الگو امکان همکاری بین اشیائی که قبلاً بخاطر داشتن رابط‌های ناسازگار نمی‌توانستند با هم کار کنند را فراهم می‌سازد.
  • Bridge: یک مفهوم مجرد را از پیاده‌سازی‌اش مجزا کرده تا هر دو بتوانند بطور مستقل تغییر کنند.
  • Composite: اشیاء را به صورت ساختار درختی برای ایجاد ساختار سلسله مراتبی به فرم part-whole ترکیب می‌نماید. این الگو اجازه می‌دهد تا مشتری‌ها اشیاء منفرد و مرکب را به صورت یکسانی پردازش کنند.
  • Decorator: در زمان اجرا وظایف جدیدی به یک شئ اضافه می‌کند. این الگو با دارا بودن قابلیت انعطاف برای گسترش عملکرد یک کلاس به وسیله زیر کلاس ساختن از آن مناسب است
  • Facade: یک رابط منفرد برای مجموعه‌ای از رابط‌ها در یک زیر سیستم تدارک می‌بیند. در واقع، یک facade رابط سطح بالاتری برای یک زیر سیستم تعریف کرده و باعث می‌شود تا زیر سیستم را به صورت ساده‌تری مورد استفاده قرار داد.
  • Flyweight: از اشتراک منابع برای فراهم نمودن تعداد زیادی از اشیاء سبک به صورت کارا استفاده می‌کند.
  • Proxy: یک جانشین یا جایگاه برای کنترل دسترسی به یک شئ ایجاد می‌کند.

معرفی الگوهای ایجادی

  •  Abstract factory: رابطی برای ساخت فامیلی‌هایی از اشیاء مرتبط یا وابسته به هم بدون مشخص کردن کلاس‌های واقعی آن‌ها تدارک می‌بیند.
  • Builder: فرآیند ساخت یک شئ را از قسمت نمایش آن جدا کرده تا بتوان همان فرآیند ساخت را برای ایجاد نمایش‌های مختلف به کار برد.
  • (Factory method: یک رابط برای ساخت اشیاء تعریف کرده و در عین حال اجازه می‌دهد تا زیر کلاس‌ها در مورد اینکه چه شئ را نمونه‌سازی کنند تصمیم بگیرند. در واقع، این الگو اجازه می‌دهد تا نمونه‌سازی را به زیر کلاس‌ها محول نمود.
  • Lazy Initialization: شیوۀ تأخیر انداختن برای ساخت یک شي محاسبه یک مقدار یا پردازش‌های سنگین دیگر تا زمان ِ این الگو در فهرست GoF با نام «پروکسی مجازی» نیز شناخته می‌شود. یک استراتژی پیاده‌سازی برای الگوی Proxy به حساب می‌آید.
  • Multiton: این اطمینان را می‌دهد که یک کلاس فقط نمونه‌های (instances) با نام دارد و یک نقطه سراسری (global) برای دسترسی به آن فراهم می‌کند.
  • Object pool: با بازیابی اشیائی که دیگر مورد استفاده قرار نمی‌گیرند از اشغال و آزادسازی‌های سنگین منابع دوری می‌کند.
  • Prototype: با استفاده از یک شئ به عنوان نمونه نوع اشیاء جدیدی که بایستی ساخته شوند را مشخص کرده و آن اشیاء را با ساختن کپی‌های جدید از این نمونه ایجاد می‌نماید.
  • Resource acquisition is initialization: این اطمینان را می‌دهد که منابع به‌ طور مناسب با تعیین طول عمر برای اشیاء آزادسازی می‌شوند.
  • Singleton: این اطمینان را می‌دهد که یک کلاس دارای تنها یک نمونه بوده و دسترسی به آن نمونه را تدارک می‌بیند.
  • Object library: کپسوله کردن مدیریت اشیاء شامل factory interface و لیست‌های مُرده و زنده.

معرفی الگوهای رفتاری

  •  Chain of responsibility: با دادن شانس به بیش از یک شیء برای پاسخگویی به یک درخواست از در هم آمیختن فرستنده و دریافت‌کننده یک درخواست جلوگیری می‌کند. به این ترتیب که اشیاء دریافت‌کننده یک درخواست را به صورت زنجیره‌ای در نظر گرفته و درخواست را در طول این زنجیره عبور داده تا اینکه یکی از اشیاء آن را پاسخ پوید.
  • Command: یک درخواست را به صورت یک شیء کپسوله سازی می‌کند. بنابراین، این امکان را فراهم می‌کند تا مشتری‌ها را با درخواست‌های متفاوت پارامتردهی کرده، درخواست‌ها را صف بندی یا Log کرده و اعمال قابل برگشت ایجاد کنید.
  • Interpreter: برای یک زبان، نمایشی از گرامرش به همراه مفسری که از آن نمایش برای تفسیر جملات مربوط به آن زبان استفاده می‌کند، تعریف می‌نماید.
  • Iterator: روشی برای دسترسی ترتیبی به عناصر یک شیء مجتمع (مرکب) بدون افشاء کردن نمایش آن فراهم می‌کند.
  • Mediator: شئ‌ای که نحوه تبادلات مجموعه‌ای از اشیاء را کپسوله سازی می‌کند را تعریف می‌نماید. این الگو با پرهیز از ارجاعات مستقیم بین مجموعه‌های از اشیاء، اتصال حداقلی بین آن‌ها را ترغیب نموده و اجازه می‌دهد تا تبادلات را به صورت مستقل تغییر دهید.
  • Memento: بدون شکستن کپسوله سازی، حالت درونی یک شیء را تسخیر و ذخیره کرده تا آن شئ بتواند بعداً به آن حالت برگشت یابد.
  • Observer: یک نوع وابستگی یک-به-چند بین اشیاء تعریف کرده به طوری‌ که وقتی یک شیء حالتش را تغییر داد، تمام اشیاء وابسته به آن خبردار شده تا آن‌ها خود را با آن تغییر هماهنگ کنند.
  • State: اجازه می‌دهد تا یک شئ هنگامی که حالتش عوض شد رفتارش را تغییر دهد. اشیاء از این نوع رفتار کلاسی که در آن قرار دارند را تغییر می‌دهند.
  • Strategy: یک خانواده از الگوریتم‌ها را تعریف، کپسوله سازی و قابل جایگزین کردن می‌کند. استراتژی اجازه می‌دهد تا یک الگوریتم را بدون توجه به جائی که مورد استفاده قرار می‌گیرد تغییر داد.
  • Template method: اسکلت یک الگوریتم را تعریف کرده و پیاده‌سازی بعضی قدم‌های آن را به زیر کلاس‌ها محول می‌کند. این الگو امکان تغییر بعضی از قدم‌های یک الگوریتم را بدون تغییر در ساختار کلی الگوریتم به زیر کلاس‌ها می‌دهد.
  • Visitor: عملی که بایستی بر روی عناصر یک ساختار از اشیاء اعمال شود را نمایش می‌دهد. این الگو اجازه می‌دهد تا عمل جدیدی بدون نیاز به تغییر کلاس‌های عناصری که بر روی آن عمل می‌کند را تعریف کنید.

    الگوهای طراحی در برنامه نویسی

مروری بر بعضی از الگوهای طراحی (دیزاین پترن ها)

الگوی Factory

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

چه زمانی از این متد استفاده کنیم؟

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

مثال:

class MySQLDB
{
    public function setHost($host)
    {
        // code
    }
    public function setDB($db)
    {
        // code
    }
    public function setUserName($user)
    {
        // code
    }
    public function setPassword($pwd)
    {
        // code
    }
    public function connect()
    {
        // code
    }
}

class PostgreSQLDB
{
    public function setHost($host)
    {
        // code
    }
    public function setDB($db)
    {
        // code
    }
    public function setUserName($user)
    {
        // code
    }
    public function setPassword($pwd)
    {
        // code
    }
    public function connect()
    {
        // code
    }
}

if (Config::item('db_type') === 'mysql') {
    $DB = new MySQLDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}
elseif (Config::item('db_type') === 'postgre') {
    $DB = new PostgreSQLDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}
elseif (Config::item('db_type') === 'sqlite') {
    $DB = new SQLiteDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}

در نهایت، با ساخت یک آبجکت به راحتی از آن استفاده کنید. به مثال بالا دقت کنید، بزرگ‌ترین مشکل کد بالا این است که اگر بخواهیم پروژه را بزرگتر و نوع دیتابیس‌ها را افزایش دهیم، پیچیده‌تر می‌شود، پس دستورات شرطی کد بالا را حذف کنید و کلاس Factory را اضافه کنید:

class DBFactory
{
    protected $driver = null;

    public function setDriver($driver)
    {
        $this->driver = $driver;
    }

    public function makeDB($host, $user, $pass, $dbname)
    {
        if ($this->driver === 'mysql') {
            $DB = new MySQLDB();
        }
        elseif ($this->driver === 'postgre') {
            $DB = new PostgreSQLDB();
        }
        elseif ($this->driver === 'sqlite') {
            $DB = new SQLiteDB();
        }

        $DB->setHost($host);
        $DB->setDB($dbname);
        $DB->setUserName($user);
        $DB->setPassword($pass);
        $DB->connect();

        return $DB;
    }
}

الگوی Abstract Factory

الگوی Abstract Factory مانند الگوی Factory است ولی از یک کلاس Abstract ارث‌بری می‌کنند.

الگوی Facade

الگوی Facade یک رابط مشترک برای آبجکت‌های مختلف ایجاد می‌کند. در این الگو، کلاس‌های مورد نظر خود را می‌نویسید تا از طریق یک کلاس که نقش واسطه را دارد، با این کلاس‌ها کار کند. اسم این کلاس را Facade (هر اسمی دوست دارید) می‌گذاریم، فرض کنید کلاسی داریم که از سایر کلاس‌های مورد نیاز خود آبجکت می‌سازد، با یک متد داده‌ها را گرفته و با یک حلقه foreach پردازش می‌کند. در نهایت، با کمک کلاس‌های دیگر دستورات و اعمال مورد نظرش را روی آن‌ها انجام می‌دهد. هنگام استفاده نیز ابتدا از کلاس Facade یک آبجکت می‌سازیم، سپس کارها را از طریق آبجکت مورد نظرمان انجام می‌دهیم.

نکته

برای اینکه نتوان از یک کلاس آبجکت ایجاد کرد، خصوصا برای استاتیک، راه اول private کردن متد سازنده است و راه دوم ایجاد خطا در متد سازنده (throw new Exception(‘Error message’)) است، در هنگام استفاده نیز از بلاک try catch استفاده می‌کنیم که حرفه‌ای‌تر از حالت اول است.

الگوی Decorator

الگو decorator یک مشکل دیگر برنامه‌ نویسان را حل کرده است. وقتی نتوانیم به هر دلیلی یک کد را ویرایش کنیم، مثلا کلاسی داریم که بنا به هر دلیلی (مانند کپی‌ رایت، فاینال بودن یا غیره) نمی‌توانیم آن را بازنویسی کنیم، اگر بخواهیم متدی به آن کلاس اضافه کنیم، از این الگو استفاده می‌کنیم. نحوه پیاده‌سازی بدین صورت است که ابتدا یک کلاس ساخته و در این کلاس یک فیلد خصوصی تعریف می‌کنیم، آبجکت (این آبجکت از کلاس مورد نظر ما مشتق شده است) را به عنوان پارامتر متد سازنده کلاس در نظر می‌گیریم و در فیلد فوق قرار می‌دهیم. حالا متدی هم‌ نام با نام متد کلاس مورد نظرمان می‌سازیم و عملیات مورد نظر را انجام می‌دهیم (اغلب تغییرات روی داده‌ها است) و در صورت نیاز مقادیری را برمی‌گردانیم که البته در این متد می‌توانیم متدهای دیگری را نیز برای اعمال تغییرات یا اجرای دستورات فراخوانی کنیم. به این تکنیک مضروب‌سازی (Containment) می‌گویند که شما یک آبجکت از یک کلاس دیگر می‌سازید و از خصوصیات public آن استفاده می‌کنید و یه سری خصوصیات دیگر نیز اضافه می‌کنید و این در جاهایی که خصوصا وراثت امکان‌پذیر نیست، خیلی مفید است، به خصوص در غلبه کردن بر این محدودیت که یک آبجکت نمی‌تواند همزمان بیش از یک کلاس والد داشته باشد.

الگوی Observer

الگوی Observer نیز مشکل دیگری را حل می‌کند، فرض کنید می‌خواهید برخی از آبجکت‌ها تغییرات آبجکت‌های دیگر را دنبال کنند، یعنی اگر تغییراتی در یک آبجکت دیگر داده شود، متوجه شوند و کار دیگری را انجام دهند. این الگو از دو نوع آبجکت تشکیل شده است Observable و Observer که یکی Event تولید می‌کند و یکی به Eventها پاسخ می‌دهد. هر گاه وضعیت آبجکت observable تغییر کند، تمام آبجکت‌های observer ثبت شده در آبجکت خود را فراخوانی می‌کند و می‌گوید وضعیت من تغییر کرده است. یکی از کاربردها گزارش‌گیری است که خطاها را اعلام می‌کند. باید برای استفاده از آن رابطی با نام observer را پیاده‌سازی کنیم که حاوی متد notify است. مثال استفاده از این الگو به صورت زیر است:

interface observer 
{
    public function notify();
}

class YMNotifier implements observer 
{
    public function notify () 
    { 
        // send alerts using YM echo 'Notifying via YM
' . PHP_EOL;
    }
} 

class EmailNotifier implements observer 
{ 
    public function notify() 
    { 
        // send alerts using Email echo 'Notifying via Email
' . PHP_EOL;
    }
}

class SmsNotifier implements observer 
{
    public function notify()
    { 
        // send alerts using SMS echo 'Notifying via SMS
' . PHP_EOL;
    }
}

class Test 
{ 
    private $observers = [];

    public function register($object)
    { 
        if($object instanceof observer)
        {
            $this->observers[] = $object;
        }
        else
        { 
            echo 'The object must implement observer interface.
' . PHP_EOL;
        }
    }

    public function StateChange()
    { 
        foreach($this->observers as $observer) 
        {
            $observer->notify();
        }
    }
} 

class Notifier { }

$test = new Test(); 
$ym = new YMNotifier();
$em = new EmailNotifier();
$sm = new SmsNotifier(); 
$n = new Notifier();

$test->register($ym);
$test->register($em);
$test->register($sm);
$test->register($n);
$test->StateChange();

الگوی Singleton

تمامی کلاس‌های سینگلتون باید حداقل سه عنصر زیر را داشته باشند:

  • یک متد سازنده با سطح دسترسی private
  • یک پراپرتی استاتیک که نمونه‌ای از کلاس (آبجکت) را نگه دارد.
  • یک متد استاتیک با سطح دسترسی public برای دسترسی به آبجکت

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

// The Database class represents our global DB connection
class Database extends PDO {
	// A static variable to hold our single instance
	private static $_instance = null;

	// Make the constructor private to ensure singleton
	private function __construct()
	{
		// Call the PDO constructor
		parent::__construct(APP_DB_DSN, APP_DB_USER, APP_DB_PASSWORD);
	}

	// A method to get our singleton instance
	public static function getInstance()
	{
		if (!(self::$_instance instanceof Database))
		{
			self::$_instance = new Database();
		}
		return self::$_instance;
	}
}

 یک مثال برای استفاده از این الگو، اتصال‌ها به دیتابیس و تنظیمات و اطلاعات فایل‌های config است. الگوی Singleton یکی از پرکاربردترین الگوها است و مشکلات زیادی را حل کرده است، هدف اصلی آن این است که در هر لحظه بیش از یک آبجکت از یک کلاس وجود نداشته باشد. برای پیاده‌سازی این روش، یک فیلد استاتیک خصوصی مثلا $instance می‌سازیم و داخل متد سازنده آبجکت، یک شرط قرار می‌دهیم که اگر if(self::$instance) آنگاه self::$instance = $this و در بیرون شرط نیز همین مقدار return self::$instance را برمی‌گردانیم. حالا حتی اگر یک میلیون آبجکت هم بسازیم، فقط یک نسخه وجود دارد و فقط همان آبجکت در حافظه قرار می‌گیرد، پس تا جایی که می‌شود باید از این الگو استفاده کنیم تا مصرف حافظه به شدت کاهش یابد.

الگوی Iterator

الگوی Iterator کمک می‌کند تا مجموعه‌ای از داده‌ها را راحت‌تر مدیریت کنید. رابط Iterator دارای ۵ متد می‌باشد، rewind ایندکس آرایه را به اولین خانه برمی‌گرداند، currentعنصر جاری را برمی‌گرداند، key کلید (اندیس) عنصر جاری را برمی‌گرداند، next اشاره‌گر (اندیس) را یک واحد به جلو می‌برد، valid می‌گوید که آیا عنصری (اندیسی) که اشاره‌گر به آن اشاره دارد، وجود داره یا نه. برای مثال، می‌توانیم پست‌های یک مطلب را به کلاسی بدهیم که از این رابط ارث‌ بری کرده است و این کلاس پست‌ها را پردازش می‌کند، به صورت زیر:

Class Post implements Iterator
{
    private $posts = array();

    public function __construct($posts)
    {
        if(in_array($posts))
        {
            $this->posts = $posts;
        } 
    }

    public function rewind() 
    {
        reset($this->posts); 
    }

    public function current() 
    {
        return current($this->posts); 
    }

    public function key()
    {
        return key($this->posts); 
    } 

    public function next()
    {
        return next($this->posts); 
    }

    public function valid () { 
        return($this->current() !== false); 
    }
}

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

$blogposts = GetAllPosts(); 
$posts = new Posts($posts);

foreach($posts as $post) 
{
    echo $psot->GetTitle();
    echo $psot->GetAuthor();
    echo $psot->GetContet(); 

    $comments = new Comments($post->GetComments);

    foreach($comments as $comment) 
    {
        echo $comment->GetAuthor();
        echo $comment->GetContent(); 
    }
}

اگر بخواهیم از foreach بتوانیم استفاده کنیم، باید رابط Iterator را پیاده‌سازی کرده باشیم. البته در آرایه‌های php این رابط به صورت پیش‌فرض پیاده‌سازی شده است اما می‌توانیم ساختارش را تغییر بدهیم.

الگوی Strategy

در الگوی Strategy یک رابط می‌نویسیم و برای هر حالت مثلا ارسال sms و mail و fax یک کلاس به ازای هر کدام قرار می‌دهیم که همه یک متد هم نام برای اجرای دستور دارند و انتخاب استفاده از کدام کلاس تعیین کننده ادامه داستان است.  

الگوی Active Record

الگوی ActiveRecord یک الگوی فوق‌العاده کاربردی است. رکوردهای داخل دیتابیس به شکل آبجکت در می‌آیند، یعنی هر آبجکت ActiveRecord با یک رکورد در دیتابیس متناظر است. هدف اصلی این الگو این است که بتوانیم با روشی مانند $post->field به پراپرتی برای ساخت یا تغییر دسترسی داشته باشیم که با مقداردهی یک پراپرتی، یک رکورد متناظر در جدول ایجاد می‌شود و با خواندن یک پراپرتی نیز رکورد متناظر برمی‌گردد، البته ساخت با متدی مانند save انجام می‌شود ولی مقداردهی از روش گفته شده انجام می‌شود و روش پیاده‌سازی بدین صورت است که به نام هر تیبل (مفرد آن مثلا برای تیبل posts نام کلاس را post قرار می‌دهیم)، یک کلاس می‌سازیم، در این کلاس یک فیلد خصوصی قرار می‌دهیم و در متد سازنده نام ستون‌ها را به عنوان اندیس‌های این فیلد مقداردهی اولیه می‌نماییم، سپس با __GET و __SET مقداردهی و مقدارگیری را انجام می‌دهیم، حالا متدهای مورد نظرمان را به صورت استاتیک می‌نویسیم، مثلا متد findByPk($id) یک رکورد خاص از جدول را با استفاده از id آن برمی‌گرداند که این کار را به این صورت انجام می‌دهد که هر ستون رکورد را در یک اندیس پراپرتی کلاس قرار می‌دهیم و سپس می‌توانیم آن را فراخوانی کنیم.

الگوی Adaptor

الگوی Adapter یک آبجکت را به متدهای یک آبجکت دیگر تبدیل می‌کند. وقتی از api یک سرویس استفاده می‌کنیم و سپس به هر دلیلی مجبوریم از یک سرویس‌دهنده دیگر استفاده کنیم. فرض کنیم از سرویس Writely استفاده می‌کردیم و بعد از خرید آن توسط گوگل، مجبور خواهیم بود تا از گوگل‌داک استفاده کنیم، حالا اگر رابطی داریم که کلاس Writely از آن استفاده می‌کند، حالا باید از کلاس گوگل داک استفاده کنیم، برای استفاده از این کلاس نیز نیاز به یک کلاس از نوع Adapter داریم که این کلا

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

مطالعه بیشتر در لیداوب:

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

5 از 3 رای

 مطالب مرتبط  

در قسمت زیر مطالبی وجود دارند که با مقاله فعلی مرتبط هستند



متاسفانه فقط اعضای سایت قادر به ثبت دیدگاه هستند

برترین مطالب

آموزش در لیداوب

از مقالات و ویدیو های آموزشی خودتان کسب درآمد کنید!

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