مجموعهای از APIهای عمومی
قصد دارم مجموعه ای کامل از اصول طراحی شیء گرا، الگوهای طراحی و best practice های مربوطه را ارائه دهم. از این رو ابتدا با اصول طراحی شروع میکنم. سپس در مقالات آتی به الگوهای مختلف خواهم پرداخت و تا جایی که معلومات اجازه دهد مشخص خواهم کرد که هر الگو متمرکز بر رعایت کدام یک از اصول است و اینکه آیا مناسب است از الگوی مورد نظر استفاده کنیم.
این مطالب نیز چکیده ای از آموزشهای Lynda, Pluralsight , SkillFeed و کتاب های Gang of four, Headfirst Design
patterns و ...
میباشد .
اصل اول: Encapsulate what varies
"آنچه را که تغییر میکند مشخص و جدا کن یا به عبارتی آنرا کپسوله کن"
برای آنکه بتوانیم کدی منعطف،
قابل استفاده مجدد و خوانا داشته باشیم، ابتدا باید بخشهای ثابت و متغیر کد را تشخیص
دهیم و کاری کنیم تا بخش ثابت، بدون تکرار در جای جای برنامه استفاده شود و سپس برای بخش
متغیر برنامه ریزی کنیم.
اصل دوم: Program to an interface not implementation
" برنامه نویسی را متمرکز بر واسط کن، نه نحوهی پیاده سازی "
برای این اصل تعابیر مختلفی ارائه شده است:
- تمرکز بر واسطها به معنای تمرکز بر رفتار است که باعث میشود انعطاف برنامه بیشتر شده و با تغییر نحوهی پیاده سازی بتوان همچنان سیستمی پایدار داشت.
- تمرکز بر "چه کاری انجام میشود" باعث میشود بدون نگرانی از "چگونگی انجام آن" بتوانیم معماری سیستم را طراحی کنیم.
- واسطها نقش پروتکل را دارند و باعث پنهان شدن نحوهی پیاده سازی از چشم کلاینت (استفاده کنندهی خدمت) میشوند و آنها را ملزم میکنند تا به ورودی و خروجی تمرکز کنند.
برای رعایت این اصل باید:
- سعی بر تعریف واسط برای اکثر کلاسها کنیم
- اشیا را از نوع واسط تعریف
کنیم، نه کلاسهای پیاده ساز آن
در کد زیر نحوهی تعریف واسط را برای کلاس و تعریف اشیاء از نوع واسط را میبینیم:
public interface IMyInterface { void DoWork(); } public class MyImplementation1 : IMyInterface { public void DoWork() { var implementationName = this.GetType().ToString(); Console.WriteLine("DoWork from " + implementationName); } } public class MyImplementation2 : IMyInterface { public void DoWork() { var implementationName = this.GetType().ToString(); Console.WriteLine("DoWork from " + implementationName); } } public class Context { IMyInterface myInterface; public void Print() { myInterface = new MyImplementation1(); myInterface.DoWork(); myInterface = new MyImplementation2(); myInterface.DoWork(); } }
اصل سوم: Favor composition over inheritance
"ترکیب را بر توارث ترجیح بده"
رابطه "دارد" (has a ) انعطاف بیشتری نسبت به ارث بری یا "از نوع ... هست" ( is a ) دارد. برای مثال فرض کنید کلاس Enemy رفتار Movable را دارد و این رفتار در طول بازی بر حسب موقعیتی تغییر میکند. اگر این رفتار را با توارث مدل کنیم، یعنی Enemy از نوع Movable باشد، آنگاه برای هر نوع رفتار Movable (هر نوع پیاده سازی) باید یک نوع Enemy داشته باشیم و تصور کنید بعضی از این پیاده سازیها در کلاس Player یکسان باشد. آنگاه کد باید دوباره تکرار شود. حال تصور کنید این موقعیت را با ترکیب مدل کنیم. آنگاه کلاس Enemy یک شیء از جنس Movable خواهد داشت و در زمان نیاز میتواند نوع این رفتار را با نمونه گیری از کلاسهای پیاده ساز آن، تغییر دهد. در واقع با اینکار اصل اول را رعایت کرده ایم و بخش ثابت را از بخش متغیر جدا نموده ایم.
در زیر مدلسازی با توارث را میبینیم:
public interface Movable { void Move(); } public class EnemyBase : Movable { // Enemy properties goes here protected int x, y; public virtual void Move() { x += 2; y += 2; } } public class EnemyWithMoveType2 : EnemyBase { // override the move method public override void Move() { x += 4; y += 4; } } public class EnemyWithMoveType3 : EnemyBase { // override the move method public override void Move() { x += 6; y += 6; } } public class PlayerBase : Movable { // Player properties goes here protected int x, y; public virtual void Move() { // same code as EnemyBase move method x += 2; y += 2; } } public class PlayerWithMoveType2 : PlayerBase { // override the move method public override void Move() { // same code as EnemyWithMoveType2 move method x += 4; y += 4; } } public class PlayerWithMoveType3 : PlayerBase { // override the move method public override void Move() { // same code as EnemyWithMoveType3 move method x += 6; y += 6; } }
در ادامه نیز مدلسازی با ترکیب را میبینیم:
public interface IMovable { void Move(ref int x, ref int y); } public class EnemyBase { // Enemy properties goes here protected int x, y; IMovable moveBehavior; public void SetMoveBehavior(IMovable _moveBehavior) { moveBehavior = _moveBehavior; } public void Move() { moveBehavior.Move(ref x,ref y); } } public class PlayerBase { // Player properties goes here protected int x, y; IMovable moveBehavior; public void SetMoveBehavior(IMovable _moveBehavior) { moveBehavior = _moveBehavior; } public void Move() { moveBehavior.Move(ref x, ref y); } } public class MoveBehavior1 { public void Move(ref int x, ref int y) { x += 2; y += 2; } } public class MoveBehavior2 : IMovable { public void Move(ref int x, ref int y) { x += 4; y += 4; } } public class MoveBehavior3 : IMovable { public void Move(ref int x, ref int y) { x += 6; y += 6; } }
همانطور که میبینید، با فراخوانی تابع SetMoveBehavior میتوان رفتار را در زمان اجرا تغییر داد.
در مقالهی بعدی به ادامهی اصول خواهم پرداخت. از شنیدن نظرات و سوالات شما خرسند خواهم شد.
This is the first of an eight part series where I am joined by Phil Japikse to discuss design patterns. A design pattern is a best practice you can use in your code to solve a common problem. In this episode, Phil demonstrates the Command and Memento patterns.
Episodes in this series:
- Command/Memento patterns (this episode)
- Strategy pattern
- Template Method pattern (to be published 7/20)
- Observer/Publish-Subscribe patterns (to be published 7/25)
- Singleton pattern (to be published 8/8)
- Factory patterns (to be published 8/10)
- Adapter/Facade patterns (to be published 8/15)
- Decorator pattern (to be published 8/17)
در قسمت اول با مفاهیم اولیه Class و Object آشنا شدیم.
Messages and Methods
Objectها باید مانند ماشینهایی تلقی شوند که عملیات موجود در واسط عمومی خود را برای افرادی که درخواست مناسبی ارسال کنند، اجرا خواهند کرد. با توجه به اینکه یک object از استفاده کننده خود مستقل است و وابستگی به او ندارد و همچنین توجه به ساختار نحوی (syntax) برخی از زبانهای شیء گرای جدید، عبارت «sending a message» برای توصیف اجرای رفتاری از مجموعه رفتارهای object، استفاده میشود.
به محض اینکه پیغامی (Message) به سمت object ارسال شود، ابتدا باید تصمیم بگیرد که این پیغام ارسالی را درک میکند. فرض کنیم این پیغام قابل درک است. در این صورت object مورد نظر، همزمان با نگاشت پیغام به یک فراخوانی تابع (function call)، خود را به صورت ضمنی به عنوان اولین آرگومان ارسال میکند. تصمیم گرفتن در رابطه با قابل درک بودن یک پیغام، در زبانهای مفسری در زمان اجرا و در زبانهای کامپایلری در زمان کامپایل، انجام میگرد.
نام (یا prototype) رفتار یک وهله، Message (پیغام) نامیده میشود. بسیاری از زبانهای شیء گرا مفهموم Overloaded Functions Or Operators را پشتیبانی میکنند. در این صورت میتوان در سیستم دو تابعی داشت که با نام یکسان، یا انواع مختلف آرگومان (intraclass overloading) داشته باشند یا در کلاسهای مختلفی (interclass overloading) قرار گیرند.
ممکن است کلاس ساعت زنگدار، دو پیغام set_time که یکی از آنها با دو آرگومان از نوع عدد صحیح و دیگری یک آرگومان رشتهای است داشته باشد.
void AlarmClock::set_time(int hours, int minutes); void AlarmClock::set_time(String time);
در مقابل، کلاس ساعت زنگدار و کلاس ساعت مچی هر دو messageای به نام set_time با دو آرگومان از نوع عدد صحیح دارند.
void AlarmClock::set_time(int hours, int minutes); void Watch::set_time(int hours, int minutes);
باید توجه کنید که یک پیغام، شامل نام تابع، انواع آرگومان، نوع بازگشتی و کلاسی که پیغام به آن متصل است، میباشد. این اطلاعاتی که مطرح شد، بخش اصلی چیزی است که کاربر یک کلاس نیاز دارد در مورد آنها آگاهی داشته باشد.
در برخی از زبانها و یا سیستمها، اطلاعات دیگری مانند: انواع استثناءهایی که از سمت پیغام پرتاب میشوند تا اطلاعات همزمانی (پیغام به صورت همزمان است یا ناهمزمان) را برای استفاده کننده مهیا کنند. از طرفی پیاده سازی کنندگان یک کلاس باید از پیاده سازی پیغام آگاه باشند. جزئیات پیاده سازی یک پیغام -کدی که پیغام را پیاده سازی میکند- Method (متد) نامیده میشود. آنگاه که نخ (thread) کنترل درون متد باشد، برای مشخص کردن اینکه پیغام رسیده برای کدام وهله ارسال شدهاست، ارجاعی به وهله مورد نظر و به عنوان اولین آرگومان، به صورت ضمنی ارسال میشود. این آرگومان ضمنی، در بیشتر زبانها Self Object نامیده میشود (در سی پلاس پلاس this object نام دارد). در نهایت، مجموعه پیغامهایی که یک وهله میتواند به آنها پاسخ دهد، Protocol (قرارداد) نام دارد.
دو پیغام خاصی که کلاسها یا وهلهها میتوانند به آنها پاسخ دهند، اولی که استفاده کنندگان کلاس برای ساخت وهلهها از آن استفاده میکنند، Constructor (سازنده) نام دارد. هر کلاسی میتواند سازندههای متعددی داشته باشد که هر کدام مجموعه پارامترهای مختلفی را برای مقدار دهی اولیه میپذیرند. دومین پیغام، عملیاتی است که وهله را قبل از حذف از سیستم، پاک سازی میکند. این عملیات، Destructor (تخریب کننده) نام دارد. بیشتر زبانهای شیء گرا، برای هر کلاس تنها یک تخریب کننده دارند. این پیغامها را به عنوان مکانیزم مقدار دهی اولیه و پاک سازی در پارادایم شیء گرا در نظر بگیرید.
قاعده شهودی 2.2
استفاده کنندگان از کلاس باید به واسط عمومی آن وابسته باشند، اما یک کلاس نباید به استفاده کنندگان خود، وابسته باشد. (Users of a class must be dependent on its public interface, but a class should not be dependent on its users)
منطق پشت این قاعده، یکی از شکلهای قابلیت استفاده مجدد (resuability) میباشد. یک ساعت زنگدار ممکن است توسط شخصی در اتاق خواب او استفاده شود. واضح است که شخص مورد نظر به واسط عمومی ساعت زنگدار وابسته میباشد. به هر حال، ساعت زنگدار نباید به شخصی وابسته باشد. اگر ساعت زنگدار به شخصی وابسته باشد، بدون مهیا کردن یک شخص، نمیتوان از آن برای ساخت یک TimeLockSafe استفاده کرد. این وابستگیها برای مواقعیکه میخواهیم امکان این را داشته باشیم تا کلاس ساعت زنگدار را از دامین (domain) خود خارج کرده و در دامین دیگری، بدون وابستگی هایش مورد استفاده قرار دهیم، نامطلوب هستند.
شکل 2.4 The Use Of Alarm Clocks
قاعده شهودی 2.3
تعداد پیغامهای موجود در قرارداد یک کلاس را کمینه سازید. (Minimize the number of messages in the protocol of a class)
چندین سال قبل، مطلبی منتشر شد که کاملا متضاد این قاعده شهودی میباشد. طبق آن، پیاده سازی کننده یک کلاس میتواند یکسری عملیات را با فرض اینکه در آینده مورد استفاده قرار گیرند، برای آن در نظر بگیرد. ایراد این کار چیست؟ اگر شما از این قاعده پیروی کنید، حتما کلاس LinkedList من، توجه شما را جلب خواهد کرد؛ این کلاس در واسط عمومی خود 4000 عملیات را دارد. فرض کنید قصد ادغام دو وهله از این کلاس را داشته باشید. در این صورت حتما فرض شما این است که عملیاتی تحت عنوان merge در این کلاس تعبیه شده است. بعد از جستجوی بین این تعداد عملیات، در نهایت این عملیات خاص را پیدا نخواهید کرد. چراکه این عملیات متأسفانه به صورت یک overloaded plus operator پیاده سازی شده است. مشکل اصلی واسط عمومی با تعداد زیادی عملیات این است که فرآیند یافتن عملیات مورد نظرمان را خیلی سخت یا حتی ناممکن خواهد کرد و مشکلی جدی برای قابلیت استفاده مجدد تلقی میشود.
با کمینه نگه داشتن تعداد عملیات واسط عمومی، سیستم، قابل فهمتر و همچنین مولفههای (components) آن به راحتی قابل استفاده مجدد خواهند بود.
قاعده شهودی 2.4
پیاده سازی یک واسط عمومی یکسان کمینه برای همه کلاسها (Implement a minimal public interface that all classes understand [e.g., operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from an ASCII description, etc.].)
مهیا کردن یک واسط عمومی مشترک کمینه برای کلاسهایی که توسط یک توسعه دهنده پیاده سازی شده و قرار است توسط توسعه دهندگان دیگر مورد استفاده قرار گیرد، خیلی مفید خواهد بود. این واسط عمومی، حداقل عاملیتی را که به طور منطقی از هر کلاس میشود انتظار داشت، مهیا خواهد ساخت. واسطی که میتواند از آن به عنوان مبنای یادگیری درباره رفتارهای کلاسها در پایه نرم افزاری با قابلیت استفاده مجدد، بهره برد.
به عنوان مثال کلاس Object در دات نت به عنوان کلاس پایه ضمنی با یکسری از متدهای عمومی (برای مثال ToString)، نشان دهنده تعریف یک واسط عمومی مشترک برای همه کلاسها در این فریمورک، میباشد.
public class Object { public Object(); public static bool Equals(Object objA, Object objB){...} public static bool ReferenceEquals(Object objA, Object objB){...} public virtual bool Equals(Object obj){...} public virtual int GetHashCode(){...} public Type GetType(){...} public virtual string ToString(){...} protected Object MemberwiseClone(){...} }
قاعده شهودی 2.5
جزئیات پیاده سازی، مانند توابع خصوصی common-code ( توابعی که کد مشترک سایر متدهای کلاس را در بدنه خود دارند) را در واسط عمومی یک کلاس قرار ندهید. (Do not put implementation details such as common-code private functions into the public interface of a class)
این قاعده برای کاهش پیچیدگی واسط عمومی کلاس برای استفاده کنندگان آن، طراحی شده است. ایده اصلی این است که استفاده کنندگان کلاس تمایلی ندارند به اعضایی دسترسی داشته باشند که از آنها استفاده نخواهند کرد؛ این اعضا باید به صورت خصوصی در کلاس قرار داده شوند. این توابع خصوصی common-code، زمانیکه متدهای یک کلاس، کد مشترکی را داشته باشند، ایجاد خواهند شد. قرار دادن این کد مشترک در یک متد، معمولا روش مناسبی میباشد. نکته قابل توجه این است که این متد، عملیات جدیدی نمیباشد؛ بله جزئیات پیاده سازی دو عملیات دیگر از کلاس را ساده کرده است.
شکل 2.5 Example of a common-code private function
مثال واقعی
فرض کنید در شکل بالا، کلاس X معادل یک LinkedList کلاس، f1و f2 به عنوان توابع insert و remove و تابع f به عنوان تابع common-code که عملیات یافتن آدرس را برای درج و حذف انجام میدهد، میباشند.
قاعده شهودی 2.6
واسط عمومی کلاس را با اقلامی که یا استفاده کنندگان از کلاس توانایی استفاده از آن را نداشته و یا تمایلی به استفاده از آنها ندارند، آمیخته نکنید. (Do not clutter the public interface of a class with items that users of that class are not able to use or are not interested in using )
این قاعده شهودی با قاعده قبلی که با قرار دادن تابع common-code در واسط عمومی کلاس، فقط باعث در هم ریختن واسط عمومی شده بود، مرتبط میباشد. در برخی از زبانها مانند C++، برای مثال این امکان وجود دارد که سازنده یک کلاس انتزاعی (abstract) را در واسط عمومی آن قرار دهید؛ حتی با وجود اینکه در زمان استفاده از آن سازنده با خطای نحوی روبرو خواهید شد. این قاعده شهودی کلی، برای کاهش این مشکلات در نظر گرفته شده است.
(The God Class Problem (Behavioral Form
یکی از مخاطراتی که ممکن است موجب عدم بروز مزایای شیء گرایی در طرح شما شود، بحث God Class میباشد. شکل رفتاری آن (Behavioral Form) بیشتر در اثر یک خطای مشترک بین توسعه دهندگان پارادایم action-oriented و در جریان مهاجرت به سمت پارادایم شیء گرا، رخ میدهد.
این توسعه دهندگان بیشتر سعی در تسخیر و دستیابی به یک مکانیزم کنترل مرکزی شبیه به آنچه در پارادایم action-oriented داشتهاند، در طراحی شیء گرای خود دارند. حاصل این کار تشکیل کلاسی خواهد بود که همه کارها را انجام میدهد، درحالیکه جزئیات ناچیزی هم به عهده مجموعهای از کلاسها سپرده شده است.
قاعده شهودی 3.1
تا حد ممکن هوشمندی سیستم را به صورت افقی و به طور یکنواخت توزیع کنید. به این معنی که کلاسهای سطح بالای موجود در طراحی، باید کار را به طور یکسان مابین خود به اشتراک بگذارند. (Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly)منظور اینکه Businessای را که سیستم قرار است پیاده سازی کند، بین کلاسهای سطح بالا تقسیم کنید. در حالت vertical یا عمودی میتوان در نظر گرفت که کلاسی این Business را توسط یکسری متد در دل خود پیاده سازی کند و این متدها یکدیگر را فراخوانی خواهند کرد.
قاعده شهودی 3.2
در سیستم خود God Class ایجاد نکنید. به کلاس هایی که نام آنها شامل Driver، Manager و یا Subsystem میباشد، مشکوک باشید. (Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem)
مانند: BlahBlahSystem یا BlahManager
قاعده شهودی 3.3مراقب کلاس هایی باشید که در واسط عمومی آنها تعداد زیادی Accessor Method تعریف شده است؛ وجود آنها نشان از این دارد که داده و رفتار، در یکجا نگه داشته نشده اند. (Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place)ازدیاد عملیات get و set در واسط عمومی کلاسها که Accessor Method نامیده میشوند، نشان دهنده ایجاد شکل رفتاری God Class میباشند. منظور این است که یک کلاس، رفتارهایی برای کار کردن با دادههای خود در نظر نگرفته است و این دادهها را از طریق accessor methodها در اختیار کلاس دیگری قرار میدهد تا عملیات روی دادهها را انجام دهد. در اینجا هم مقصود God Class شدن کلاسی است که از این accessor methodها استفاده میکند و نشان از این دارد که تعداد رفتارهای آن زیاد خواهد شد.
مراقب کلاس هایی باشید که تعداد خیلی زیادی رفتار نامرتبط دارند؛ یعنی رفتارهایی که فقط برروی زیر مجموعه ای از دادههای کلاس کار میکنند. God Classها اغلب دارای اینگونه رفتارهای نامرتبط به هم هستند. (Beware of classes that have too much noncommunicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit much noncommunicating behavior)منظور اینکه کلاس مورد نظر را میتوان شکست و تبدیل به دو کلاس مختلف کرد. به عنوان اولین مثال، دامنه مربوط به سیستم برنامه ریزی دورههای آموزشی را در نظر بگیرید. در این دامنه، ما با وهله هایی از «Student» ،«Course» و «CourseOffering» سروکار خواهیم داشت.
قصد داریم با فراخوانی متد ()add_student مربوط به CourseOffering، یک دانشجو را به لیست شرکت کنندگان یک دوره اضافه کنیم. همچنین در این زمان لازم است مطمئن شویم که دانشجوی مورد نظر تمام پیش نیازهای دوره انتخاب شده را گذرانده باشد. به نظر شما کدام کلاس میبایست عملیات چک کردن پیش نیازها را انجام دهد؟
کلاس دانشجو از دورههایی که گذرانده است آگاه است و کلاس دوره هم از پیش نیازهای خود. در بهترین حالت شاید یکی از طراحیهای زیر را ارائه دهید. به شکلی که یا کلاس دوره با استفاده از متد get_courses مربوط به کلاس دانشجو، داده مورد نیاز را بدست آورده و عملیات چک کردن را در دل خود بگنجاند یا برعکس.
در هر دو طراحی بالا، بخشی از اطلاعات مربوط به policy (سیاست) در کلاس هایی قرار دارد که موضوع تصمیمات سیاستها هستند. این کار از آن جهت که کلاسهای مورد نظر ما را به دامنه خاصی که این policy در آن دامنه معنا دارد وابسته میکند و امکان استفاده مجدد از آن کلاسها را از دست خواهید داد.
راه حلهای پیشنهادی برای مشکل مطرح شده به شکل زیر میباشند:
با توجه به طراحی شکل بالا، یا خود کلاس CourseOffering با استفاده از لیست دورههای گذرانده شده توسط دانشجو و لیست دورههای پیش نیاز دوره انتخابی، چک کردن را انجام دهد و یا کلاسی با عنوان PrereqChecker که یک Controller Class (کلاسی که فقط رفتار دارد و داده مورد نظر خود را توسط سایر کلاسها و از طریق accessor methodهای آنها تأمین میکند) میباشد، وظیفه چک کردن را برعهده بگیرد.
علاوه بر اینکهaccessor method ها، داده را برای کلاسهای کنترلر مهیا میکنند (مانند مثال بالا)، وظیفهی مهیا کردن داده برای UI (رابط کاربری) را نیاز بر عهده خواهند داشت. به این صورت که رابط کاربری، با استفاده از این متدها، مشخصات درونی مدل را نمایش دهد و یا این امکان را به کاربر میدهد که این مشخصات درونی مدل را ویرایش کرده و به سمت مدل ارسال نماید.
قاعده شهودی 3.5
در برنامههایی که شامل یک مدل شی گرایی میباشند که با رابط کاربری تعامل دارند، مدل نباید به رابط کاربری وابسته باشد. رابط کاربری میبایست وابسته به مدل باشد. (In applications that consist of an object-oriented model interacting with a user interface, the model should never be dependent on the interface. The interface should be dependent on the model)
برای عدم نقض این قاعده شهودی، لازم است در مدل یکسری accessor method در نظر گرفته شود تا رابط کاربری از آن استفاده کند؛ ولی باید مراقب بود که این accessor methodها صرفا توسط رابط کاربری استفاده شود و عدم توجه به این قضیه، احتمالا شما را به سمت نقض قاعده 3.3 متمایل خواهد کرد.