নিয়মিত পরিবর্তন প্রকল্পে ডিজাইন নিদর্শন ব্যবহার করা আমাদের এড়ানো উচিত?

Question

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

তিনি আমাকে একটি গল্প বলেছেন যা আমাকে এর মতো প্রকল্পগুলিতে নকশার ধরণগুলির যথাযথতা সম্পর্কে ভাবতে বাধ্য করে। গল্পটি এখানে।

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

কখনও কখনও, পণ্যগুলি থেকে তথ্য অনুপস্থিত ছিল: উদাহরণস্বরূপ, যখন পণ্যটি সবেমাত্র তৈরি করা হয়েছিল তখন তাদের একগুচ্ছের কোনও দাম ছিল না, তবে দামটি এখনও নির্দিষ্ট করা হয়নি। কারও কারও কাছে বিবরণ ছিল না (বিবরণটি একটি পরিবর্তনযোগ্য ইতিহাস, স্থানীয়করণ বিষয়বস্তু, ইত্যাদি সহ একটি জটিল অবজেক্ট)। কারও কারও চালানের তথ্য ছিল না।

ডিজাইনের ধরণ সম্পর্কে আমার সাম্প্রতিক পড়া দ্বারা অনুপ্রাণিত হয়ে আমি ভেবেছিলাম যে এটি যাদু নাল অবজেক্ট প্যাটার্নটি ব্যবহার করার একটি দুর্দান্ত সুযোগ । সুতরাং আমি এটি করেছি, এবং সবকিছু মসৃণ এবং পরিষ্কার ছিল। একজনকে কেবল product.Price.ToString("c")দামটি প্রদর্শন করতে, বা product.Description.Currentবর্ণনাটি দেখানোর জন্য কল করতে হয়েছিল; কোন শর্তসাপেক্ষ জিনিস প্রয়োজন। একদিন অবধি, স্টেকহোল্ডার nullজেএসওএন থাকাতে এটিকে এপিআইতে আলাদাভাবে প্রদর্শন করতে বলেছিল । এবং পৃথকভাবে "মূল্য অনির্দিষ্ট [পরিবর্তন]" দেখিয়ে সামগ্রী সামগ্রীগুলির জন্য। এবং আমাকে আমার প্রিয় নুল অবজেক্ট প্যাটার্নটি হত্যা করতে হয়েছিল, কারণ এর আর কোনও প্রয়োজন নেই।

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

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

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

এক্ষেত্রে কী সমাধান হবে?

• কোনও ডিজাইনের নিদর্শন ব্যবহার করছেন না, চিন্তাভাবনা বন্ধ করুন, এবং সরাসরি কোড লিখবেন?

  এমন একটি অভিজ্ঞতা করা আকর্ষণীয় হবে যেখানে কোনও দল সরাসরি কোড লিখছে, অন্য একজন টাইপ করার আগে দু'বার চিন্তা করছেন, কয়েক দিন পরে আসল নকশাটি ফেলে দেওয়ার ঝুঁকি নিয়ে: কে জানে, সম্ভবত উভয় দলেরই থাকতে হবে একই প্রযুক্তি debtণ এই জাতীয় ডেটার অভাবে, আমি কেবল দৃ .়ভাবেই বলব যে 20-মাস-প্রকল্পে কাজ করার আগে পূর্ব চিন্তা না করে কোড টাইপ করা ঠিক মনে হচ্ছে না ।

• ডিজাইনের প্যাটার্নটি রাখুন যা আর বোঝা যায় না এবং সদ্য নির্মিত পরিস্থিতির জন্য আরও নিদর্শন যুক্ত করার চেষ্টা করবেন?

  এটিও ঠিক মনে হয় না। কোডগুলি বোঝার সহজ করার জন্য প্যাটার্নগুলি ব্যবহার করা হয়; অত্যধিক নিদর্শনগুলি রাখুন, এবং কোডটি একটি গোলযোগে পরিণত হবে।

• একটি নতুন ডিজাইনের কথা ভাবতে শুরু করুন যা নতুন প্রয়োজনীয়তাগুলিকে ঘিরে রেখেছে, তারপরে আস্তে আস্তে পুরানো নকশাকে নতুন করে রিফ্যাক্টর করুন?

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

সুতরাং, কোন পরামর্শ?

