কোনও পদ্ধতির নাম পরিবর্তন কী এনক্যাপসুলেশন সংরক্ষণ করতে পারে?

Question

আমি এই পৃষ্ঠাটি পড়ছিলাম , কখন গ্রাহকরা / সেটটারদের ন্যায্যতা দেওয়া হয় এবং ওপি নিম্নলিখিত কোডের নমুনা দেয়:

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

গৃহীত উত্তর পদ বলে:

উপায় দ্বারা, আপনার উদাহরণে, আমি বর্গ দিতে হবে এবং পদ্ধতি, পরিবর্তে এবং । তারপর আপনি এখনও encapsulation থাকতে হবে।FridgeputCheese()takeCheese()get_cheese()set_cheese()

কীভাবে এনক্যাপসুলেশনটি এটিকে নাম / সেট / সেট থেকে নাম পরিবর্তন করে সংরক্ষণ করা হয় putCheese()/ takeCheese()আপনি সম্ভবত একটি মান পাচ্ছেন / সেট করছেন, তবে কেন কেবল সেটাকে সেট / সেট হিসাবে রেখে যাবেন না?

একই উত্তরে এটিও বলে:

গিটারস এবং সেটটার থাকা নিজেরাই এনক্যাপসুলেশনটি ভেঙে দেয় না। বিরতি এনক্যাপসুলেশন কী তা কোনও চিন্তাভাবনা না করে স্বয়ংক্রিয়ভাবে প্রতিটি ডেটা সদস্যের (প্রতিটি ক্ষেত্র, জাভা লিঙ্গো) জন্য একটি গিটার এবং একটি সেটার যুক্ত করছে।

এই ক্ষেত্রে, আমাদের কেবল একটি পরিবর্তনশীল রয়েছে cheeseএবং আপনি পনিরটি ফ্রিজে নিতে এবং ফিরিয়ে আনতে চাইতে পারেন, সুতরাং এই ক্ষেত্রে একটি গেট / সেট জুটি ন্যায়সঙ্গত।

Comments

putCheeseফ্রিজে পনির যোগ করতে takeCheeseহবে এবং এটিকে সরিয়ে ফেলবে - এগুলি (উচ্চ স্তরের) ডোমেন-ভিত্তিক বিমূর্ততা নয়, বস্তু ক্ষেত্রের গেটর এবং সেটটার (যা (নিম্ন স্তরের) কম্পিউটার প্রোগ্রামিং বিমূর্ততা) এর চেয়ে বেশি।

— এরিক tদ

Answer 1

আমি মনে করি আপনি পয়েন্টটি মিস করছেন। এটি বলছে না যে আপনার সেটার এবং গেটরের নাম পরিবর্তন করা উচিত, তবে এমন পদ্ধতি রয়েছে যা ফ্রিজে আইটেম যুক্ত এবং সরিয়ে দেয়। অর্থাত

public class Fridge
{
    private int numberOfCheeseSlices;

    public void AddCheeseSlices(int n)
    {
         if(n < 0) { 
             throw new Exception("you cant add negative cheese!");
         }
         if(numberOfCheeseSlices + n > this.capacityOfFridge) { 
             throw new Exception("TOO MUCH CHEESE!!");
         }
         ..etc
         this.numberOfCheeseSlices += n;
    }
}

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

Comments

ঠিক আছে, তবে আপনি setCheese()সেটারে একই যুক্তি থাকতে পারে এমনটি এখনও রেখে যেতে পারেন । আমার কাছে যাইহোক, আপনি পদ্ধতিটির নাম পরিবর্তন করে কোনও সেটার ব্যবহার করছেন এমন তথ্যটি গোপন করার চেষ্টা করছেন, তবে আপনার স্পষ্টতই কিছুটা সেট / সেট করেছেন।

— কুইনস্বেতলানা

পছন্দ করুন এটি একটি অপারেশন। আপনি ফ্রিজটি "এখানে অন্য একটি পনির" বলছেন এবং এটি এটি এর অভ্যন্তরীণ, এনপ্যাপুলেটেড পনির গণনায় যুক্ত করছে। একজন সেটটার বলতেন "আপনার কাছে এখন 5 টি চিজ আছে"। এগুলি কেবল ভিন্ন নাম নয়, কার্যত ভিন্ন অপারেশন।

— পিঁপড়া পি

আপনি এটিকে সেটচিজ বলতে পারেন, তবে এটি বিভ্রান্তিকর হবে কারণ এটি পনিরের মান নির্ধারণ করে না।

— ইওয়ান

এখানে একটি পূর্ণসংখ্যার ওভারফ্লো বাগ রয়েছে Note ইতিমধ্যে 0 টিরও বেশি পনির থাকলে, AddCheese(Integer.MAX_VALUE)ব্যর্থ হওয়া উচিত, তবে তা হবে না।

