প্রোগ্রামিংয়ে নকশার ধরণগুলি কীভাবে গুরুত্বপূর্ণ?


19

আমি একজন বিশ্ববিদ্যালয়ের ছাত্র এবং আমি সবেমাত্র নকশার ধরণগুলি সম্পর্কে শিখতে শুরু করেছি এবং তাদের উদ্দেশ্যগুলি বুঝতে আমি লড়াই করছি। আমি সেগুলি নিয়ে গবেষণার চেষ্টা করেছি তবে আমি যে সমস্ত সংস্থান পেয়েছি সেগুলি তাদের সম্পর্কে একাডেমিকভাবে, পেশাদার নয়, উপায়ে কথা বলে মনে হয়েছে।

তাদের উদ্দেশ্য কী এবং সেগুলি শেখা গুরুত্বপূর্ণ?


7
চাকরির সাক্ষাত্কারের জন্য তারা জেনে রাখা ভাল!
wim

5
একটি ডিজাইনের প্যাটার্ন হ'ল একটি নামযুক্ত, যা সমস্যা সমাধানের সাধারণভাবে পুনরাবৃত্তি। সাধারণত এগুলি ভাষার ঘাটতি থেকে উদ্ভূত হয়।
জন পুরে

7
নকশা নিদর্শনগুলির উদ্দেশ্য বোঝার জন্য তারা যে সমস্যার সমাধান করে তা বোঝা দরকার। এই সমস্যাগুলি বোঝার জন্য কঠোর উপায়ে এটি করার অভিজ্ঞতা প্রয়োজন :)
ম্যাটড্যাভি

উত্তর:


36

আপনার অভিপ্রায়টি খুব দ্রুত যোগাযোগের জন্য ডিজাইনের নিদর্শনগুলি দুর্দান্ত- সকলেই জানেন কারখানাটি কী।

সত্যিকারের, সত্যই, আসলে খুব খারাপ কাজটি হ'ল আপনার কোডটি নিদর্শনগুলির সাথে ফিট করার চেষ্টা করা বা নিদর্শন অনুসারে পৃথক দায়িত্ব বা অন্য কিছু। এটা এক জিনিস বলতে "এই বস্তু আছে হয় একটি কারখানা" এবং অন্য বলতে "এই বস্তুর একচেটিয়াভাবে একটি কারখানা হওয়া উচিত"।


1
সুতরাং আপনি সমস্ত নিদর্শন জন্য কিন্তু তারা আপনার কোড জন্য সত্য নয়। হ্যাঁ তারা ধারণাগুলি যোগাযোগের ক্ষেত্রে ভাল তবে আপনি প্রকৃত কোডটিতে প্যাটার্নটি দেখতে পারলে এগুলি আরও ভাল হয়।
নিউটোপিয়ান

3
ডাউন-ভোট কেন? এটি আসলে সেরা উত্তর আইএমএইচও। কোডিং সাধারণ জ্ঞান, এবং কখনও কখনও আপনি দ্রুত এমন একটি নিদর্শন ব্যবহার করতে পারেন যা সমস্যা সমাধানের জন্য উপযুক্ত fit কিন্তু একবার লোকেরা তাদের সর্বত্র গালি দেওয়া শুরু করলে, এটি একটি জগাখিচুড়ি হয়ে যায় hell
কোডার

1
প্রতিটি কোডে কিছু না কিছু প্যাটার্ন থাকে যদিও আপনি এটি সম্পর্কে অবগত নন। আপনি যে ডিজাইন প্যাটার্নগুলির বিষয়ে কথা বলছেন তা কেবল পুনরায় গোষ্ঠীভুক্ত করুন এবং বহুল ব্যবহৃত এবং দরকারী নিদর্শনগুলির একটি সেটটির নাম দিন। আপনি যখন এগুলি জানেন, আপনি তাদের সম্পর্কে আরও সচেতনভাবে চিন্তা করতে পারেন। আপনি যদি আপনার ক্লাসগুলির একটির "কন্ট্রোলডিস্পেনসর" কল করেন তবে সম্ভবত এটির কী করার কথা তা কেউ জানতে পারবে না। তবে, যদি আপনি কারখানার প্যাটার্নটি জানেন তবে আপনি এটিকে "কন্ট্রোলফ্যাক্টরি" বলবেন এবং অন্যরা তাৎক্ষণিকভাবে বুঝতে পারবেন।
অলিভিয়ার জ্যাকট-ডেসকোম্বেস