Comments

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

— রবার্ট হার্ভে

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

— রবার্ট হার্ভে

আমি সন্দেহ করি যে নকশার নিদর্শনগুলি ছাড়াই কোডটি খুব তাড়াতাড়ি একটি অভাবনীয় অবস্থানে পৌঁছে যেত

— স্টিভেন এ লো।

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

— জেসন সি

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

— জেসন সি

Answer 1

আমি এই প্রশ্নে কিছু ভুল অনুমান দেখছি:

• নকশা নিদর্শন সহ কোড, যদিও সঠিকভাবে প্রয়োগ করা হয়েছে, সেই নিদর্শনগুলি ছাড়াই কোডের চেয়ে বেশি সময় প্রয়োজন।

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

• গ্রাহককে দোষারোপ করা হবে কারণ তার কোনও প্রযুক্তিগত পটভূমি নেই এবং সংহতি বা পণ্যটির সংযোজন সম্পর্কে যত্ন নেই

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

• দ্রুত পরিবর্তনের প্রয়োজনীয়তার সমাধানটি দ্রুত কোড পরিবর্তন করা

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

Comments

+1 - আপনি প্রযুক্তিগত সমাধান দিয়ে মানুষের সমস্যার সমাধান করতে পারবেন না।

— টেলাস্টিন

+1, তবে "বা কমপক্ষে আরও উন্নততর বিকাশযোগ্য (এর অর্থ: পরিবর্তনের প্রয়োজনীয়তার সাথে খাপ খাইয়ে নেওয়া সহজ)" - আমি যুক্তিসঙ্গতভাবে প্রয়োজনীয় প্রয়োজনীয়তার সাথে এই যোগ্যতা অর্জন করব , তাই না?

— ফুহরম্যানেটর

@ ফুহরম্যানেটর: আমি মনে করি সাধারণ পদে এটি আলোচনা করা কঠিন। আইএমএইচও এটি স্পষ্ট যে কোনও নকশার প্যাটার্ন আপনাকে সাহায্য করবে না যখন আপনার প্রথম প্রয়োজন "আমাদের একটি ওয়ার্ড প্রসেসর প্রয়োজন" এবং এটি "আমাদের একটি ফ্লাইট সিমুলেটর প্রয়োজন" তে পরিবর্তিত হয়। কম কঠোর প্রয়োজনের পরিবর্তনের জন্য এটি আপনার সফ্টওয়্যারকে বিকাশযোগ্য রাখতে কী সাহায্য করবে তা স্থির করা সর্বদা সহজ নয়। সবচেয়ে ভাল জিনিস হ'ল আইএমএইচও খুব বেশি নিদর্শন প্রয়োগ না করা, তবে কিছু নীতি - মূলত সলিড নীতি এবং ইয়াগনি I এবং আমি টেলাস্টিনের সাথে 100% এর সাথে সম্মত- যখন প্রয়োজনীয়তাগুলি প্রায়শই পরিবর্তিত হয়, এটি সম্ভবত কোনও প্রযুক্তিগত সমস্যা নয়।

— ডক ব্রাউন 16

+1 - "সত্যই, যদি 'অন্তর্নিহিত ইন্টারফেসগুলি তিন মাস ধরে প্রতিদিন দুবার পরিবর্তিত হয়', তবে সমাধানটি দিনে দুবার কোড পরিবর্তন করে প্রতিক্রিয়া দেখা উচিত নয় the প্রয়োজনীয় সমাধানগুলি কেন এত ঘন ঘন পরিবর্তিত হয় তা জিজ্ঞাসা করা এবং যদি প্রক্রিয়াটির সেই অংশে পরিবর্তন আনা সম্ভব "" যদি আপনাকে প্রতিনিয়ত নতুন দিকনির্দেশনা দেওয়া হয় তবে সমস্ত স্টেকহোল্ডারদের সাথে বসে প্রত্যাশা কী তা আবার নতুন করে জানানো ভাল। আপনার মতপার্থক্যগুলি কার্যকর করুন এবং আশা করি প্রকল্পটিকে আরও পরিষ্কার লক্ষ্য দিয়ে প্রত্যেকের সময় এবং অর্থ অপচয় করবেন না।

— ক্রিলগার

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

— ফুহরম্যানেটর

