ওভারলোডিং ওপেন / বদ্ধ নীতিটির উদাহরণ?

12

উইকিপিডিয়া বলেছেন

"সফ্টওয়্যার সত্তা (শ্রেণি, মডিউল, ফাংশন, ইত্যাদি) এক্সটেনশনের জন্য উন্মুক্ত হওয়া উচিত, তবে পরিবর্তনের জন্য বন্ধ করা উচিত"

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

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

bool IsAdmin(userId)

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

public bool IsAdmin(string username)
{
    int userId = UserManager.GetUser(username).Id;
    return IsAdmin(userId);
}

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

এটি কি ওপেন / বদ্ধ নীতিগত উদাহরণ?

solid design-patterns open-close

— সা Saeedদ নেমতি
সূত্র

5

আমি ব্যক্তিগতভাবে এইভাবে উইকির বক্তব্যটি ব্যাখ্যা করব:

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

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

— Sassafras_wot
সূত্র

3

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

public bool IsAdmin(int userid)
{
    User user = UserManager.GetUser(userid);
    return user.IsAdmin();
}

public bool IsAdmin(string username)
{
    int userId = UserManager.GetUser(username).Id;
    return IsAdmin(userId);
}

আপনার অবশ্যই সেই ক্লাসটি বাড়ানো উচিত ।

public bool IsAdmin(int userid)
{
    User user = UserManager.GetUserById(userid);
    return user.IsAdmin();
}

public bool IsUsernameAdmin(string username)
{
    User userId = UserManager.GetUserByName(username);
    return user.IsAdmin();
}

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

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

চাচা বব যেমন বলেছেন (জোর আমার):

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

— PDR
সূত্র

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

— সা Saeedদ নেমতি

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

— পিডিআর

2

মুক্ত-বদ্ধ নীতি অনুসারে মডিউলগুলির দুটি প্রাথমিক বৈশিষ্ট্য রয়েছে।

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

তারা "মোদির পক্ষে বন্ধ" are এই জাতীয় মডিউলটির উত্স কোডটি চালিত। এটিতে উত্স কোড পরিবর্তন করার জন্য কাউকে অনুমতি নেই।

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

মূল পদ্ধতি পরিবর্তন না করার বিষয়ে অন্যেরা কী বলেছে তা শুনতে আমি আগ্রহী be হ্যাঁ, আপনি উপযুক্ত অ্যাক্সেস সংশোধক রাখতে পারেন এবং এনক্যাপসুলেশন প্রয়োগ করতে পারেন, তবে আর কী করা যায়?

তথ্যসূত্র: http://www.objectmentor.com/resources/articles/ocp.pdf oc

— CodeART
সূত্র

1

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

তবে ধরা যাক আপনার একটি ফাংশন বলা হয়েছিল BigContrivedMethod(int1, int2, string1)। BigContrivedMethodতিনটি জিনিস করে: জিনিস 1, জিনিস 2 এবং জিনিস 3 3 এই মুহুর্তে, বিসিএম পুনরায় ব্যবহার করা সম্ভবত শক্ত, কারণ এটি খুব বেশি করে। এটা refactoring (সম্ভব হলে) মধ্যে ContrivedFunction1(int), ContrivedFunction2(int)এবং ContrivedFunction3(string)আপনি তিনটি ছোট, আরও নিবদ্ধ পদ্ধতি দেয় আরও সহজে আপনাকে একত্রিত করতে পারেন।

এবং এটি পদ্ধতি / ফাংশন: রচনার ক্ষেত্রে ওসিপির মূল চাবিকাঠি। আপনি অন্যান্য ক্রিয়া থেকে কল করে তাদের "প্রসারিত" করুন।

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

— CodexArcanum
সূত্র

আমি মনে করি আপনি এখানে ওসিপি নয়, একা দায়িত্বের অধ্যক্ষের বিষয়ে কথা বলবেন।

— সা Saeedদ নেমতি

1

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

— কোডেক্সআর্কানিয়াম 10'12

এই উত্তর আরও upvated করা উচিত।

— আশীষ গুপ্ত

0

আপনি যদি পুরানো কোড পরিবর্তন না করে নতুন কোড লিখে আপনার প্রোগ্রামের আচরণ পরিবর্তন করে থাকেন তবে আপনি উন্মুক্ত নীতিটি অনুসরণ করছেন।

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

আপনি যখন নতুন কিছু আচরণের পরিবর্তে কিছু পরিবর্তন করার পরিবর্তে কিছু পরিবর্তন করতে চান তখন পরিবর্তনের বিষয়টি কী তা বোঝার জন্য, আপনার প্রোগ্রামটির আচরণটি পরিবর্তন না করেই পুনর্গঠন করুন যাতে আপনি নতুন কোড লিখে সেই আচরণটি পরিবর্তন করতে পারেন ।

সুতরাং, এটি আপনার ক্ষেত্রে কীভাবে প্রযোজ্য:

আপনি যদি আপনার ক্লাসে নতুন ফাংশন যুক্ত করে থাকেন তবে আপনার ক্লাসটি খোলা / বন্ধ নয় তবে আপনি যে ক্রিয়াকলাপটি ওভারলোড করছেন তার ক্লায়েন্টরা।

যদি আপনি কেবল নতুন ক্লাস যুক্ত করেন যা আপনার ক্লাসে কাজ করে, তবে এটি এবং আপনার ফাংশনের ক্লায়েন্ট উভয়ই খোলা / বন্ধ রয়েছে।

— এডওয়ার্ড স্ট্রেঞ্জ
সূত্র