در هنگام طراحی نرم افزار، یک سری اصول هستند که در صورتی که به این اصول توجه شود، نرم افزار طراحی شده، سریع تر و ساده تر قابل توسعه و نگهداری مباشد. در این مطلب به شرح کوتاهی از برخی از این اصول میپردازیم
اصل Kiss-Keep it simple stupid :
در نرم افزار همیشه با مسائل و مشکلات بغرنغ و پیچیده سر و کار داریم. این اصل به ما میگوید که همیشه راه حل های ارائه شده باید ساده و قابل فهم باشد. در نیتجه باید از پیچیدگی های ناکارامد دوری کنیم.
عدم تکرار DRY-Don’t repeat Yourself:
یعنی هیچ قسمتی از نرم افزار نباید تکراری باشد. در صورتی که به یک قسمت در بیش از یک جا نیاز است، باید این قسمت طوری طراحی و پیاده سازی شود که بدون وابستگی به قسمت های دیگر نرم افزار باشد و در هرجا نیاز بود از همان واحد استفاده شود.
بیان خواسته ها Tell, Don’t ask:
این اصل بیانگر اصل کپسوله سازی است. یعنی هنگامی که با یک قسمت سر و کار داریم باید خواسته هایمان را به آن قسمت بدهیم و خروجی را تحویل بگیریم نه اینکه ابتدا وضعیت شی را بررسی کنیم و بعد مجددا خودمان تصمیم بگیریم که حالا چه عملی باید انجام شود.
پیاده سازی احتیاجات YAGNI-You ain’t Gonna need it:
یعنی تنها قسمت هایی که واقعا به آنها نیاز دارید طراحی و پیاده سازی کنید، نه قسمت هایی که خیال میکنید به آنها نیاز خواهید داشت.
جدا سازی قسمت ها SoC-separation of Concerns:
یعنی قسمت های مختلف برنامه که کارهای مختلفی انجام میدهند را باید از هم جدا کرد تا در موقع نیاز از هر قسمت بتوان به طور جدا گانه استفاده کرد. یکی از راه های اجرای این اصل لایه بندی صحیح برنامه میباشد.
تک مسئولیتی SRP-single responsibility Principle:
هر قسمت از برنامه باید تنها یک مسئولیت داشته باشد و این مسئولیت را صحیح انجام دهد. این اصل با اصل SoCبسیار رابطه تنگاتنگی دارند. به کمک این اصل از پیچیدگی واحد های مختلف هم جلوگیری میشود.
جانشینی LSP-liskov substitution Principle:
یعنی شما باید بتوانید هر کلاس فرزندی را به جای والد خود به کار ببرید بدون اینکه به روند برنامه لطمه ای وارد شود.
جدا سازی طراحی از پیاده سازی DIP-Dependency inversion Principle:
بیانگر این موضوع است که طراحی و خواسته های ما نباید وابسته به پیاده سازی باشد. این کار را میتوانیم به کمک Interface ها انجام دهیم و ابتدا طراحی خود را انجام دهیم و سپس به سراغ پیاده سازی سیستم برویم.
اصل Kiss-Keep it simple stupid :
در نرم افزار همیشه با مسائل و مشکلات بغرنغ و پیچیده سر و کار داریم. این اصل به ما میگوید که همیشه راه حل های ارائه شده باید ساده و قابل فهم باشد. در نیتجه باید از پیچیدگی های ناکارامد دوری کنیم.
عدم تکرار DRY-Don’t repeat Yourself:
یعنی هیچ قسمتی از نرم افزار نباید تکراری باشد. در صورتی که به یک قسمت در بیش از یک جا نیاز است، باید این قسمت طوری طراحی و پیاده سازی شود که بدون وابستگی به قسمت های دیگر نرم افزار باشد و در هرجا نیاز بود از همان واحد استفاده شود.
بیان خواسته ها Tell, Don’t ask:
این اصل بیانگر اصل کپسوله سازی است. یعنی هنگامی که با یک قسمت سر و کار داریم باید خواسته هایمان را به آن قسمت بدهیم و خروجی را تحویل بگیریم نه اینکه ابتدا وضعیت شی را بررسی کنیم و بعد مجددا خودمان تصمیم بگیریم که حالا چه عملی باید انجام شود.
پیاده سازی احتیاجات YAGNI-You ain’t Gonna need it:
یعنی تنها قسمت هایی که واقعا به آنها نیاز دارید طراحی و پیاده سازی کنید، نه قسمت هایی که خیال میکنید به آنها نیاز خواهید داشت.
جدا سازی قسمت ها SoC-separation of Concerns:
یعنی قسمت های مختلف برنامه که کارهای مختلفی انجام میدهند را باید از هم جدا کرد تا در موقع نیاز از هر قسمت بتوان به طور جدا گانه استفاده کرد. یکی از راه های اجرای این اصل لایه بندی صحیح برنامه میباشد.
تک مسئولیتی SRP-single responsibility Principle:
هر قسمت از برنامه باید تنها یک مسئولیت داشته باشد و این مسئولیت را صحیح انجام دهد. این اصل با اصل SoCبسیار رابطه تنگاتنگی دارند. به کمک این اصل از پیچیدگی واحد های مختلف هم جلوگیری میشود.
جانشینی LSP-liskov substitution Principle:
یعنی شما باید بتوانید هر کلاس فرزندی را به جای والد خود به کار ببرید بدون اینکه به روند برنامه لطمه ای وارد شود.
جدا سازی طراحی از پیاده سازی DIP-Dependency inversion Principle:
بیانگر این موضوع است که طراحی و خواسته های ما نباید وابسته به پیاده سازی باشد. این کار را میتوانیم به کمک Interface ها انجام دهیم و ابتدا طراحی خود را انجام دهیم و سپس به سراغ پیاده سازی سیستم برویم.
3 نظرات:
این اصول واقعاً مفید هستند.
امکانش هست در مورد آیتم آخر بیشتر توضیح بدید؟!!
سلام
ببینید، ما توی برنامه نویسی کلاس هایی داریم که با کلاس های دیگر در تعامل هستند. مثلا توی کلاس ارسال پیام، ما با کلاس ایمیل در تعامل هستیم.
بهتره است برنامه رو جوری طراحی کنیم که این تعامل باعث وابستگی نشود.
یعنی مثلا یک اینترفیس برای مسیج داشته باشیم و با این اینترفیس در کلاس خودمون کار کنیم. و هر کلاسی میتواند این اینترفیس را پیاده سازی کند و با کلاس ارسال پیام ما تعامل داشته باشد، بدون اینکه نیازی به تغییر در کلاس ارسال داشته باشیم.
حالا کلاس پیام ما میخاد ایمیل باشه یا اس ام اس.
در کل این کار با الگوهایی که در ساختار Ioc جای میگیرند انجام میشود. یعنی به جای اینکه در داخل کلاس ما به بیرون وابستگی داشته باشیم، استفاده کننده وظیفه ارسال وابستگی ها رو داشته باشه.
ارسال یک نظر