اصول استفاده از الگوی مستطیل

طراحی شی گرا چیست؟کل این در بارهی چیست؟مزایای آن چیست؟هزینه های آن چیست؟ممکن است احمقانه به نظر برسد که این سؤالات را در یک روز و سن بپرسید که تقریباً هر توسعه دهنده نرم افزاری از یک زبان شی گرا به نوعی استفاده می کند. با این حال ، این سؤال مهم است زیرا به نظر من ، بیشتر ما از آن زبانها استفاده می کنیم بدون اینکه بدانیم چرا ، و بدون اینکه بدانیم چگونه بیشترین سود را از آنها بدست آوریم.

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

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

در مارس 1995 ، در Comp. Object ، من مقاله ای را نوشتم که اولین درخشش مجموعه ای از اصول برای OOD بود که از آن زمان تاکنون بارها نوشتم. شما آنها را در کتاب PPP من و در بسیاری از مقالات در وب سایت Objectmentor ، از جمله خلاصه شناخته شده ، مستند خواهید کرد.

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

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

پنج اصل اول اصول طراحی کلاس است. آن ها هستند:

SRP	اصل مسئولیت واحد ''	یک کلاس باید یک و تنها یک دلیل برای تغییر داشته باشد.
OCP	اصل بسته بسته	شما باید بتوانید بدون تغییر آن ، یک رفتار کلاس را گسترش دهید.
LSP	اصل تعویض لیسکوف	کلاسهای مشتق شده باید برای کلاسهای پایه خود جایگزین شوند.
ISP	اصل تفکیک رابط	رابط های ریز دانه ای که خاص مشتری هستند ایجاد کنید.
غرق شدن	اصل وارونگی وابستگی	به انتزاع بستگی دارد ، نه به بتن ها.

شش اصل بعدی درباره بسته ها است. در این زمینه ، یک بسته یک باینری قابل تحویل مانند یک پرونده . jar یا DLL بر خلاف فضای نام مانند بسته جاوا یا فضای نام C ++ است.

سه اصل بسته اول مربوط به انسجام بسته است ، آنها به ما می گویند چه چیزی را باید در داخل بسته بندی کنید:

هرزه	اصل استفاده مجدد از انتشار	گرانول استفاده مجدد گرانول رهاسازی است.
CCP	اصل بسته شدن مشترک	کلاس هایی که با هم تغییر می کنند با هم بسته بندی می شوند.
CRP	اصل استفاده مجدد مشترک	کلاس هایی که در کنار هم استفاده می شوند با هم بسته بندی می شوند.

سه اصل آخر در مورد اتصالات بین بسته ها است و در مورد معیارهایی که ساختار بسته یک سیستم را ارزیابی می کنند صحبت می کنند.

ADP	اصل وابستگی های آسیکلیک	نمودار وابستگی بسته ها نباید هیچ چرخه ای داشته باشد.
SDP	اصل وابستگی پایدار	به جهت ثبات بستگی دارد.
شیره	اصل انتزاع پایدار	چکیده با ثبات افزایش می یابد.

شما می توانید مقالاتی را که همه این اصول را در بخش مقالات قدیمی CleanCoder. com توصیف می کند ، پیدا کنید.

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

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

من یک ستون منظم در مجله توسعه نرم افزار دارم. آن را "crafstman" نامیده می شود. در آن من در مورد TDD ، اصول ، الگوهای و زندگی در یک ستاره دریایی چیزهای زیادی می نویسم. شما می توانید لیستی از تمام این مقاله ها را مشاهده کنید: http://www. objectmentor. com/resource/listarticles؟key=topic& topic=craftsman

من همچنین مقالات برجسته ای را برای این مجله هر از گاهی و برای سایر مجلات نیز می نویسم. شما می توانید آنها را پیگیری کنید ، و تمام مقالاتی که مربیان شیء در http://www. objectmentor. com/resource/articleindex می نویسند

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

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

