আলগাভাবে যুগল নকশাগুলি তৈরি করতে আমার কতটা প্রচেষ্টা বিনিয়োগ করা উচিত?

Question

আমি বর্তমানে নকশা নিদর্শন সম্পর্কে শিখছি।

আমি মনে করি বেশিরভাগ লোকেরা সম্মত হবেন যে এই নিদর্শনগুলি দুর্দান্ত সরঞ্জাম, তবে সবকিছুর উত্তর হিসাবে নয় বরং সংযমের সাথে ব্যবহার করা উচিত। এগুলিকে বেশি ব্যবহার করা অল্প সুবিধা দিয়ে অ্যাপ্লিকেশনকে অতিরিক্ত জটিল করে তুলবে। প্যাটার্নগুলি কেবল তখনই ব্যবহার করা উচিত যেখানে সেগুলি সেরা সমাধান হতে পারে বা একটি ভাল সমাধান তৈরি করতে সহায়তা করে (আপনি কি সম্মত হন?)

এটি মাথায় রেখে:

আমি যে বইটি পড়ছি (হেড ফার্স্ট ডিজাইন প্যাটার্নস) প্রায়শই আলগা দম্পতির গুরুত্বের উপর জোর দেয় । এই আলগা দম্পতিটি 'ইন্টারফেসের কাছে প্রোগ্রাম, বাস্তবায়ন নয়' এবং 'কী পরিবর্তিত হয় তা encapsulate' এর মতো নীতিগুলি অনুসরণ করে প্রাপ্ত হয়।

মূলত, আমি এখনও অবধি শিখেছি বেশিরভাগ নিদর্শনগুলি বেশিরভাগ ক্ষেত্রেই ডিজাইনগুলি আলগাভাবে মিশ্রিত করার অনুমতি দেয় এবং এইভাবে আরও নমনীয় হয়।

আমি আলগা সংযোগের গুরুত্ব এবং উপকারিতা বুঝতে পারি।

তবে আমার প্রশ্ন হ'ল আলগাভাবে মিলিত, নমনীয় নকশাগুলি তৈরি করতে একজনের কতটা প্রচেষ্টা বিনিয়োগ করা উচিত?

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

আমি যা জানতে চাই, কেবলমাত্র আমার অ্যাপ্লিকেশনটিকে ওও নীতিগুলি যেমন looseিলে coupালা মিলন, ইন্টারফেসে প্রোগ্রামমাইন ইত্যাদি অনুসরণ করার অনুমতি দেওয়ার জন্য আমার অতিরিক্ত স্তরের বিমূর্ততা এবং নকশাগুলি তৈরি করতে আসলে কতটা প্রচেষ্টা করা উচিত তা কি আসলেই মূল্যবান? এটা? এতে আমার কতটা চেষ্টা করা উচিত?

Comments

কিছু লোক এটির জন্য পুরো জীবন জুড়ে দেয়, উদাহরণস্বরূপ কেন্ট বেক, যারা এর প্রশংসা করেন তারা আপনার প্রচেষ্টা দেখতে পাবেন।

— নিং

Answer 1

জঘন্য উত্তর: আপনি এটি যত বেশি করবেন, তত কম প্রচেষ্টা।

মূলত, আলগাভাবে সংযুক্ত কোড তৈরি করা খুব শক্ত নয় isn't অন্যদিকে, শিথিল দম্পতির বিবেচনায় আপনার মনকে প্রশিক্ষণ দেওয়া। এবং, ভাল, আমি এটি সম্পূর্ণরূপে মূল্যবান বলে বিশ্বাস করি।

