https://virgool.ir/feed/@aghaie.zahrafa2026-11-12 16:38:10https://files.virgool.ir/upload/users/557478/avatar/avatar.pnghttps://virgool.ir/@aghaie.zahrahttps://virgool.ir/@aghaie.zahra/قسمت-دوم-strategy-pattern-ctnhkmr8jedrطراحی رفتارهای اردکو اما چگونه مجموعه رفتارهای fly و quack را پیاده سازی کنیم ؟از اینجا به بعد رفتارهای Duck در کلاس های جداگانه زندگی می کنند. کلاس هایی که یک Interface مشخصی را پیاده سازی می کنند. با این روش ، هر کدام از اردک ها نیازی نیست در مورد پیاده سازی جزییات رفتارهای خودشان بدانند.پیاده سازی آن به صورت زیر خواهد بود :طراحی بر اساس Polymorphism از اصول شی گرایی با استفاده از Interfaceدر طراحی جدید ، زیر مجموعه های کلاس Duck از Interface مربوط به FlyBehavior یا QuackBehavior استفاده می کنند و جزییات پیاده سازی هر کدام از رفتارها در کلاس های زیر مجموعه مربوط به Interface ها پیاده سازی می شود . در اینجا محدود به پیاده سازی رفتارها در کلاس های زیرمجموعه Duck (انواع اردک ها) نیستیم. مثال زیر را با طراحی بالا مطابقت می دهیم : یک SuperClass مربوط به Animal داریم و زیر مجموعه آن کلاس های Dog و Cat هستند.کد نویسی با استفاده از کلاس های زیر مجموعه به صورت زیر خواهد بود :Dog d=new Dog();d.makeSound();اما کد نویسی با استفاده از SuperType / Interface به صورت زیر خواهد بود :Animal animal=new Dog();animal.makeSound();در تعریف بالا ، کلاس Dog راداریم که از حالت Polymorphism مربوط به کلاس Animal استفاده می کند و مزیتی که ایجاد می کند، می توانیم هنگام RunTime هر کدام از زیرمجموعه هارا به کلاس Animal انتصاب دهیم.اصل طراحی : برروی Interface کد بزنید نه زیرمجموعه ها.و اما از مثال بالا ، می توان طراحی رفتارهای اردک را هم متوجه شد. طراحی دو رفتار اردک به صورت زیر خواهد بود :پیاده سازی دو رفتار Quack و Flyبا طراحی فوق ، انواع اردک ها می توانند این دو رفتار را reuse کنند و می توانیم رفتارهای جدیدی را به این طراحی اضافه کنیم بدون اینکه نیاز به تغییر در کلاس های موجود بالا یا کلاس هایی که هم اکنون از این رفتارها استفاده می کنند ، باشد. بنابراین مافواید Reuse را به دست آورده ایم بدون اینکه بار اضافه Inheritance را متحمل شویم.پیاده سازی کلاس Duckدیاگرام کلاس به صورت زیر می باشد :نمای کلی کلاس Duckپیاده سازی کد کلاس بالا به صورت زیر می باشد :public abstract class Duck(){FlyBehavior flyBehavior;QuackBehavior quackBehavior;public abstract void display();public void performFly() { flyBehavior.fly(); }public void performQuack() { QuackBehavior.quack(); }public void swim () { System.out.println("All Ducks Float, even Decoys!"); }و شبه کدهای مربوط به Fly به صورت زیر می باشد :public interface FlyBehavior(){ public void fly(); }public class FlyWithWings implements FlyBehavior { public void fly() { print("I m flying..."); } }public class FlyNoWay implements FlyBehavior { public void fly() { print("I can t fly"); } } و شبه کدهای پیاده سازی زیرمجموعه های Quack هم همانند کدهای Fly می باشد .و شبه کد یکی از کلاس هایی که از Duck ارث بری می کنند به صورت زیر می باشد :public class MallardDuck extends Duck {public MallardDuck () {quackBehavior=new Quack();flyBehavior=new FlyWithWings(); }public void display() { print("I m a real Mallard Duck"); } }و نحوه تست کدهای بالا به صورت زیر می باشد :Duck mallard=new MallardDuck(); mallard.performQuack(); mallard.performFly();با اجرای کد بالا ، پیغام هایی که در متدهای Quack و FlyWithWings وجود داشت، چاپ خواهد شد.افزودن رفتارها به صورت پویا مرحله اول : افزودن دو متد جدید به کلاس پایه Duck به صورت زیر :public void setFlyBehavior(FlyBehavior fb) { flyBehavior=fb; }public void setQuackBehavior(QuackBehavior qb) { quackBehavior=qb; }هر موقع می خواهیم در حین اجرا رفتارها را به اردک ها اضافه کنیم ، از این متدها استفاده می کنیم. و تست آن به صورت زیر می باشد :Duck model=new MallardDuck(); model.setFlyBehavior(new FlyNoWay ()); model.performFly();با افزودن رفتار پرواز هنگام اجرا ، توسط شبه کد بالا پیغام I can t fly چاپ می گردد.ساختار کلی کلاس های استفاده شده در این مثال به صورت زیر نمایش داده می شود :دیاگرام کلی مثال اردک با استفاده از پترن استراتژیتوجه : نمادهایی که در بالا استفاده شده است ، با استفاده از نمادهای uml می باشد. در مثال بالا ، کلاس اردک از رابطه HAS-A استفاده کرده است. هر اردک یک FlyBehavior و یک QuackBehavior دارد. این تکنیک مهم Composition نام دارد. و در واقع ما از یک اصل طراحی استفاده می کنیم:اصل طراحی : از Composition بیشتر کمک بگیرید تا Inheritance .همانطور که مشاهده نمودید ،در ایجاد سیستم ها استفاده از Composition به شما انعظاف پذیری بیشتری می دهد. نه تنها اجازه میدهد مجموعه ای از الگوریتم ها را در یک سری از کلاس ها Encapsulate نمایید بلکه می توانید رفتارها را در زمان اجرا تغییر دهید.در پترن استراتژی مجموعه ای از الگوریتم هارا داریم که هرکدام از آنهارا Encapsulate می نماید و قابلیت تغییر به آنها میدهد بدون اینکه نیاز باشد قسمت های دیگر تغییر یابد. استراتژی به الگوریتم ها اجازه میدهد به صورت مستقل از Client هایی که آنهارا استفاده می کنند ، تغییر یابد.توجه کنید که فقط دانستن مفاهیم abstraction ، inheritance ، polymorphism و encapsulation (مبانی طراحی شی گرا) از شما یک طراح خوب نمی سازد .بلکه یک طراح خوب می داند که چگونه یک طراحی انعطاف پذیر را ایجاد کند که هم قابلیت نگهداری داشته باشد و هم با تغییرات سازگار باشد.سوال : اگر نتوانستم برای مسایل نرم افزاری خود یکی از پترن ها را پیدا کنم چه کار کنم؟جواب : یک سری اصول شی گرایی وجود دارد که زمینه ساز تشکیل پترن ها هستند و دانستن آنها به شما کمک می کند مسئله خود را حل کنید وقتی که نمی توانید پترن متناظر با مسئله خود را حل کنید.اصول طراحی مطرح شده را با هم مرور می کنیم :هرآنچه که تغییر می کند را Encapsulate نمایید.بیشتر از composition بهره بگیرید تا inheritance.برروی Interface کد بزنید نه زیرمجموعه ها.تا اینجا چند ابزار به جعبه ابزار اصول طراحی ما افزوده شد .قسمت اول از پترن استراتژی را می توانید در لینک زیر دنبال نمایید :https://vrgl.ir/yrHb5zahra aghaeizahra aghaeiSun, 21 Feb 2021 11:31:47 +0330https://virgool.ir/CodeLovers/داستان-های-design-patterns-jffy2crjxoxe(خلاصه کتاب Head First Design Patterns - o Reilly)داستان اول- بخش اول - قصه Strategy Pattern توضیحات : در این سری از مقاله ها قصد دارم دلیل پیدایش هر کدام از Pattern ها را با مثال و به صورت داستان بیان کنم و چالش هایی که در رسیدن به یک الگو با آن دست و پنجه نرم می کنیم تا به یک Pattern برسیم را بررسی می کنیم . امیدوارم این مجموعه راهنمای خوبی را برای تفکر در مورد طراحی های شی گرا پیش روی ما قرار دهد. کدهایی که به صورت نمونه قرار می گیرد ، فارغ از نوع زبان برنامه نویسی می باشد و فرض براین است که اصول طراحی شی گرا را درک کرده ایم.به دنیای پترن ها خوش آمدید.(یک کسی قبلا مشکل شما را حل کرده است)با یک اپ ساده بازی شبیه سازی اردک ها شروع می کنیم : جویی قصه ما برای یک شرکت موفق بازی شبیه ساز اردک ها کار می کند.بازی می تواند گونه های مختلف اردک ها رانمایش بدهد که شنا می کنند و آوای صدای کوئک را تولید می کنند. طراحی اولیه سیستم از تکنیک های استاندارد شی گرا استفاده می کرد به این صورت که یک Super class مربوط به duck وجود داشت که تمامی گونه های اردک از آن ارث بری می کردند.و مابقی اردک ها از Duck ارث بری می کنند.و اما الان می خواهیم اردک ها پرواز کنند ........جویی با خودش فکرکرد که فقط کافی است متد fly را به کلاس duck اضافه کند تا همه اردک ها بتوانند پرواز کنند. در جلسه دمویی که در شرکت داشتند مشاهده نمودند که حتی اردک های پلاستیکی هم می توانند پرواز کنند که این رویه منجربه شکست در مقایسه با رقبا میشد. برخی اردک ها از جمله اردک پلاستیکی برخی رفتارهارا مانند fly و یا quack را نیازندارند که ارث بری کنند.جویی فکر کرد یکی از مهم تریم ویژگی های ارث بری Reuse بودن یا قابلیت استفاده مجدد آن است که این موضوع نگهداری سیستم را آسان تر می کند. جویی در مورد Inheritance تفکر کرد....هر کدام از اردک ها آوای صدایی خود را تولید می کنند و رفتارهای پرواز کردن آنها باهم متفاوت است. قرار است به لیست اردک موجود در بازی ، اردک چوبی هم اضافه شود که نه آوایی تولید می کند و نه پرواز می کند پس در متدهای fly و quack مربوط به آن هیچ پیاده سازی وجود ندارد . معایب زیر برای ادامه با طراحی بالا وجود دارد :برای هر کدام از Sub Class ها لزوم پیاده سازی این دو رفتار(quack وfly) اجبار می شود.ما دقیقا رفتار تمامی اردک ها را از ابتدا نمی دانیم.بنابراین ، این روش پاسخگوی نیاز ما نخواهد بود. راهکار دومی که جویی در مورد آن فکر کرد ، پیاده سازی رفتارها توسط Interface است که طراحی آن به صورت زیر می باشد :در طراحی بالا ، دورفتار quack و Fly از کلاس Duck بیرون کشیده شده است و در دو Interface قرار گرفته است تا هر کدام از رفتارها را فقط برای کلاس هایی که لازم داریم پیاده سازی نماییم . همان گونه که در تصویر مشخص است ، DecoyDuck یا اردک چوبی هیچ کدام از رفتارهار را پیاده سازی نکرده است. اشکالی که در این نوع طراحی می توان گرفت به این صورت است که اگر بخواهیم تغییری در رفتارها اعمال کنیم و بخواهیم آن تغییر در تمامی اردک ها اعمال شود ، بایستی آن را در همه اردک ها تکرار کنیم که قانون قابلیت استفاده مجدد یا Reuse را نقض می کند و کابوس نگهداری سیستم را خواهیم داشت.در سناریوی بالا ، بازهم مدیرجویی که کمی هم اصول شی گرایی را می دانست ، به وی اعتراض کرد که اگر بخواهیم تکه کدی را به متد Fly اضافه کنیم آیا بایستی تمامی زیرمجموعه ها آن تکه کد اضافه شود(تمامی زبان ها امکان پیاده سازی کد در Interface را ندارند.) ؟ پس همان طراحی قبلی با Duplicate Code بهتربود.اگر شما به جای جویی بودین چه کار می کردین ؟یک اصل ثابت در توسعه نرم افزارآیا چیزی در توسعه نرم افزار هست که شما همیشه بتوانید روی آن حساب باز کنید؟جدای از اینکه شما کجا کار می کنید ، در حال ساختن چه نرم افزاری هستید یا شما با چه زبانی در حال برنامه نویسی هستید . چه اصل ثابتی برای همیشه با شما همراه خواهد بود؟تغییرجدای از اینکه شما چقدر خوب نرم افزار خودرا طراحی کرده اید ، در طول زمان و به مرور نرم افزار بایستی رشد کند و دراین حین یا تغییرات انجام می شود یا نرم افزار طراحی شده ، محکوم به فنا خواهد بود.اولین اصل طراحیجنبه هایی از نرم افزار خود را که تغییر می کنند را تشحیص دهید و آنها را از قسمت هایی که ثابت باقی می مانند ، مجزا کنید.ما می دانیم که متدهای fly و duck قسمت هایی از کلاس duck هستند که درحال تغییر می باشند، بنابراین این رفتارهارا از کلاس duck بیرون می کشیم و هر کدام از آنهارا به عنوان یک کلاس در نظر می گیریم.که تصویر شماتیک آن به صورت زیر می باشد :جداسازی یا Encapsule نمودن رفتارهای متغیرماجرا هنوز ادامه دارد و در قسمت های بعدی بیشتر آن را درک می کنیم....zahra aghaeizahra aghaeiMon, 15 Feb 2021 14:24:38 +0330