Answer 2

আমার নম্র মতামতটি হ'ল ডিজাইনের ধরণগুলি ব্যবহার করা আপনার এড়ানো বা না এড়ানো উচিত নয়।

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

আমি মনে করি সমস্যার মূলটি এটি হতে পারে যে আপনার বন্ধু "ডিজাইনের প্যাটার্ন প্রয়োগ বা প্রয়োগ না করার" ক্ষেত্রে বিবেচনা না করে "আমি যে সর্বোত্তম সমাধানটি ভাবতে পারি তার মধ্যে বিবেচনা না করে কেবল প্যাটার্নগুলিতে সীমাবদ্ধ নয় আমি জানি".

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

Comments

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

— জেসন সি

Answer 3

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

সুতরাং, যখন কোনও নকশার নকশাগুলি প্রয়োজনীয়তা পূরণ করে না, তখন আমরা কি বলি যে সমস্ত নকশার নিদর্শনগুলি সময়ের অপচয় বা আমরা কী বলি যে আমাদের আলাদা ডিজাইনের প্যাটার্ন দরকার?

Answer 4

এটি প্রদর্শিত হবে ভুলটি প্যাটার্নের জিনিসগুলি ব্যবহার করার চেয়ে অপসারণ করার চেয়ে বেশি ছিল। প্রাথমিক নকশায় নাল অবজেক্টটি কোনও সমস্যার সমাধান সরবরাহ করেছে বলে মনে হয়। এটি সেরা সমাধান নাও হতে পারে।

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

ফর্ম product.Price.toString মধ্যে চেইনিং রেফারেন্স ( 'গ') লঙ্ঘন Demeter আইন । আমি এই অনুশীলন সহ সমস্ত প্রকারের সমস্যা দেখেছি, যার মধ্যে অনেকগুলি নালীর সাথে সম্পর্কিত। Product.displayPrice ('c') এর মতো একটি পদ্ধতি অভ্যন্তরীণভাবে নালাগুলি পরিচালনা করতে পারে। অনুরূপভাবে product.Description.Current হ'ল product.displayDescript (), product.displayCurrentDescription () দ্বারা পরিচালনা করা যেতে পারে। বা product.diplay ('বর্তমান')।

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

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

Comments

এটি আরও নির্দেশ করতে পারে, আপনি যে ডেমিটার আইনটি "ভঙ্গ" করতে পারেন, যে পৃষ্ঠায় ব্যবহৃত মডেলটি উপযুক্ত ছিল না was কেন "ভিউ মডেল" (আলগা অর্থে ব্যবহৃত) কেবল বর্ণনার বর্ণনা রাখে না? (অর্থাত্ ইউআই স্তরে কেবলমাত্র বর্তমান ডেস্কের চেয়ে কেন আরও বেশি কিছু রয়েছে?) ব্যবসায়ের স্তরটি ইউআই স্তরটিতে যথাযথভাবে ভরাট বস্তু প্রস্তুত করতে পারে যা ইতিমধ্যে ম্যানেজার কিনা তা নির্ভর করে বিভিন্ন সামগ্রী রয়েছে content

— কর্নেলিয়াস

Answer 5

প্রশ্নটি এতগুলি পয়েন্টে ভুল বলে মনে হচ্ছে। তবে নিন্দনীয় বিষয়গুলি হ'ল:

• আপনি উল্লিখিত নাল অবজেক্ট প্যাটার্নের জন্য প্রয়োজনীয়তা পরিবর্তনের পরে আপনি কিছুটা কোড পরিবর্তন করেন। এটি ঠিক আছে তবে এর অর্থ এই নয় যে আপনি 'খুন' নল অবজেক্ট প্যাটার্নটি (বিটিডব্লিউ, আপনার শব্দটি সম্পর্কে সতর্ক থাকুন, এটি অত্যন্ত চরম শোনাচ্ছে, কিছু লোক খুব পারানিয়াক এটিকে মজার হিসাবে দেখবে না)।

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