OOP خیلی انعطاف پذیر است. می توانید از آن برای همه چیز و برعکس همه چیز استفاده کنید. به همین دلیل اینقدر محبوب شد. اصول پس از آن همیشه بحث برانگیز است. به عنوان مثال برای اصولگرایان محاصره (مواردی که از طراحی خودداری می کنند یا حتی از تنظیم کننده/گیرنده استفاده می کنند) چه اتفاقی افتاده است؟همچنین برنامه نویسی ساختاری یک گلوله نقره ای نیست و اغراق آمیز با آن اوضاع را بدتر می کند (حداقل این همان چیزی است که من سعی می کنم به دانش آموزانم آموزش دهم .. شرمنده من!). به همین دلیل توصیه شما بسیار مهم است: زیرا از نظر تجربی مبتنی است.

هنریک: با استفاده از الگوهای ، به شما پیشنهاد می کنم نگاهی به پیش نویس قبلی داشته باشید (http://scholar. google. com/url؟sa=u& q=http://www. tarrani. net/refactoringtopatterns. PDF) که حاوی نیمی از الگوهای است اما احساس رویکرد کلی را به شما می دهد (با عرض پوزش اگر من از این فضا برای پاسخ به پاسخ دیگر استفاده می کنم).

اصلاح مجدد به الگوهای بسیار جذاب است. نمونه ها با کد خاص دامنه واقعی سروکار دارند ، اما اصول برای سایر حوزه ها قابل اجرا است.

• بیش از نیم دهه طول کشید تا بفهمم که این درست نیست. OOP و OOD تفکیک ناپذیر هستند. OOA تعریف نشده است.- UB

تا زمانی که این تغییر کند ، ما گیر کرده ایم.

• نه ، ما گیر نکرده ایم. وابستگی ها قابل کنترل هستند.- UB

من کتاب فوق العاده شما را خوانده ام< agile software development >، در فصل 19 ، شما سیستم حقوق و دستمزد را پیاده سازی می کنید. اکنون من یک سیستم حقوق و دستمزد واقعی [؟] طراحی می کنم ، اما نمی دانم چه موقع و چگونه می توانم جزئیات پایگاه داده را اضافه کنم؟من می توانم ابتدا UI را اضافه کنم و سپس نیاز مشتری را برآورده کنم؟

• توصیه می کنم ابتدا روی قوانین تجاری تمرکز کنید. در ابتدا نگران UI یا بانک اطلاعاتی نباشید. قوانین تجاری (مالیات ، کسر و غیره) را به کار خود ادامه دهید. سپس می توانید یک پایگاه داده اضافه کنید. و در آخر می توانید UI اضافه کنید.- UB

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

• LOD یک موضوع وابستگی است. بیانیه ای مانند system. trunk. line. linecard. connect () اطلاعات بیش از حد را در یک مکان واحد متمرکز می کند. که یک خط کد در مورد چهار کلاس می داند! گره های بزرگی از وابستگی ها مانند این نقض OCP است. هرگونه تغییر در ساختار داده باعث تغییر در آن خط کد می شود.

آیا می توانیم بحث را از اینجا شروع کنیم؟بیایید بگوییم که ما یک الگوی برخی از نهادها داریم ، می گویند یک ForumTopic [؟]. ما این مسئولیت را برای ارائه یک موضوع انجمن به ما می دهیم. اکنون یک مورد کلاسیک - ما می خواهیم مدل های ما قابل مشاهده باشد. بنابراین ما مسئولیت اطلاع رسانی به ناظران آن در مورد تغییر دولت را اضافه می کنیم. نقض SRP.

چگونه می توان در حالی که از الگوی Observer در اینجا استفاده می کنیم ، به SRP احترام بگذاریم [؟] به SRP احترام بگذاریم؟

• شما می توانید از فرم کلاس الگوی آداپتور (یعنی میراث متعدد) به شرح زیر استفاده کنید:

با تشکر از کتاب توسعه نرم افزار چابک شما - یک منبع عالی. من یک سوال در مورد ISP دارم. پاراگراف دوم به صراحت بیان می کند که برخی از اشیا به رابط های غیر منسجم نیاز دارند. بنابراین من یک شی O با دو واسط غیر منسجم A و B دارم. سوال من این است - وقتی یک کلاینت به O به عنوان نمونه ای از A دسترسی داشته باشد و سپس در نقطه ای به O به عنوان یک نمونه از B دسترسی داشته باشد، چگونهآیا آن مدیریت می شود؟غریزه من به من می گوید که از یک کارخانه برای تبدیل استفاده کنم تا دانش اینکه A و B در O همسان هستند جدا شود (اجازه دادن به آداپتورها و سایر جایگزین ها) اما من مطمئن نیستم. هر توصیه ای استقبال می شودبازم ممنون

من امشب دارم از طریق PPP می خوانم، و کتاب جذابی است. اما به نظر می‌رسد مثال‌هایی که برای نشان دادن بوی طراحی استفاده می‌کنید وابسته به استفاده از زبانی با تایپ ایستا مانند C++ هستند، با راه‌حل‌هایی که شامل کلاس‌های پایه مجازی و/یا MI هستند.

من دارم با روبی بازی می کنم، که هیچ یک از موارد بالا را ندارد، و در ابتدا به نظرم می رسد که بسیاری از مسائل "الزام آور" در آنجا وجود ندارند. LSP ذاتاً توسط "duck-typing" اعمال می‌شود و کلاس‌ها را می‌توان به طور مکرر در فایل‌های منبع مختلف گسترش داد و ISP را ارائه کرد. به این ترتیب، SRP و OCP به نظر مهم نیستند. آیا بحث یا مقاله ای در مورد نحوه اعمال این اصول در زبان های پویا وجود داشته است؟

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

کتاب عالی است. من چند سوال عمیق تر دارمچیزی که اخیراً با آن دست و پنجه نرم می کنم، تعریف یک مسئولیت است. شما می نویسید، "در زمینه SRP، ما مسئولیت را "دلیلی برای تغییر" تعریف می کنیم."

با این حال، کلمه "مسئولیت" نشان می دهد که معنای ریشه ای مربوط به مدیریت نوعی ویژگی است، و این تغییر فقط یک *نشانه* از مدیریت آن ویژگی است. مسئولیت های دیگر کشف نشده باقی می مانند تا زمانی که تغییری آنها را آشکار کند. اما در تعریف آن مشکل داشتم.

منظورم این است که اگر تمام چیزی که می‌خواستید بیان کنید «دلیلی برای تغییر» بود، می‌توانستید آن را اصل «دلیل واحد برای تغییر» بنامید. پس چرا از کلمه "مسئولیت" استفاده کردید؟و آیا تعریفی عمیق تر از «دلیلی برای تغییر» وجود دارد؟

• یک ماژول باید یک کار را انجام دهد، آن را به خوبی انجام دهد و فقط آن را انجام دهد.

• یک ماژول باید یک و تنها یک دلیل برای تغییر داشته باشد.

سلام عمو باب ، من مقالاتی را که توسط شما نوشته شده است با علاقه زیادی خواندم. در واقع ما هر روز دوشنبه یک مقاله فنی را پوشش می دهیم. امروز ما اصل تعویض لیسکوف را انجام دادیم. لطفا اگر سوال من خیلی ساده لوحانه به نظر می رسد ، مرا ببخشید. شما در مورد فاکتورسازی به عنوان یکی از راه های ساخت کلاس LSP صحبت کردید. برای exampe شما خط LineaRobject [؟] و خط زیر کلاس و Linesegment [؟] را از آن ایجاد کرده اید. من تعجب می کردم که آیا کلاس های مشتق شده روش هایی دارند که نمی توانند در یک کلاس پایه متمرکز شوند. به عنوان مثال اگر من دایره ، مستطیل و مربع را برای ساختن کلاس شکل و روش قرعه کشی در آن قرار دهم. چه می شود اگر من هم نیاز به چرخش مستطیل و مربع داشته باشم اما نه دایره. پس چه کار می کردم؟آیا باید روش چرخش را در کلاس شکل پایه قرار دهم و یک روش چرخشی دژنراتیو را در اجرای دایره و جامد در مستطیل و مربع بنویسم؟

به طور کلی چه کاری باید انجام دهم اگر کلاسهای با بیانیه من دارای برخی از رفتارهای مشترک باشند اما همچنین دارای رفتارهای منحصر به فردی هستند.