যেমনটি আমি এটি ব্যাখ্যা করেছি, মুক্ত / বদ্ধ নীতিতে বলা হয়েছে যে একবার লিখিত কোডটি পরিবর্তন করা উচিত নয় (বাগ ফিক্সগুলি বাদ দিয়ে)। কিন্তু যদি আমার ব্যবসায়ের নিয়ম পরিবর্তন হয় তবে আমি কি এই পরিবর্তনগুলি প্রয়োগ করে কোডটি সংশোধন করব না? আমার সন্দেহ হয় যে নীতিটি আমার কাছে বোধগম্য হয় না সে সম্পর্কে আমি কিছু বুঝতে পারছি না।
উত্তর:
এটি সম্ভবত ব্যাখ্যা করা শক্ত নীতিগুলির মধ্যে সবচেয়ে কঠিন। আমাকে চেষ্টা করতে দাও. কল্পনা করুন আপনি একটি চালান ক্লাস লিখেছেন যা নিখুঁতভাবে কাজ করে এবং এতে কোনও বাগ নেই। এটি একটি চালানের পিডিএফ তৈরি করে।
তারপরে কেউ বলছেন যে তারা এতে লিঙ্কযুক্ত একটি HTML চালান চান। আপনি এই অনুরোধটি সন্তুষ্ট করতে চালানে কোনও কোড পরিবর্তন করবেন না। পরিবর্তে, আপনি অন্য শ্রেণি তৈরি করেন, এইচটিএমএল ইনভয়েস, এখন তারা যা চায় তা করে। আপনি উত্তরাধিকার উত্তোলন করেন যাতে আপনাকে HTMLInvoice এ প্রচুর নকল কোড লিখতে না হয়।
পুরাতন কোড যা পুরানো ইনভয়েস ব্যবহার করছিল তা কোনওভাবেই ভাঙা বা সত্যই প্রভাবিত হয়নি। নতুন কোডটি এইচটিএমএল ইনভয়েস ব্যবহার করতে পারে। (আপনি যদি লিসকোব সাবস্টিটিউটেবিলিটি , শক্তের এলও করেন তবে আপনি চালানের উদাহরণগুলির প্রত্যাশিত বিদ্যমান কোডটিতে এইচটিএমএল ইনভয়েস উদাহরণ দিতে পারেন)) প্রত্যেকেই সুখীভাবে পরে বাস করে।
চালানটি পরিবর্তনের জন্য বন্ধ হয়ে গেছে, এক্সটেনশনে খোলা আছে। এবং এই কাজ করার জন্য আপনাকে আগেই চালানটি সঠিকভাবে লিখতে হবে, বিটিডাব্লু।
আপনি কি অবজেক্টমেন্টারে আঙ্কেল ববসের পালস দ্বারা খোলা-ক্লোজড প্রিন্সিপাল নিবন্ধটি পড়েছেন? আমি মনে করি এটি সেখানকার আরও ভাল ব্যাখ্যা।
অবজেক্ট ওরিয়েন্টড ডিজাইনের সাথে সম্পর্কিত অনেকগুলি হিউরিস্টিকস রয়েছে। উদাহরণস্বরূপ, "সমস্ত সদস্যের ভেরিয়েবলগুলি ব্যক্তিগত হওয়া উচিত", বা "গ্লোবাল ভেরিয়েবলগুলি এড়ানো উচিত" বা "রান টাইম টাইপ আইডেন্টিফিকেশন (আরটিটিআই) ব্যবহার করা বিপজ্জনক"। এই হিউরিস্টিকসের উত্স কী? এগুলি কী সত্য করে? তারা সবসময় সত্য? এই কলামটি নকশার নীতিটি অনুসন্ধান করে যা এই হিউরিস্টিকসকে অন্তর্ভুক্ত করে - মুক্ত-বদ্ধ নীতি।
যেমন ইভার জ্যাকবসন বলেছিলেন: "সমস্ত সিস্টেমগুলি তাদের জীবনচক্রের সময় পরিবর্তিত হয়। উন্নয়নশীল সিস্টেমগুলি প্রথম সংস্করণের চেয়ে দীর্ঘস্থায়ী হওয়ার প্রত্যাশার ক্ষেত্রে এটি অবশ্যই মনে রাখা উচিত ”" পরিবর্তনের মুখে স্থিতিশীল এবং এটি প্রথম সংস্করণের চেয়ে দীর্ঘতর হবে এমন ডিজাইন আমরা কীভাবে তৈরি করতে পারি? বার্ট্র্যান্ড মেয়ের 1988 সাল পর্যন্ত যখন আমাদের বিখ্যাত খোলামেলা নীতিটি তৈরি করেছিলেন তখন তিনি আমাদেরকে দিকনির্দেশনা দিয়েছিলেন। তাকে প্যারাফ্রেস করতে:
সফ্টওয়্যার এন্টি (ক্লাস, মডিউল, ফাংশনস, ইত্যাদি) খোলার জন্য খোলা উচিত, তবে পরিবর্তনের জন্য বন্ধ করা উচিত।
যখন কোনও প্রোগ্রামের একক পরিবর্তনের ফলে নির্ভরশীল মডিউলগুলিতে পরিবর্তনের ঝাঁকুনির সৃষ্টি হয়, তখন সেই প্রোগ্রামটি আমরা "খারাপ" ডিজাইনের সাথে সংযুক্ত করতে আসা অযাচিত বৈশিষ্ট্যগুলি প্রদর্শন করি। প্রোগ্রামটি ভঙ্গুর, অনমনীয়, প্রত্যাশিত এবং অবিশ্বাস্য হয়ে ওঠে। উন্মুক্ত-নীতিটি একে একে খুব সোজা পদ্ধতিতে আক্রমণ করে। এটি বলে যে আপনার এমন মডিউলগুলি ডিজাইন করা উচিত যা কখনই পরিবর্তন হয় না । যখন প্রয়োজনীয়তাগুলি পরিবর্তন হয়, আপনি নতুন কোড যুক্ত করে এই জাতীয় মডিউলগুলির আচরণটি প্রসারিত করুন, ইতিমধ্যে কাজ করা পুরানো কোড পরিবর্তন করে নয়।
বিবরণ
মুক্ত-বদ্ধ নীতি অনুসারে মডিউলগুলির দুটি প্রাথমিক বৈশিষ্ট্য রয়েছে।
- তারা "এক্সটেনশনের জন্য উন্মুক্ত" are
এর অর্থ মডিউলটির আচরণ প্রসারিত হতে পারে। অ্যাপ্লিকেশন পরিবর্তনের প্রয়োজনীয়তা হিসাবে বা নতুন অ্যাপ্লিকেশনগুলির চাহিদা পূরণের জন্য আমরা মডিউলটিকে নতুন এবং বিভিন্ন উপায়ে আচরণ করতে পারি।- এগুলি "পরিবর্তনের জন্য বন্ধ" ”
এই জাতীয় মডিউলটির উত্স কোডটি চালিত। এটিতে উত্স কোড পরিবর্তন করার জন্য কাউকে অনুমতি নেই।দেখে মনে হবে এই দুটি বৈশিষ্ট্য একে অপরের সাথে মতবিরোধের মধ্যে রয়েছে। মডিউলটির আচরণ প্রসারিত করার সাধারণ উপায়টি হল সেই মডিউলে পরিবর্তন করা make যে মডিউলটি পরিবর্তন করা যায় না তা সাধারণত একটি স্থির আচরণ বলে মনে করা হয়। এই দুটি বিরোধী গুণাবলী কীভাবে সমাধান করা যায়?
বিমূর্ততা মূল ...
কেট গ্রেগরি দ্বারা উত্তর খুব ভাল হয়, কিন্তু একটি ভিন্ন পরিস্থিতি যেখানে একটি নতুন প্রয়োজন বিদ্যমান একটি অপেক্ষাকৃত ছোট পরিবর্তনের ফলে সন্তুষ্ট করা যাবে বিবেচনা Invoiceবর্গ। উদাহরণস্বরূপ, আসুন বলি যে ইনভয়েস পিডিএফটিতে একটি নতুন ক্ষেত্র যুক্ত করা উচিত। ওসিপি অনুসারে, আমাদের এখনও একটি নতুন সাবক্লাস তৈরি করা উচিত, যদিও কোডের কয়েকটি লাইন পরিবর্তন করে বিদ্যমান প্রয়োগে নতুন ক্ষেত্রটি যুক্ত করা যায়।
আমার উপলব্ধি অনুসারে, ওসিপি 80 এবং 90 এর দশকের গোড়ার দিকে বাস্তবতা প্রতিফলিত করে, যেখানে প্রকল্পগুলি প্রায়শই সংস্করণ নিয়ন্ত্রণ ব্যবহার করে না, অনেক কম অটোমেটিক রিগ্রেশন টেস্ট বা অত্যাধুনিক রিফ্যাক্টরিং সরঞ্জামগুলির সুবিধা নিয়েছিল। ওসিপি হ'ল ম্যানুয়ালি টেস্ট করা এবং উত্পাদন করা হয়েছে এমন কোডটি ভঙ্গ করার ঝুঁকি এড়ানোর একটি প্রচেষ্টা ছিল। আজ, ওয়ার্কিং সফটওয়্যার (যথা সংস্করণ নিয়ন্ত্রণ ব্যবস্থা, টিডিডি এবং স্বয়ংক্রিয় পরীক্ষণ, এবং রিফ্যাক্টরিং সরঞ্জাম) ভাঙার ঝুঁকি পরিচালনা করার জন্য আমাদের আরও ভাল উপায় রয়েছে।
ব্যক্তিগতভাবে আমি মনে করি এই নীতিটি এক চিমটি লবণের সাথে নেওয়া উচিত। কোডটি জৈবিক, ব্যবসায়ের পরিবর্তন এবং সময়ের সাথে সাথে ব্যবসায়ের প্রয়োজনীয়তা অনুসারে কোড পরিবর্তন হয়।
বিমূর্ততা কী, এই বিষয়টিকে ঘিরে আমার মাথা পেতে খুব অসুবিধা হয়। মূলত যদি বিমূর্ততাটি ভুল হত তবে কী হবে? যদি ব্যবসায়ের কার্যকারিতা উল্লেখযোগ্যভাবে পরিবর্তিত হয়?
এই নীতিটি মূলত নিশ্চিত করে যে কোনও নকশার মূল উদ্দেশ্য এবং আচরণ কখনই বদলাতে পারে না। এটি সম্ভবত তাদের জন্য কাজ করে যাদের পাবলিক এপিআই রয়েছে এবং তাদের ক্লায়েন্টরা নতুন রিলিজ এবং আরও কিছু অ্যাড-কেস রাখতে সমস্যা বোধ করে। তবে, যদি কোনও সংস্থা সমস্ত কোডের মালিক হয়, তবে আমি এই নীতিটিকে চ্যালেঞ্জ জানাই।
আপনার কোডের ভাল পরীক্ষার কভারেজ থাকার কারণে আপনার কোড বেসকে বাতাসের পুনরুদ্ধার করা উচিত। এর অর্থ হল যে জিনিসগুলিকে ভুল করা ঠিক আছে - আপনার পরীক্ষাগুলি আপনাকে আরও ভাল ডিজাইনের দিকে পরিচালিত করতে সহায়তা করবে।
বলছেন যে, যদি কোনও পরীক্ষা না হয় তবে এই নীতিটি যথাযথ।