4
যদি এটি অন্য উদ্দেশ্যে কাজ করে তবে তা অন্য শ্রেণি হওয়া উচিত ... উদ্বেগের পৃথকীকরণ।
Nate

2
@ নেট: একটি উদ্দেশ্য বিভিন্ন ধরণের হতে পারে। কোনও শ্রেণীর কেবল একটি প্যাটার্ন জড়িত হওয়ার কোনও কারণ নেই। নিদর্শনগুলি "পারমাণবিক" দায়িত্ব নয়। একটি একক দায়িত্বের জন্য বিভিন্ন ধরণের প্রয়োজন হতে পারে।
ডেড জিএম

26

ডিজাইন প্যাটার্নসের উইকিপিডিয়া নিবন্ধ থেকে :

নিদর্শনগুলির কথা বলার উপযোগিতা হ'ল ডিজাইনাররা ইতিমধ্যে এবং যে পরিস্থিতিগুলি ইতিমধ্যে দেখেছেন সেগুলি নিয়ে আলোচনার জন্য একটি সাধারণ পরিভাষা।

সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে খুব দীর্ঘকাল ধরে আমাদের একটি গুরুতর সমস্যা রয়েছে: আপনি কোনও প্রকল্পে একজন নতুনকে নিয়োগ করেন এবং তারা প্রোগ্রামিংয়ের ভাষা যেভাবেই ভাল জানেন না কেন, আপনার বিষয়গুলিতে কীভাবে কাজ করা হয় তা খতিয়ে দেখতে তাদের কয়েক মাস সময় লাগে your তারা উত্পাদনশীল হতে পারে আগে প্রকল্প। হার্ডওয়্যার ইঞ্জিনিয়ারিংয়ে, তারা এই সমস্যাটি অনেক আগেই সমাধান করেছেন: তাদের 'স্কিম্যাটিক ডায়াগ্রাম' নামে একটি সাধারণ পরিভাষা রয়েছে। আপনি একটি হার্ডওয়্যার ইঞ্জিনিয়ার নিয়োগ করেন, সকালে আপনার হার্ডওয়্যার প্রকল্পের স্কিম্যাটিক্স দিন, তাদের সেগুলি অধ্যয়ন করুন এবং সন্ধ্যার পরে এটি কল করার কোনও দিন হওয়ার আগে তারা সোল্ডারিং বন্দুকটি বেছে নিয়ে উত্পাদনশীল হয়ে উঠতে পারে। আমরা আরও উন্নত হওয়ার উপায় নিয়ে আসতে চেষ্টা করেছি; প্রোগ্রামিং ভাষার মানিককরণ ছিল এক উপায়; স্ট্যান্ডার্ড লাইব্রেরি (আজকাল শ্রেণীর পাঠাগার) অন্যভাবে হয়েছে; তবে সবচেয়ে গুরুত্বপূর্ণ উপায়গুলির মধ্যে একটি সম্ভবত নকশার নিদর্শন ছিল। সুতরাং, তারা গুরুত্বপূর্ণ? আপনি বাজি!


3
বৈদ্যুতিন ইঞ্জিনিয়ারিংয়ের সাথে সফ্টওয়্যার বিকাশের তুলনা সাইকেলের সাথে শনি রকেটের তুলনায় প্রায় সঠিক। পরিবহণের উভয় পদ্ধতি (পয়েন্ট এ থেকে পয়েন্ট বিতে পৌঁছানো) তবে এটিকে পুরোপুরি পৃথক এবং নন-সামঞ্জস্যপূর্ণ উপায় হিসাবে নিয়ে যান।
জুন

