অনুশীলনে খোলা-বন্ধ নীতিটি কীভাবে মেনে চলবেন


14

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

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

  1. আগে: প্রোগ্রামটি বিমূর্তকরণ এবং যতটা সম্ভব 'ভবিষ্যতের ভবিষ্যদ্বাণী করা' to উদাহরণস্বরূপ, ভবিষ্যতে সিস্টেমে এস যুক্ত করা drive(Car car)থাকলে একটি পদ্ধতি পরিবর্তন করতে হবে Motorcycle, সুতরাং এটি সম্ভবত ওসিপি লঙ্ঘন করে। তবে ভবিষ্যতে পদ্ধতিটি drive(MotorVehicle vehicle)পরিবর্তনের সম্ভাবনা কম, তাই এটি ওসিপিতে মেনে চলে।

    তবে ভবিষ্যতের ভবিষ্যদ্বাণী করা এবং সিস্টেমে কী কী পরিবর্তন আনতে চলেছে তা আগেই জানা খুব কঠিন difficult

  2. পরে: যখন কোনও পরিবর্তন প্রয়োজন হয়, তার বর্তমান কোডটি পরিবর্তনের পরিবর্তে একটি শ্রেণি প্রসারিত করুন।

# 1 অনুশীলনটি বোঝা শক্ত নয়। তবে এটি অনুশীলন # 2 যে কীভাবে প্রয়োগ করতে হয় তা বুঝতে আমার সমস্যা হচ্ছে।

উদাহরণ হিসেবে বলা যায় (আমি এটা YouTube- এ একটি ভিডিও থেকে গ্রহণ): দিন আসুন আমরা একটি বর্গ যে গ্রহণ করে একটি পদ্ধতি আছে CreditCardবস্তু: makePayment(CraditCard card)। এক দিনের Voucherএস সিস্টেমে যুক্ত করা হয়। এই পদ্ধতিটি তাদের সমর্থন করে না তাই এটি পরিবর্তন করতে হবে।

প্রথমে পদ্ধতিটি প্রয়োগ করার সময় আমরা ভবিষ্যত এবং প্রোগ্রামটিকে আরও বিমূর্ত শর্তে ভবিষ্যদ্বাণী করতে ব্যর্থ হয়েছি (উদাহরণস্বরূপ makePayment(Payment pay), এখন আমাদের বিদ্যমান কোডটি পরিবর্তন করতে হবে)।

অনুশীলন # 2 বলছে আমাদের পরিবর্তনের পরিবর্তে প্রসারিত করে কার্যকারিতা যুক্ত করা উচিত। ওটার মানে কি? আমি কি বিদ্যমান ক্লাসটির বিদ্যমান কোডটি পরিবর্তনের পরিবর্তে সাবক্লাস করা উচিত? পুনর্লিখনের কোডটি এড়াতে কি আমার চারপাশে কোনও ধরণের আবরণ তৈরি করা উচিত?

অথবা নীতিটি 'কার্যকারিতাটি কীভাবে সঠিকভাবে সংশোধন / সংযোজন করতে হবে' বোঝায় না, বরং 'প্রথম স্থানে (অর্থাৎ বিমূর্তির প্রোগ্রামে) পরিবর্তন কীভাবে এড়াতে হবে তা বোঝায়?



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

উত্তর:


14

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

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

অনুশীলনে, যখন আপনি কেবল দুটি বাস্তবায়ন করেন, যখন আপনি তৃতীয় যুক্ত করেন তখন রিফ্যাক্টরিং সাধারণত খুব কঠিন হয় না। এটি যখন আপনি এটিকে সেই পর্যায়ে যেতে দিন যে এটি বজায় রাখতে সমস্যা হয়।


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

1

2

আমি মনে করি আপনি ভবিষ্যতের দিকে অনেক দূরে সন্ধান করছেন। বর্তমান সমস্যাটিকে নমনীয় উপায়ে সমাধান করুন যা খোলার / বন্ধ করার জন্য মেনে চলে।

আসুন আমরা বলি যে আপনার একটি drive(Car car)পদ্ধতি বাস্তবায়ন করা দরকার । আপনার ভাষার উপর নির্ভর করে আপনার কাছে কয়েকটি বিকল্প রয়েছে।

  • যে ভাষার জন্য ওভারলোডিং (সি ++) সমর্থন করে, কেবল সেগুলি ব্যবহার করুন drive(const Car& car)

    কিছু সময় পরে আপনার প্রয়োজন হতে পারে drive(const Motorcycle& motorcycle), তবে এটি কোনও হস্তক্ষেপ করবে না drive(const Car& car)। সমস্যা নেই!

  • যে ভাষার জন্য ওভারলোডিং (উদ্দেশ্য সি) সমর্থন করে না, তারপরে পদ্ধতিতে প্রকারের নামটি অন্তর্ভুক্ত করুন -driveCar:(Car *)car

    কিছু সময় পরে আপনার প্রয়োজন হতে পারে -driveMotorcycle:(Motorcycle *)motorcycle, তবে আবার এটি হস্তক্ষেপ করবে না।

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

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


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

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

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

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

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

2

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

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

ওটার মানে কি? আমি কি বিদ্যমান ক্লাসটির বিদ্যমান কোডটি পরিবর্তনের পরিবর্তে সাবক্লাস করা উচিত?

হা.

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

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

নতুন আচরণ = নতুন শ্রেণি

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

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