ধরুন আপনি এমন একটি চাকরি নেন যা সফটওয়্যার বিকাশের ক্ষেত্রে পুনরাবৃত্তি পদ্ধতির ব্যবহার করে, যেমনটি গত 20 বছরের বেশিরভাগের দ্বারা সুপারিশ করা হয়েছে। আপনি এমন কিছু নির্মাণ করেন যা পুনরাবৃত্তিতে সুন্দরভাবে কাজ করে। 1 পুনরাবৃত্তির 2 তে আপনি এটির উপরে তৈরি করেন, কিছু নতুন বৈশিষ্ট্য যুক্ত করেন এবং কিছু যখন আপনার পুনরাবৃত্তির সাথে খাপ খায় না তখন কিছু একসাথে কিছুটা বাঁকানো যখন জিনিসগুলি কীভাবে কাজ করা উচিত সে সম্পর্কে 1 ধারণা । এখন পুনরাবৃত্তি 3 আসে, এবং আপনি প্রয়োজনীয়তাগুলি আপনার প্রাথমিক আর্কিটেকচারটি পুনর্বিবেচনা করার জন্য প্রয়োজনীয়তাগুলি সন্ধান করে। আপনি কীভাবে আপনার কোডটি ছিঁড়ে ফেলবেন এবং স্কয়ার একটিতে না গিয়ে এটিকে পুনর্নির্মাণ করবেন?

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

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

Answer 2

প্রয়োজনীয় পরিশ্রমের পরিমাণ আপনাকে সর্বদা যথেষ্ট বলে দেয় না; আমি মনে করি আরও ভাল ব্যবস্থা হ'ল পরিশোধের অনুপাতের প্রচেষ্টা। তবে পেওফটি কী হতে পারে তা নির্ধারণ করা সর্বদা সোজা এবং ত্রুটিমুক্ত নয়।

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

একটি জিনিস রয়েছে যা আপনার সর্বদা করা উচিত (বা এটির কাছে যতটুকু আপনি পেতে পারেন): আপনার সফ্টওয়্যারটির পৃথক উপাদানগুলি (ওওপির পক্ষে অবজেক্টস, ক্রিয়ামূলক বা প্রক্রিয়াজাতকরণের প্রোগ্রামিংয়ের জন্য কাজগুলি) কালো বাক্সে পরিণত করা। একটি কালো বাক্স এমন একটি জিনিস যার অভ্যন্তরস্থতা (বাস্তবায়ন) আমরা জানি না বা যত্ন করি না।

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

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

নকশার নকশাগুলির প্রতি আপত্তিগুলির মধ্যে একটি হ'ল তারা 'স্পষ্টত' বা 'তাদের নাম শোনার আগে আমি তাদের ব্যবহার করছিলাম, কেবল নামেই নয়'। লোকেরা যে আপত্তি জানাতে পারে বা নকশার নিদর্শনগুলির প্রবর্তকরা তাদের সাথে প্রথমে উপস্থিত হতে পারে, তা হ'ল তারা তাদের পিছনের নীতিগুলি বোঝে।

ব্ল্যাক বাক্সগুলি ব্যবহার করে আপনার কোডগুলি বুদ্ধিমান পদ্ধতিতে সংগঠিত করে এবং এগুলির সাধারণত সাধারণত কোনও দাম হয় না (যদি কিছু থাকে); এগুলি সর্বত্র ব্যবহার করুন। ডিজাইনের প্যাটার্ন বা অন্য কোনও কৌশল ব্যবহার করে যা বিমূর্ততার একটি স্তর যুক্ত করে বা জিনিসগুলিকে জটিল করে তোলে তার একটি ব্যয় রয়েছে; এগুলি কখনই কেবল সুন্দর বা ঝরঝরে বা চালাক হিসাবে ব্যবহার করবেন না; সমস্যাটি মাপসই হলে এগুলি ব্যবহার করুন এবং সুবিধাটি পাওয়ার জন্য ব্যয়টি মূল্য দিতে হবে।

Answer 3

আপনার প্রশ্নটি নকশার প্যাটার্নগুলির সাথে আলগা সংযোগের সমতুল্য বলে মনে হচ্ছে, তবে এগুলি সত্যই পৃথক, তবে সম্পর্কিত জিনিস।

লুজ কাপলিং প্রোগ্রামিংয়ের মৌলিক উদ্বেগ। যতক্ষণ না আমরা মেশিন কোড থেকে এবং প্রতীকী ভাষাগুলিতে সরে এসেছি, প্রোগ্রামগুলি কার্যকরভাবে তাদের সম্পাদনের সাথে মিশ্রিত হয়ে উঠল। প্রভৃতি

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

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