— ব্যবহারকারী 253751

এটি সম্পূর্ণরূপে .. ইত্যাদি বিভাগে আচ্ছাদিত হবে

— ইওয়ান

Answer 2

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

কীভাবে এনক্যাপসুলেশনটিকে গেট / সেট থেকে সেটচিজ () / টেকচিইস () এ সেট করে নাম পরিবর্তন করে সংরক্ষণ করা হয় আপনি স্পষ্টতই একটি মান পাচ্ছেন / সেট করছেন, তবে কেন কেবল সেটাকে সেট / সেট হিসাবে রেখে যাবেন না?

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

সুতরাং getএবং setপ্রযুক্তিগত পদগুলি এবং এটিকে "ফ্রিজে" ডোমেনের সাথে কোনও সম্পর্কযুক্ত বলে মনে হচ্ছে না, putএবং takeসম্ভবত এটি কিছুটা বোধগম্য হতে পারে।

তবে কিনা putবা takeকরতে প্রকৃত অর্থে এখনো প্রয়োজনীয়তা উপর নির্ভর করে এবং নিরপেক্ষভাবে বিচার করা যাবে না। পরের বিষয়টি দেখুন:

এই ক্ষেত্রে, আমাদের কেবল একটি পরিবর্তনশীল, পনির রয়েছে এবং আপনি পনিরটি ফ্রিজে নিতে এবং ফিরিয়ে আনতে চাইতে পারেন, সুতরাং এই ক্ষেত্রে একটি গেট / সেট জুটি ন্যায়সঙ্গত।

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

মনে রাখবেন, আপনি জেনেরিক, পুনরায় ব্যবহারযোগ্য ব্যবহার করছেন না Fridge। আপনি Fridgeকেবল আপনার প্রয়োজনীয়তার জন্য একটি তৈরি করছেন। যা করা দরকার তার চেয়ে বেশি পরিমাণে ব্যয় করতে ব্যয় করা আসলে ব্যর্থ।

Comments

Getters and setters break encapsulation every single time- এটি আমার স্বাদের জন্য কিছুটা দৃ strongly়ভাবে বলা হয়েছে। পদ্ধতিগুলি (গেটর এবং সেটটার সহ) গেটগুলি কনসার্টে করার মতো একই উদ্দেশ্য থাকে: তারা সুশৃঙ্খলভাবে প্রবেশ এবং ভেন্যু থেকে প্রস্থান করার অনুমতি দেয়।

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

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

— ফিলিপ মিলোভানোভি

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

— রবার্ট ব্রুটিগাম

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

— WHN

ঠিক আছে, গেটার্স এবং সেটার কেবলমাত্র 99% সময় এনক্যাপসুলেশন বিরতি করে। খুশি? এবং, প্রকাশক দ্বারা টাইপ encapsulated বস্তুর, তারা স্পষ্টভাবে এনক্যাপস্যুলেশন ভঙ্গ করো না। একবার আপনার কাছে public int getFoo()এলে এটি প্রায় অসম্ভব, বাস্তবে, অন্য ধরণের পরিবর্তিত।

— user949300

Answer 3

এগুলির প্রায় সমস্তই এনক্যাপসুলেশনের একটি মৌলিক ভুল বোঝাবুঝি এবং এটি কীভাবে প্রযোজ্য তা দেখায়।

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

যখন কোনও মান পেতে বা সেট করার বৈধ প্রয়োজন হয় তখন একজন গিটার বা সেটার এনক্যাপসুলেশনটি ভাঙবে না। এই কারণেই পদ্ধতিগুলি জনসাধারণ্যে করা যায় can

এনক্যাপসুলেশন হ'ল ডেটা এবং সেই পদ্ধতিগুলি যা সেই ডেটাটিকে সরাসরি এক যৌক্তিক স্থানে, ক্লাসে সংশোধন করে।

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

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

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

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

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

Comments

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

— রবার্ট ব্রুটিগাম

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

— ব্যবহারকারী 343330

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

— রবার্ট ব্রুটিগাম

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

— স্থিত

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

— ব্যবহারকারীর 343330

Answer 4

এটি কেবল কোনও পদ্ধতির নামকরণ নয়। দুটি পদ্ধতি আলাদাভাবে কাজ করে।

(আপনার মনের মধ্যে এটি চিত্র)

get_cheese এবং সেট_চিজ পনির উন্মোচন করে। চিটস () এবং টিক চিজ () পনিরটি গোপন রাখে এবং এটি পরিচালনা করার যত্ন নেয় এবং ব্যবহারকারীকে এটি পরিচালনা করার উপায় দেয়। পর্যবেক্ষক পনিরটি দেখেন না, কেবলমাত্র এটির কৌশলগত কৌশল দুটি দেখেন।