3
@ জের হুমম, আপনার উপমাটি দরিদ্র। দু'জনেই ইঞ্জিনিয়ারিং শাখা। এমনকি যদি তাদের মিলগুলি সেখানেই শেষ হয়ে যায়, তবুও তারা সংজ্ঞা অনুসারে একটি প্রচুর পরিমাণে মিলবে। আমরা তাদের কখনই সমীকরণের আশা করি না, তবে একজনের কাছে অন্যের কাছ থেকে অনেক কিছু শেখার আছে।
মাইক নকিস

6
@Mike আছে: হয় একটি মৌলিক পার্থক্য: বৈদ্যুতিক সার্কিট কঠিন শারীরিক সীমা করে তোলে। সফটওয়্যার সিস্টেমগুলি মানুষের বুদ্ধির অস্পষ্ট সীমাবদ্ধতায় সীমাবদ্ধ।
কেভিন cline

3
প্রথমত, আমি বলিনি যে কোনও বড় পার্থক্য নেই। দ্বিতীয়ত, আপনার বক্তব্যও সঠিক নয়। সফ্টওয়্যার কঠোর প্রতিবন্ধকতাগুলি মানায়, সেগুলি কোনও ভাষার বাক্য গঠন দ্বারা নির্ধারিত হয়। এবং মানব বুদ্ধি ইলেকট্রনিক উপাদানগুলিকে আন্তঃসংযোগ করতে পারে এমন ক্রম সংখ্যাও সীমাহীন। তবে আবারও আমি দুজনের সমীকরণ করার চেষ্টা করছি না, এমনকি এমনও বলার চেষ্টা করছি না যে খুব ভয়ঙ্কর মিল রয়েছে। আমি কেবল বলছি যে একজনের কাছে অন্যের কাছ থেকে অনেক কিছু শেখার আছে
মাইক নকিস

3
সফ্টওয়্যার যেহেতু নকশাকালীন, তেমনি একটি বৈদ্যুতিক ইঞ্জিনিয়ারিং সাদৃশ্যটি একটি এমপ্লিফায়ার সার্কিটের "বর্তমান আয়না" এবং "নেতিবাচক প্রতিক্রিয়া" নিয়ে আলোচনা হবে। এগুলি কোনও স্কিম্যাটিকের বিযুক্ত উপাদান নয়, বরং বেশ কয়েকটি উপাদানগুলির একটি বিন্যাস যা একটি নির্দিষ্ট উদ্দেশ্য পূরণ করে। উপাদানগুলির উদ্দেশ্যগুলি না জেনে কীভাবে সংযোগ স্থাপন করবেন তা জেনে কোনও নতুন ব্যক্তিকে নতুন ডিজাইন তৈরি করতে দেওয়া হবে না। (যেমন এটি বোঝার এক ধাপ এগিয়ে))
rwong

9

নিদর্শনগুলির অস্তিত্বের জন্য দুটি ভিন্ন, যথেষ্ট কারণ রয়েছে।

প্রথমটি ইতিমধ্যে বেশ ভালভাবে ব্যাখ্যা করা হয়েছে: নিদর্শনগুলির ব্যবহার বিকাশকারীদের মধ্যে যোগাযোগকে লুব্রিকেট করে। যদি আপনি এবং আমি উভয়ই বুঝতে পারি যে আমি যখন 'পর্যবেক্ষক' বলি তখন আমি কোডের একটি খুব নির্দিষ্ট কাঠামোর কথা বলছি, তবে আমি খুব তাড়াতাড়ি বর্ণনা করতে পারি যে কোডটি কীভাবে এই প্যাটার্নটি ব্যবহার করে তা কীভাবে কাজ করে। বিকল্পটি হ'ল সমাধানটি সম্পূর্ণরূপে বর্ণনা করা, যা সময় সাশ্রয়ী এবং ত্রুটিযুক্ত। ("ঠিক আছে, আমি এই খাঁটি ভার্চুয়াল ক্লাসটি তৈরি করেছি যা গ্রাহক বস্তুর বর্ণনা ও ইন্টারফেস করে এবং তারপর আমি এমন একটি শ্রেণি তৈরি করেছি যা সক্রিয় গ্রাহকদের একটি তালিকা বজায় রাখে, যা ...")