• আপনি যে নকশার কথা বলেছিলেন সেটি খারাপ, কারণ প্রয়োজনীয় পরিবর্তনগুলি যখন ছোটখাটো জিনিস হিসাবে আসে, আপনি সমস্ত জায়গাগুলিতে প্রচুর কৌশলগত নকশার পরিবর্তন করেন। উচ্চ-স্তরের ব্যবসায়িক সমস্যার পরিবর্তন না হওয়া পর্যন্ত আপনি বিশাল ডিজাইনের পরিবর্তনকে ন্যায়সঙ্গত করতে পারবেন না।

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

Answer 6

আসুন এক মুহুর্তের জন্য বিরতি দিন এবং এখানে মৌলিক সমস্যাটি দেখুন - একটি সিস্টেমের আর্কিটেকিং যেখানে আর্কিটেকচার মডেলটি সিস্টেমের নিম্ন-স্তরের বৈশিষ্ট্যগুলির সাথে মিলিত হয়, যার ফলে আর্কিটেকচারটি বিকাশ প্রক্রিয়াটিতে প্রায়শই ভেঙে যায়।

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

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

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

এর জন্য আপনাকে কেবল প্রস্তাবিত সিস্টেমের বর্তমান প্রয়োজনীয়তাগুলি বোঝার প্রয়োজন হবে না, এটির সনাক্তকরণের জন্য এটির কী দিকগুলি সিস্টেমের স্থিতিশীল মূল বৈশিষ্ট্য হিসাবে দেখা যেতে পারে এবং বিকাশের সময় কী কী বৈশিষ্ট্যগুলি পরিবর্তিত হতে পারে identity

যদি আপনি দেখতে পান যে আপনাকে নিয়মিত অসংগঠিত স্প্যাগেটি কোডের সাথে লড়াই করতে হয়, আপনি সম্ভবত পর্যাপ্ত আর্কিটেকচার করছেন না বা উচ্চ স্তরের করছেন না। যদি আপনি দেখতে পান যে আপনার আর্কিটেকচারটি প্রায়শই ভেঙে যায়, আপনি সম্ভবত খুব বিস্তারিত আর্কিটেকচার করছেন।

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

খুব বিস্তৃত আর্কিটেকচারের ইস্যুতে প্রাসঙ্গিক, আপনি আর্কিটেকচারে খুব বেশি প্রচেষ্টা করতে পারেন যেখানে এটি খুব বেশি মূল্য দেয় না। রেফারেন্সের জন্য ঝুঁকি চালিত আর্কিটেকচার দেখুন, আমি এই বইটি পছন্দ করি - যথেষ্ট পরিমাণে সফ্টওয়্যার আর্কিটেকচার , সম্ভবত আপনিও পাবেন।

সম্পাদন করা

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

Comments

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

— শমূয়েল

Answer 7

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

প্রযুক্তিগত এবং আন্তঃব্যক্তিক দুটি পৃথক সমস্যা ক্ষেত্র হওয়ায় আমি প্রত্যেককে পৃথকভাবে সম্বোধন করব।

আন্তঃব্যক্তিগত

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

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

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

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

কারিগরী

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

(নিম্নলিখিতটি এমন প্রযুক্তিগত সমাধানগুলির একটি সেট যা মূল প্রশ্নে জিজ্ঞাসা করা হয়নি, তবে এটি দেখায় যে আমরা উদাহরণস্বরূপ উদ্দেশ্যে কীভাবে নিদর্শনগুলি মেনে চলতে পারি))