(এখন এবং তার পরে আমি এমন কারও সাথে কাজ করি যিনি ভবিষ্যতের বিকাশকারীদের নির্দিষ্ট কাঠামোর নিদর্শনগুলিতে স্থির রেফারেন্স এম্বেড করে তাদের উদ্দেশ্যে - উদ্দেশ্য হিসাবে নকশার পছন্দগুলি তৈরি করা থেকে বিরত রাখতে চান wants তবে এটি সত্যই ব্যতিক্রম Most বেশিরভাগ নকশাটি মড্যুলারটির জন্য জিনিসগুলি ভাঙ্গার আশেপাশে ঘোরে) এবং প্রচুর প্রসঙ্গে পুনরায় ব্যবহার করুন))

Answer 4

প্যাটার্নগুলি কেবল তখনই ব্যবহার করা উচিত যেখানে সেগুলি সেরা সমাধান হতে পারে বা একটি ভাল সমাধান তৈরি করতে সহায়তা করে (আপনি কি সম্মত হন?)

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

আলগাভাবে মিলিত, নমনীয় নকশাগুলি তৈরিতে একজনের কতটা প্রচেষ্টা বিনিয়োগ করা উচিত?

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

বিধিগুলির মধ্যে (সম্পূর্ণ তালিকা নয়):

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

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

উদাহরণস্বরূপ, জাভাতে, আপনার ইন্টারফেসটিকে একটি হিসাবে সংজ্ঞায়িত করা এবং সেটিতে interfaceক্লায়েন্ট কোড লিখতে ভাল অনুশীলন হয় (তারপরে, একটি বাস্তবায়ন শ্রেণীর সাথে ইন্টারফেসটি ইনস্ট্যান্ট করুন)।

অন্যদিকে সি ++ এ আপনার ইন্টারফেস নেই, সুতরাং আপনি কেবল একটি বিমূর্ত বেস শ্রেণি হিসাবে ইন্টারফেসটি লিখতে পারেন; যেহেতু সি ++ তে আপনি কেবল উত্তরাধিকার ব্যবহার করেন যখন আপনার জন্য এটির দৃ strong় প্রয়োজন হয় (এবং এটি অপ্রয়োজনীয় ভার্চুয়াল ফাংশনগুলির ওভারহেড এড়ানো হয়), আপনি সম্ভবত ইন্টারফেসটি পৃথকভাবে ব্যাখ্যা করবেন না, কেবল শ্রেণির শিরোনাম)।

যারা নকশার নিদর্শনগুলির বিরোধিতা করেন তারা বলে যে এই নিদর্শনগুলি ব্যবহার করতে ব্যয় করা প্রায়শই সুবিধার চেয়ে বেশি।

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

আপনি পরিবর্তনগুলি প্রচুর করতে একটি নকশা প্যাটার্ন বাস্তবায়ন থাকে, তবে আপনার সমস্যা না নকশা প্যাটার্ন - এটা আপনার কোড একশিলা হচ্ছে বেস, এবং শক্তভাবে মিলিত হয়। এটি একটি খারাপ / suboptimal নকশা সমস্যা, নকশা নিদর্শন সমস্যা নয়।

আমি যা জানতে চাই, কেবলমাত্র আমার অ্যাপ্লিকেশনটিকে ওও নীতিগুলি যেমন looseিলে coupালা মিলন, ইন্টারফেসে প্রোগ্রামমাইন ইত্যাদি অনুসরণ করার অনুমতি দেওয়ার জন্য আমার অতিরিক্ত স্তরের বিমূর্ততা এবং নকশাগুলি তৈরি করতে আসলে কতটা প্রচেষ্টা করা উচিত তা কি আসলেই মূল্যবান? এটা? এতে আমার কতটা চেষ্টা করা উচিত?

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

আলগা সংযোগের সুবিধার মধ্যে রয়েছে:

• রিফ্যাক্টরিং এবং নমনীয়তা পুনরায় নকশা
• কম ব্যর্থ প্রচেষ্টা
• testability
• কোড পুনরায় ব্যবহার করার সম্ভাবনা বৃদ্ধি পেয়েছে
• নকশা সরলতা
• ডিবাগারে কম সময় ব্যয় করা

... এবং আরও কয়েকজন যা এখনই আমার মনে আসে না।