নিদর্শনগুলির দ্বিতীয় সুবিধা হ'ল তারা সাধারণ সমস্যা-ফর্মগুলির জন্য অফ-দ্য শেল্ফ সমাধান-রূপগুলি। যদি আপনি আপনার নিদর্শনগুলি জানেন, এবং উদাহরণস্বরূপ, আপনি এমন কোনও সমস্যার মুখোমুখি হয়েছেন যেখানে ক্লাসগুলির মধ্যে অপ্রয়োজনীয় সংযোগের প্রবর্তন না করে (সম্ভবত একাধিক) প্রযোজক অবজেক্ট থেকে একাধিক গ্রাহক অবজেক্টের কাছে তথ্য পাওয়ার জন্য আপনাকে একটি ভাল উপায় খুঁজে বের করতে হবে, আপনি "এটিকে চিনতে পারবেন" একটি পর্যবেক্ষকের জন্য কাজ! " এবং আপনি তাত্ক্ষণিকভাবে বুঝতে পারবেন কীভাবে আপনার সমস্যার সমাধান করবেন।

এই সুবিধাগুলি সত্যই একে অপরকে শক্তিশালী করে। তারা আপনাকে সমস্যার কয়েকটি সাধারণ শ্রেণীর দ্রুত সমাধান করার অনুমতি দেয় এবং তারপরে আপনি যখন হয়ে যান, আপনি কীভাবে সমস্যার সমাধান করেছেন তা খুব তাড়াতাড়ি যোগাযোগ করতে পারেন।

এটি এমন একটি বিশ্বের সাথে বিপরীতে করুন যেখানে নিদর্শনগুলি "অস্তিত্ব নেই"। আপনি এই শ্রেণীর সমস্যাগুলির মধ্যে একটিতে দৌড়ান, যা সাধারণত তুচ্ছ নকশার সমস্যা নয় এবং আপনি একটি ভাল সমাধান নিয়ে আসার জন্য যথেষ্ট সময় ব্যয় করেন (যা ঘটনাক্রমে খুব সম্ভবত উপযুক্ত প্যাটার্নের মতো দেখাবে)। তারপরে, আপনার সহকর্মী এসে আপনি কীভাবে এটি সমাধান করেছেন তা জানতে চাইছেন এবং কীভাবে এবং কেন তা নিয়ে আপনি এক ঘন্টা ব্যয় করলেন।

এগুলি সমস্তই একটি ক্যাভিয়েটের সাথে যুক্ত যা একেবারে সুস্পষ্ট বলে মনে করা উচিত: সমস্যাগুলিকে উপযুক্ত নয় এমন প্যাটার্নগুলিতে জোর করার চেষ্টা করবেন না। যদি প্যাটার্নটি সমস্যার সাথে মানায় না, তবে সমাধানটি বিশৃঙ্খলাবদ্ধ হয়ে শেষ হবে এবং আপনি নিদর্শনগুলির প্রচেষ্টা হ্রাস সুবিধাটি হারাবেন। তদ্ব্যতীত, যেহেতু আপনার কাজটি আপনার সহকর্মীদের প্যাটার্নটির অর্থ বোঝার সাথে উপযুক্ত হবে না, তাই আপনি যোগাযোগের সুবিধার জন্য ব্যয় হারাবেন। আসলে, আপনি সম্ভবত নন-প্যাটার্নের ব্যয় ছাড়াই যোগাযোগের ব্যয় বাড়িয়ে তুলবেন, কারণ প্যাটার্নটির অপব্যবহার আপনার সহকর্মীদের সমাধানের একটি ভ্রান্ত ধারণা দেবে, যা মোটেও বোঝার চেয়ে খারাপ is


