رفتن به مطلب



iran rules jazbe modir
snapphost mahak

پست های پیشنهاد شده

Design Patternها یکسری جواب های ثابت شده به مشکلات رایج در طراحی هستند. به وسیله آنها می توان یکسری راهکار برای حل مسائل بازگشتی در طراحی برنامه تعریف کرد. به طور واضح، Design Patternها کدهای آماده ای نیستند که بتوان مستقیماً از آن ها استفاده کرد. اما یسکری رویکرد یا نظریه برای حل چالش های عادی طراحی ارائه می دهند.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

telegram channel   jazbe modir

Design Pattern

Design Patternها در زمان طراحی سیستم های نرم افزاری و یا فرایند تولید جواب بسیار مورد توجه قرار می گیرد. الگوها سر و صدای زیادی به پا کرده است. از طرفی ممکن است در استفاده از آن ها دچار سردرگمی بشویم. اساساً با سوالات زیر مواجه خواهیم بود:

 

 Design Pattern چیست؟

 چرا باید از Design Patternها استفاده کنیم؟

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

 چند الگو وجود دارد؟

در اولین سری از آموزش های Design Pattern سعی خواهیم کرد به این سوالات پاسخ دهیم.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

Design Pattern چیست؟

Design Patternها یکسری جواب های ثابت شده به مشکلات رایج در طراحی هستند. به وسیله آنها می توان یکسری راهکار برای حل مسائل بازگشتی در طراحی برنامه تعریف کرد.
به طور واضح، Design Patternها کدهای آماده ای نیستند که بتوان مستقیماً از آن ها استفاده کرد. اما یسکری رویکرد یا نظریه برای حل چالش های عادی طراحی ارائه می دهند.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

 چرا باید از Design Patternها استفاده کنیم؟

دلیل استفاده از آنها واضح است. چرا باید چرخ را دوباره اختراع کنیم؟ در حالیکه جواب های کاربردی، تست شده و مستند برای یکسری مسائل بازگشتی رایج داریم.
باید از design pattern ها برای طراحی و توسعه اجزاء (componentها) ای استفاده کنیم که مجدداً قابل استفاده و مقیاس پذیر بوده باشند و به تیم برنامه نویسی کمک کنند تا عملیات توسعه در زمان مقرر و با کیفیت بالاتری به انجام برسد.
طراحی یک برنامه به شکل استاندارد یا تست شده به سایر توسعه دهنده گان و کسانی که کدهای برنامه را قرار است مرور کنند، اجازه می دهد به راحتی مفهوم کدهای نوشته شده را درک کنند.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

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

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

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

چند الگو وجود دارد؟

هیچ عدد مشخصی برای تعداد الگوها وجود ندارد. چرا که این الگو ها در طول زمان تکامل یافته و توسط سازندگان نرم افزار ها مورد استفاده قرار گرفته و بررسی شدند. بررسی این الگوها توسط یک گروه چهار نفره منصوب به Gang Of Four انجام شد. علاوه بر این نگاهی بر اصول طراحی SOLID خواهیم داشت.
به طور خلاصه، با چند اصل اولیه طراحی نظیر: کد نویسی تمیز (clean coding)، loose coupling و طراحی modular و غیره، طراحی خود را آغاز کنید و چالش های طراحی را با مسائل شناخته شده و موجود در Design Patternها ارزیابی کنید. پس از آن، اگر به الگوی مناسبی رسیدید، ادامه دهید و در غیر اینصورت به همان طراحی خودتان اکتفا کنید. 
به عنوان آخرین نکته یادآور می شوم هرگز برنامه خود را مجبور به استفاده از Design Patternها نکنید و تنها زمانی که به آنها نیاز دارید به سراغ آنها بروید.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

Singleton

در این مقاله قصد داریم مهمترین بخش از Design Pattern به نام Singleton را توضیح دهیم.

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

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

 چه زمانی نیاز داریم که یک نمونه از کلاس ساخته شود؟

خیلی وقت ها نیاز است که فقط یک نمونه از یک کلاس ساخته شود. مثلاً وقتی که نمی خواهیم وضعیت شی تغییر کند و یا می خواهیم class را به صورت stateless نگه داریم.
به عنوان مثال زمانی که می خواهید یکسری داده های master را یکجا بارگذاری کنید و اجازه دهید مصرف کنندگان داده به جای فراخوانی های متعدد، با ساخت یک نمونه از کلاس، یک فراخوانی به یک کلاس Singleton داشته باشند.
در حالت کلی، در هر برنامه Enterprise پیچیده، می توان به کلاس های Repository و لایه Data Access به صورت Singleton نگاه کرد. درحالیکه معمولاً نمی خواهیم وضعیت در این لایه ها حفظ شود.
از جمله مثال های دیگر می توان به بحث log گیری، تنظیمات (configuration)، Caching و غیره اشاره کرد که می توان آن ها را به صورت Singleton پیاده سازی کرد. چرا که نیاز به یک نقطه مرکزی و سراسری خواهیم داشت تا به این کلاس ها دسترسی داشته باشیم.
گذشته از توضیحات فوق، دیده شده است که برخی از برنامه نویسان بی تجربه یکسری نمونه های اضافی می سازند که نه نتها باعث سربار حافظه می شوند، بلکه کارایی برنامه را تحت تاثیر قرار می دهند.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