নাল বস্তুর পেছনের মূলনীতিটি কী পরিবর্তিত হয় তা এনক্যাপসুলেট করার ধারণা । আমরা কী পরিবর্তন করে তা গোপন করি যাতে এর সাথে অন্য কোথাও আমাদের মোকাবেলা করতে হবে না। এখানে, নাল অবজেক্টটি product.Priceউদাহরণটিতে বৈকল্পিককে আবদ্ধ করছিল (আমি এটিকে একটি Priceবস্তু বলব এবং নাল বস্তুর দাম হবে NullPrice)। Priceএকটি ডোমেন অবজেক্ট, একটি ব্যবসায়িক ধারণা। কখনও কখনও, আমাদের ব্যবসায়িক যুক্তিতে, আমরা এখনও দাম জানি না। এটা ঘতছে. নাল বস্তুর জন্য উপযুক্ত ব্যবহারের কেস। Prices এর একটি ToStringপদ্ধতি রয়েছে যা দামকে আউটপুট করে বা খালি স্ট্রিংটি জানা না থাকলে (বা, NullPrice#ToStringএকটি খালি স্ট্রিং দেয়)। এটি একটি যুক্তিসঙ্গত আচরণ। তারপরে প্রয়োজনীয়তা পরিবর্তন হয়।

আমাদের nullএপিআই ভিউতে আউটপুট দিতে হবে বা ম্যানেজারের ভিউতে আলাদা স্ট্রিং দিতে হবে। এটি কীভাবে আমাদের ব্যবসায়িক যুক্তিকে প্রভাবিত করে? ভাল, এটা না। উপরের বিবৃতিতে, আমি দুটি বার 'ভিউ' শব্দটি ব্যবহার করেছি। এই শব্দটি সম্ভবত স্পষ্টভাবে বলা হয়নি, তবে আমাদের অবশ্যই প্রয়োজনের মধ্যে লুকানো শব্দগুলি শুনতে প্রশিক্ষণ দিতে হবে। তাহলে 'ভিউ' এত ব্যাপার কেন? কারণ এটি আমাদের জানিয়েছে যে পরিবর্তনটি আসলে কী ঘটবে: আমাদের দৃষ্টিতে।

পাশে : আমরা একটি এমভিসি কাঠামো ব্যবহার করছি কিনা তা এখানে অপ্রাসঙ্গিক। যদিও এমভিসি'র 'ভিউ'র জন্য খুব নির্দিষ্ট অর্থ রয়েছে, আমি উপস্থাপনা কোডের এক টুকরোটির আরও সাধারণ (এবং সম্ভবত আরও প্রযোজ্য) অর্থ এটি ব্যবহার করছি।

সুতরাং আমাদের দেখার প্রয়োজনে এটি ঠিক করা দরকার to আমরা কীভাবে এটি করতে পারি? এটি করার সহজতম উপায়টি একটি ifবিবৃতি হবে। আমি জানি নাল বস্তুটি সমস্ত আইএফএস থেকে মুক্তি পাওয়ার উদ্দেশ্যে করা হয়েছিল, তবে আমাদের ব্যবহারিক হতে হবে। আমরা স্ট্রিংটি খালি কিনা তা পরীক্ষা করে দেখতে পারি এবং স্যুইচ করতে পারি:

if(product.Price.ToString("c").Length == 0) { // one way of many
    writer.write("Price unspecified [Change]");
} else {
    writer.write(product.Price.ToString("c"));
}

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

আমরা বলতে পারি যে আমাদের ব্যবসায়ের যুক্তি কিছুটা পরিবর্তিত হয়েছে যে কোনও দাম নির্ধারিত না হলে আমরা ডিফল্ট স্ট্রিংগুলি আউটপুট দিতে চাই। আমরা আমাদের Price#ToStringপদ্ধতিতে একটি সামান্য ঝাঁকুনি দিতে পারি (আসলে একটি ওভারলোডেড পদ্ধতি তৈরি করুন)। আমরা একটি ডিফল্ট রিটার্ন মান গ্রহণ করতে পারি এবং কোনও মূল্য সেট না করা থাকলে তা ফিরিয়ে দিতে পারি:

class Price {
    ...
    // A new ToString method
    public string ToString(string c, string default) {
        return ToString(c);
    }
    ...
}

class NullPrice {
    ...
    // A new ToString method
    public string ToString(string c, string default) {
        return default;
    }
    ...
}

এবং এখন আমাদের দেখার কোড হয়ে যায়:

writer.write(product.Price.ToString("c", "Price unspecified [Change]"));

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

এর পরিবর্তে আমরা একটি IsSetপদ্ধতি তৈরি করতে পারতাম Priceযেটিতে একটি বুলিয়ান দেয়:

class Price {
    ...
    public bool IsSet() {
        return return true;
    }
    ...
}

class NullPrice {
    ...
    public bool IsSet() {
        return false;
    }
    ...
}

যুক্তি দেখুন:

if(product.Price.IsSet()) {
    writer.write(product.Price.ToString("c"));
} else {
    writer.write("Price unspecified [Change]");
}

আমরা দেখুন শর্তাধীন শর্ত সাপেক্ষে ফিরে আসছি, তবে দাম নির্ধারণ করা হয়েছে কিনা তা ব্যবসায়ের যুক্তিগুলির জন্য কেস আরও শক্তিশালী। Price#IsSetআমাদের কাছে এটি উপলব্ধ রয়েছে এখন আমরা অন্য কোথাও ব্যবহার করতে পারি।

পরিশেষে, আমরা দেখার জন্য কোনও সহায়তায় পুরোপুরি মূল্য উপস্থাপনের ধারণাটি সজ্জিত করতে পারি। এটি আমাদের শর্তসাপেক্ষে ডোমেন অবজেক্টটি সংরক্ষণ করার সময় শর্তযুক্ত লুকিয়ে রাখবে:

class PriceStringHelper {
    public PriceStringHelper() {}

    public string PriceToString(Price price, string default) {
        if(price.IsSet()) { // or use string length to not change the Price class at all
           return price.ToString("c");
        } else {
            return default;
        }
    }
}

যুক্তি দেখুন:

writer.write(new PriceStringHelper().PriceToString(product.Price, "Price unspecified [Change]"));

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

Answer 8

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

প্রয়োজনীয়তার সাথে দস্তাবেজের প্রকরণের পয়েন্টগুলি (সেগুলি ঝুঁকিপূর্ণ)

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

যদি আপনার প্রয়োজনীয়তাগুলি এতটাই অস্থিতিশীল হয় যে আপনার "পূর্বাভাসের বিভিন্নতা" সর্বদা ভুল হয়, তবে আপনি যে প্যাটার্নগুলি প্রয়োগ করেন তা আপনাকে ব্যথিত করবে বা সর্বোপরি অনিরাপদ জটিলতা তৈরি করবে।

সুরক্ষিত বৈচিত্রগুলি প্রয়োগ করার দুটি সুযোগের কথা ক্রেগ লারম্যান বলেছেন:

• প্রকরণের পয়েন্টস - বিদ্যমান, বর্তমান সিস্টেম বা প্রয়োজনীয়তার ক্ষেত্রে যেমন একাধিক ইন্টারফেস যা সমর্থিত হতে হবে এবং
• বিবর্তন পয়েন্টস - পরিবর্তনের অনুমানের পয়েন্টগুলি যা বিদ্যমান প্রয়োজনীয়তার সাথে উপস্থিত নয়।

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

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

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

CONSTANTS উত্স কোড ইন পিভির একটি সাধারণ ফর্ম

আপনার প্রশ্নের আর একটি সাদৃশ্যটি জিজ্ঞাসা করা উচিত CONSTANTSউত্স কোড ব্যবহার করা ভাল ধারণা কিনা। এই উদাহরণটির উল্লেখ করে , যাক গ্রাহক পাসওয়ার্ডের প্রয়োজনীয়তা বাদ দিয়েছেন। সুতরাং MAX_PASSWORD_SIZEআপনার কোড জুড়ে অবিচ্ছিন্নভাবে ছড়িয়ে পড়া অকেজো হয়ে উঠবে এবং রক্ষণাবেক্ষণ এবং স্বচ্ছলতার ক্ষেত্রে বাধা হয়ে দাঁড়াবে। CONSTANTSকারণ হিসাবে আপনি ব্যবহার দোষারোপ করবেন ?

Answer 9

আমি মনে করি এটি আপনার পরিস্থিতির প্রকৃতির উপর অন্তত আংশিকভাবে নির্ভর করে।

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

অন্যদিকে, যদি পরিবর্তনের প্রকৃতিটি আরও বেশি "আমার লন্ড্রোমেট সমষ্টিগতের বেতন নির্ধারণ করতে এই মৌমাছি রাখার অ্যাপ্লিকেশনটি চাই", তেমন কোনও কোডের পরিমাণ আপনাকে আপনার গর্ত থেকে বের করে আনবে না।

নকশা নিদর্শন সম্পর্কে অন্তর্নিহিত ভাল কিছুই নেই। এগুলি অন্য যেগুলির মতো সরঞ্জাম - আমরা কেবলমাত্র মাঝারি থেকে দীর্ঘ সময়ে আমাদের কাজ সহজ করার জন্য এগুলি ব্যবহার করি। যদি কোনও আলাদা সরঞ্জাম (যেমন যোগাযোগ বা গবেষণা ) আরও কার্যকর হয় তবে আমরা এটি ব্যবহার করি।