2
এটি একটি ভ্রান্ত ধারণা যে নকশার ধরণগুলি শেল্ফ সমাধানের বাইরে। তারা "PATTERNS" এটি সর্বদা কোডে অনুবাদ করে না।
মার্টিন ইয়র্ক

এরম, একটি প্যাটার্নটি সর্বদা কোডে অনুবাদ করে। এটি যথেষ্ট পরিমাণে দেওয়া। সমস্যাটি হ'ল তারা আপনার কোড বা আপনার যে আর্কিটেকচার বা আপনার অধীনে কাজ করছেন সেই সীমাবদ্ধতায় সর্বদা ফিট নাও হতে পারে। উদাহরণস্বরূপ যে কোনও প্যাটার্ন ফিট হতে পারে তার অর্থ এই নয় যে আপনি এটি ব্যবহার করতে পারেন। কেউ ধরে নিতে পারে আপনি যা বোঝাতে চেয়েছিলেন এটিই (তবে আমি অনুমান করা পছন্দ করি না)।
মার্ফ

5

নিদর্শনগুলি ধারণা এবং ধারণাগুলির পুনরায় ব্যবহার সম্পর্কে এবং এর যোগাযোগের জন্য একটি সাধারণ / ধারাবাহিক প্ল্যাটফর্ম স্থাপন সম্পর্কে।

আমরা সকলেই একমত (!) যে তত্ত্বের ক্ষেত্রে কোড-পুনঃব্যবহার একটি ভাল জিনিস - তবে এটি ব্যবহারিকভাবে করা আমাদের চেয়ে কঠিন হতে প্রমাণিত হয়েছে (কিছু ক্ষেত্রে এটি পরিবর্তন হচ্ছে, তবে এটি সর্বদা একটি চ্যালেঞ্জ হবে )। কিন্তু বাস্তবে আমরা যা ব্যবহার করতে চাই তার অনেকগুলি বিষয়গুলি করার একটি উপায়, কোনও নির্দিষ্ট সমস্যার সমাধানের জন্য এক ধরণের টেম্পলেট ব্যবহার করা - এগুলি হ'ল প্যাটার্নস। সুতরাং আপনি এমন একটি ক্ষেত্রে যান যেখানে আপনি বলে থাকেন যে এক্স সমস্যা সমাধানের জন্য একটি ভাল পদ্ধতি হ'ল প্যাটার্ন ওয়াই ব্যবহার করা এবং আমরা জানি যে প্যাটার্ন ওয়াইয়ের উপাদানগুলি একটি, বি এবং সি এবং আমরা যাচ্ছি। কারণ নিদর্শনগুলি ব্যাপকভাবে বোঝা যাচ্ছে আপনাকে যোগাযোগের উপকারটি গভীরতার সাথে ব্যাখ্যা করতে হবে না।

নিদর্শনগুলির জন্য মজাদার বিষয়টি হ'ল ভাষা এবং ফ্রেমওয়ার্কগুলি সাধারণ নিদর্শনগুলির জন্য আরও ভাল সমর্থন সরবরাহ করতে বিকশিত হচ্ছে যা নেট এফেক্টের সাথে আমরা আরও এবং আরও ভাল কোড পুনরায় ব্যবহার করতে পারি (আরও এবং আরও ভাল লেগো ইট!) কারণ আমরা যেভাবে অ্যাপ্লিকেশন তৈরি করি (নিদর্শনগুলি প্রয়োগ করে) ) পুনরায় ব্যবহারের সুবিধা দেয়।


4