چرا کلاس های static

به دلایل مختلفی نباید از کلاس های static استفاده کنیم. برخی از این دلایل عبارتند از:

 

 موارد مختلفی هست هست که می خواهید Interface ها را در یک کلاس پیاده سازی کنید (برای مثال پیاده سازی IOC- بعداً به توضیح IOC خواهم پرداخت) و به جای پیاده سازی کلاس به صورت static، آن را به صورت Singleton پیاده سازی می کنیم.

 در صورت نیاز، می توانید از یک کلاس singleton به صورت پارامتر یک متد استفاده کنید درحالیکه نمی توان این کار را با کلاس static انجام داد.

به اشتراک گذاری این ارسال


لینک به ارسال
به اشتراک گذاری در سایت های دیگر

برای ارسال دیدگاه یک حساب کاربری ایجاد کنید یا وارد حساب خود شوید

برای اینکه بتوانید دیدگاهی ارسال کنید نیاز دارید که کاربر سایت شوید

ایجاد یک حساب کاربری

برای حساب کاربری جدید در سایت ما ثبت نام کنید. عضویت خیلی ساده است !

ثبت نام یک حساب کاربری جدید

ورود به حساب کاربری

دارای حساب کاربری هستید؟ از اینجا وارد شوید

ورود به حساب کاربری


  • مطالب مشابه

    • توسط  Moeein Seven
      CPL ( زبان برنامه نویسی ترکیب شده Combined Programming Language و قبل تر از آن تحت عنوان زبان برنامه نویسی کمبریج ) یک زبان برنامه نویسی چند مدلی[۱] (multi-paradigm) می باشد ، که در اوایل سال ۱۹۶۰ توسعه یافت.
    • توسط  Moeein Seven
      کلدفیوژن (ColdFusion) یک برنامهٔ خادم تجاری مبتنی بر روش‌های سریع توسعه نرم‌افزار (به انگلیسی: RAD) است که در سال ۱۹۹۵ توسط جرمی و جی‌جی آلایر ابداع شد. مهم‌ترین قابلیت کلدفیوژن این‌است که می‌تواند ارتباطی آسان بین صفحات وب (HTML) و بانک اطلاعاتی ایجاد کند.
      در اصل این زبان برای اتصال صفحات اچ‌تی‌ام‌ال ساده به پایگاه داده طراحی شده بود ولی در نسخه ۲ با اضافه کردن یک IDE و زبان اسکریپت نویسی، تبدیل به یک پلتفرم کامل شد. نسخه‌های کنونی که توسط ادوبی منتشر می‌شوند در برگیرنده ویژگی‌های سازمانی و توسعه برنامه کاربردی اینترنت غنی می‌باشند.
    • توسط  Moeein Seven
      زبان برنامه‌نویسی کوبول (تلفظ: کوبول) یکی از قدیمی‌ترین زبان‌های برنامه‌نویسی است. نام کوبول که مخفف کلمهٔ COmmon Business-Oriented Language است، حوزهٔ اصلی کار خود را در زمینه تجارت، امور مالی و سیستم‌های اجرایی برای شرکت‌ها و دولت‌ها قرار داد. کوبول استاندارد ۲۰۰۲، از برنامه‌نویسی شیءگرا و ویژگی‌های دیگر زبان‌های مدرن حمایت می‌کند
    • توسط  Moeein Seven
      CMS-2 یک زبان برنامه‌نویسی سیستم‌های جاسازی شده است که به وسیلهٔ نیروی دریایی ایالات متحده استفاده شده است. آن اوایل تلاش به منظور توسعه یک زبان برنامه‌نویسی کامپیوتری سطح بالای استاندارد شده برای بهبود کد قابل حمل و استفاده مجدد انجام می‌شد. CMS-2 درجه اول برای سیستم‌های داده‌های تاکتیکی نیروی دریایی ایالات متحده توسعه یافت. (NTDS).[۱]
      CMS-2 توسط شرکت رند در اوایل دهه ۱۹۷۰ توسعه داده شد و مخفف "سیستم نظارت کامپایلر" است. بعد از نام "CMS-2" یک حرف قرار می‌گیرد که تعیین کنندهٔ نوع سیستم هدف است. برای مثال CMS_2M پردازنده‌های ۱۶ بیتی نیروی دریایی را هدف قرار می‌دهد، مانند /AYK-14
  • کاربران آنلاین در این صفحه   0 کاربر

    هیچ کاربر عضوی،در حال مشاهده این صفحه نیست.

×