নকশার নিদর্শনগুলি কেবল ইটগুলিই জানা যায় যে কোনও সফ্টওয়্যার সমাধান নির্মিত হয়। নিম্নলিখিত কারণগুলির কারণে এগুলি গুরুত্বপূর্ণ:

  1. তারা ভাষা অজ্ঞানী। প্রদত্ত সমস্যা / আর্কিটেকচার / কার্যের জন্য কোন ডিজাইনের প্যাটার্নটি উপযুক্ত তা আপনি একবারে বুঝতে পারেন যে কোনও বহুমাত্রিক ভাষায় আপনি এটি প্রয়োগ করতে পারেন - আসুন সি #, জাভা বা পাইথন হোন - বেশিরভাগ ক্ষেত্রে সমাধানটি একই রকম হবে, আপনার ঠিক আছে সিনট্যাক্স মানিয়ে নিতে। এর অর্থ হ'ল আপনি যখনই একই সমস্যা ডোমেনের (এবং এমনকি ডোমেন জুড়েও) থাকেন ততক্ষণ আপনি নিজের অভিজ্ঞতা প্রোগ্রামিং থেকে অন্য ভাষায় অন্য ভাষায় স্থানান্তর করতে পারেন।

  2. ডিজাইনের নিদর্শনগুলি প্রোগ্রামিং দৃষ্টান্তের সাথে বাধ্যতামূলক রয়েছে তা সত্ত্বেও , যার অর্থ অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের নকশা নকশা (সর্বাধিক বিখ্যাত, "গ্যাং অফ ফোর" নিদর্শন হিসাবেও পরিচিত )। প্যাটার্নগুলি আপনাকে যে দৃষ্টান্তটি সবচেয়ে ভাল তা বোঝার অনুমতি দেয় এবং আপনাকে কেবল সিনট্যাক্সের বাইরে যেতে সহায়তা করে।উদাহরণস্বরূপ আমি সি # এবং জাভাতে প্রচুর বাস্তবায়ন দেখেছি যেখানে লোকেরা কেবল বেসিক বা ফোর্টরান এ তারা যেভাবে প্রোগ্রাম করেছিল - সমস্যা সমাধানের জন্য তাদের একটি নিখুঁত আবশ্যক মন আছে এবং তারা এই সমাধানটি রেন্ডার জন্য ওওপি ব্যবহার করে - কোন উত্তরাধিকার নেই , কোনও পলিমারফিজম নেই, সমস্ত পদ্ধতিই সর্বজনীন Design নকশা নকশাগুলি আপনাকে এই ধারণাগুলির পিছনে তাকাতে এবং বাস্তব জীবনে কীভাবে কাজ করে তা দেখতে সহায়তা করে। ফাংশনাল প্রোগ্রামিংয়ের মতো অন্যান্য দৃষ্টান্তগুলিতে নকশার প্যাটার্নে একই প্রয়োগ হয়।

  3. প্যাটার্নগুলি সাধারণত ধারণাগুলি উপস্থাপনের একটি সহজ উপায় এবং আর্কিটেকচার থেকে কম্পিউটার সায়েন্সে এসেছিল। কোনও নির্দিষ্ট "প্যাটার্ন" এর পিছনে ধারণাটি বুঝতে পারলে আপনি সহজেই অন্য কোনও সমস্যায় এই প্যাটার্নটি সনাক্ত করতে পারেন এবং এই প্যাটার্নটি ব্যবহার করে সমাধান করতে পারেন (সম্ভবত আপনার সমস্যার সমাধানের জন্য কিছুটা সংশোধন করা হয়েছে)। বিভিন্ন ধরণের নিদর্শন রয়েছে: এন্টারপ্রাইজ সফ্টওয়্যার ইন্টিগ্রেশন , সোর্স কোড টেস্টিং ইত্যাদিতে কম্পিউটার কম্পিউটার বিজ্ঞানের জন্য বইগুলিতে কেবল নিদর্শনগুলি দেখুন।

  4. নিদর্শন শেখার মাধ্যমে ভাল অভ্যাসগুলি অর্জন করা বাদ দিয়ে আপনি সহজেই অ্যান্টি-প্যাটার্নগুলি অধ্যয়ন করে কীভাবে আপনার কোডের নির্বিকার ভুলগুলি এড়াতে পারবেন তা শিখতে পারেন । অ্যান্টি-প্যাটার্ন আকারে বিভিন্ন ডোমেনে সাধারণ ভুলগুলির বৈশিষ্ট্যযুক্ত প্রচুর বই রয়েছে যা খুব বিনোদনমূলক এবং একই সাথে শিক্ষামূলক। আমি এই অ্যান্টি-প্যাটার্নগুলির নামগুলি ভালোবাসি, যাইহোক!


2

আপনি এবং অন্যান্য বিকাশকারীরা বুঝতে পারছেন এমন কোনও সমস্যার সমাধানের প্রমাণিত উপায় হিসাবে আপনি কোনও প্যাটার্নটিকে ভাবতে পারেন। উদাহরণস্বরূপ, সমস্যাটি হ'ল ডেটার একটি বাছাই করা তালিকা তৈরি করা, তারপরে আপনি একটি লিঙ্কযুক্ত তালিকা ব্যবহার করতে বা কোনও ভেক্টরে ডেটা রেখে বাছাই করতে পারেন। আপনি সম্ভবত এই দুটি অপশনই বুঝতে পারবেন কারণ আপনি ইতিমধ্যে লিঙ্কযুক্ত তালিকার প্যাটার্ন বা লোড অ্যান্ড সারণি ভেক্টর প্যাটার্নটি জানেন। আপনি প্রত্যেকের উপকারিতা এবং বিধিগুলি জানেন এবং কি চলছে তা বোঝার জন্য বাস্তবায়নটি দেখার প্রয়োজন হবে না।


1

আমি মনে করি আপনি প্রোগ্রামিংয়ের জন্য স্টার্টার, আমি আপনাকে নকশার প্যাটার্নটি শিখার পরামর্শ দিই না। সফ্টওয়্যার বিকাশের অভিজ্ঞতার ভিত্তিতে ডিজাইন প্যাটার্ন শেখা এবং বোঝা দরকার। আপনার কোডে আরও অনুশীলন করা উচিত এবং কোন কোড শৈলীটি খারাপ এবং তারপরে ডিজাইনের উন্নতির জন্য নকশার প্যাটার্ন শিখতে হবে।


1

ডিজাইনের প্যাটার্নের একটি দরকারীতা নির্ভর করে আপনি কোন ভাষাটি চয়ন করেন। আপনি যত বেশি শক্তিশালী ভাষা বেছে নিন তার জন্য আপনাকে ডিজাইন প্যাটারগুলি বুঝতে এবং প্রয়োগ করতে হবে। ডিজাইনের ধরণটি এমন সিগন্যাল হতে পারে যা আপনার ভাষা চুষতে পারে একটি অন্তর্নির্মিত বৈশিষ্ট্যটি অনুপস্থিত।

জো গ্রেগরিও পাইথনে ডিজাইনের ধরণগুলির অভাব সম্পর্কে দুর্দান্ত আলোচনা করেছিলেন


পাইথনে ডিজাইনের ধরণগুলির অভাব সম্পর্কে লিঙ্কটির জন্য ধন্যবাদ। সম্পাদনা: উফ !! ভিডিওটি সেই অবস্থান থেকে সরানো হয়েছে !! :(
সৌরভ পাতিল

0

ডিজাইন নিদর্শনগুলি সফ্টওয়্যার বিকাশে সাধারণ সম্মুখীন সমস্যার সমাধান। কিছু সমস্যার সর্বদা একাধিক সমাধান থাকে এবং নকশার নিদর্শনগুলি আপনাকে এই সাধারণ সমস্যাগুলির জন্য ভাল সমাধানের সেট সরবরাহ করে কোন সমাধানটি সেরা তা সিদ্ধান্ত নিতে সহায়তা করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.