জাভাতে, সুরক্ষিত সদস্যদের একই প্যাকেজের ক্লাসে অ্যাক্সেসযোগ্য কেন করা হয়েছিল?


14

অফিসিয়াল ডকুমেন্টেশন থেকে ...

মডিফায়ার ক্লাস প্যাকেজ সাবক্লাস ওয়ার্ল্ড 
YYYY 
YYYN সুরক্ষিত 
কোনও সংশোধক YYNN নেই 
বেসরকারী YNNN 

জিনিসটি হ'ল, আমি মনে করতে পারি না এমন ব্যবহারের ক্ষেত্রে আমি একই প্যাকেজের মধ্যে ক্লাস থেকে সুরক্ষিত সদস্যদের অ্যাক্সেস করার দরকার ছিল।

এই বাস্তবায়নের পিছনে কারণগুলি কী ছিল?

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

package some.package;
public class A {
 protected void protectedMethod(){
  // do something
 }
}

package another.package;
public class B extends A{
 public void someMethod(){
  // accessible because B is a subclass of A
  protectedMethod();
 }
} 

package some.package;
public class C {
 public void anotherMethod(){
  // accessible because C is in the same package as A
  protectedMehtod();
 }
}

উত্তর:


4

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

আমার কাছে ভাল, এই ধরনের ব্যবহারের ক্ষেত্রে নির্দিষ্টটি না থেকে সাধারণ হয় এবং এটি আমার পছন্দ থেকে শুরু করে:

  1. যতটা সম্ভব কঠোর অ্যাক্সেস মডিফায়ার দিয়ে শুরু করুন, কেবল পরে প্রয়োজনীয় হিসাবে বিবেচিত হিসাবে দুর্বল (গুলি) এর অবলম্বন করুন।
  2. ইউনিট পরীক্ষাগুলি পরীক্ষিত কোডের মতো একই প্যাকেজে থাকে।

উপরের থেকে, আমি আমার অবজেক্টগুলির জন্য ডিফল্ট অ্যাক্সেস মডিফায়ারগুলি দিয়ে ডিজাইনিং শুরু করতে পারি (আমি এটি দিয়ে শুরু করব privateতবে এটি ইউনিট পরীক্ষা জটিল করে তুলবে):

public class Example {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        void doSomething() {} // default access
    }
    static class Unit2 {
        void doSomething() {} // default access
    }

    static class UnitTest {
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

সাইড নোট উপরে স্নিপেট এ, Unit1, Unit2এবং UnitTestহয় নেস্টেড মধ্যে Exampleউপস্থাপনার সরলীকরণের জন্য, কিন্তু একটি বাস্তব প্রকল্পে, আমি সম্ভবত পৃথক ফাইলে (এবং এই শ্রেণীর হবে UnitTestএমনকি একটি পৃথক ডিরেক্টরির মধ্যে )।

তারপরে, যখন কোনও প্রয়োজনীয়তা দেখা দেয়, আমি ডিফল্ট থেকে অ্যাক্সেস নিয়ন্ত্রণকে দুর্বল করে দেব protected:

public class ExampleEvolved {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        protected void doSomething() {} // made protected
    }
    static class Unit2 {
        protected void doSomething() {} // made protected
    }

    static class UnitTest {
        // ---> no changes needed although UnitTest doesn't subclass
        // ...and, hey, if I'd have to subclass... which one of Unit1, Unit2?
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

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

কম পরিবর্তন প্রয়োজন => নিরাপদ পরিবর্তন; সর্বোপরি আমি কেবল অ্যাক্সেস মডিফায়ার পরিবর্তন করেছি এবং আমি কোন পদ্ধতিগুলি Unit1.doSomething()এবং কী করে তা সংশোধন করি Unit2.doSomething()না, সুতরাং ইউনিট পরীক্ষার কোডটি পরিবর্তন ছাড়াই চালিয়ে যাওয়া আশা করা স্বাভাবিক is


5

আমি বলব এর দুটি অংশ রয়েছে:

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

এটি protectedকেবল সাবক্লাস হলে সহজ হবে না ? সত্যি কথা, দীর্ঘদিন ধরে, আমি এমন আচরণের মধ্যে ছিলাম যে এই আচরণটি
jramoyo

@ জরাজোয়ো: না, কারণ আপনার এখনও সম্মিলিত আচরণটি কোনওভাবে উপলব্ধ করা দরকার, যার অর্থ অন্য নির্দিষ্টকারী specif
জানু হুডেক

6
@jramoyo - সি # এ, protectedকেবল শ্রেণি এবং সাবক্লাস এবং internalএটি গ্রন্থাগার / প্যাকেজ-বিস্তৃত। এটি protected internalজাভা এর সমতুল্য যা আছে protected
ববসন

@ সাবসন - ধন্যবাদ, সি # বাস্তবায়ন আরও ভাল পছন্দ হিসাবে মনে হচ্ছে
জড়ময়েও

5

আইএমএইচও, জাভাতে এটি একটি খারাপ ডিজাইনের সিদ্ধান্ত ছিল।

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

তবুও, আমার নম্র মতে তাদের অন্যভাবে যাওয়া উচিত ছিল: সুরক্ষিত বলেছিলেন যে কেবল শ্রেণি এবং উপশ্রেণীর কাছে দৃশ্যমান এবং সেই প্যাকেজটি শ্রেণি, উপকلاس এবং প্যাকেজটির জন্য দৃশ্যমান।

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

আমি এবং আমার বাচ্চাদের মধ্যে আমি ব্যক্তিগত রাখি এবং আমরা প্রতিবেশীদের সাথে ভাগ করি না don't আমার এবং প্রতিবেশীদের মধ্যে আমি ব্যক্তিগত রাখি এবং আমার বাচ্চাদের সাথে ভাগ করি না এমন খুব কমই রয়েছে। :-)


0

একটি দুর্দান্ত উদাহরণ যা অবিলম্বে মাথায় আসে ইউটিলিটি ক্লাস যা প্যাকেজে প্রচুর পরিমাণে ব্যবহৃত হয় তবে আপনি পাবলিক অ্যাক্সেস চান না (পর্দার পিছনে-চিত্র-চিত্র-লোডিং-থেকে-ডিস্ক, হ্যান্ডেল-ক্রিয়েশন / ডেস্ট্রেশন ক্লাসস ইত্যাদি) ।) পরিবর্তে সবকিছু [জাভার সমতুল্য তৈরীর friend access modifier or idiomমধ্যে C++প্রত্যেক অন্যান্য বর্গ সবকিছু] স্বয়ংক্রিয়ভাবে পাওয়া যায়।


1
ইউটিলিটি ক্লাসগুলি ক্লাসগুলির আরও উদাহরণ যা তাদের সদস্যদের চেয়ে সম্পূর্ণ অভ্যন্তরীণ।
জানু হুডেক

0

সুরক্ষিত / প্যাকেজ অ্যাক্সেস মডিফায়ারের জন্য ব্যবহারের কেসগুলি সি ++ এ বন্ধুত্বপূর্ণ অ্যাক্সেস সংশোধকগুলির সাথে মিল রয়েছে ।

একটি ব্যবহারের ক্ষেত্রে মেমেন্টো প্যাটার্নটি প্রয়োগ করার সময় ।

পূর্বাবস্থায় ফিরে আসা ক্রিয়াকলাপগুলির জন্য একটি চেকপয়েন্ট হিসাবে পরিবেশন করার জন্য মেমেন্টো অবজেক্টটিকে কোনও অবজেক্টের অভ্যন্তরীণ অবস্থার অ্যাক্সেস করতে হবে it

একই প্যাকেজের মধ্যে বর্গ ঘোষণা করছেন এক , সম্ভাব্য উপায় মেমেন্টো প্যাটার্ন অর্জন করতে যেহেতু জাভা কোন হয়েছে "বন্ধু" এক্সেস পরিবর্তক।


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

@ জানহুদেক আমি আক্ষরিকভাবে বলেছি "" -> একটি <- মেমেন্টো প্যাটার্ন অর্জনের সম্ভাব্য উপায়গুলির মধ্যে একটি "
তুলিনস কর্ডোভা

এবং মেমেন্টো প্যাটার্নটি অর্জনের আর একটি সম্ভাব্য উপায় হ'ল সবকিছুকে জনসাধারণ্যে প্রকাশ করা। অর্থাৎ আমি আপনার বক্তব্য দেখতে ব্যর্থ
টমাস এডিং

-1

প্রতিসাম্য?

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


1
ধন্যবাদ, আপনার কি উদাহরণ আছে? এমন
সুরগুলি

-1

জাভার এনক্যাপসুলেশন হায়ারার্কি ভালভাবে সংজ্ঞায়িত হয়েছে:

শ্রেণি -> প্যাকেজ -> উত্তরাধিকার

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

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

Com.example.foo.bar যা সাবক্লাসিং করছে তার চেয়ে কিছু বেশি প্যাকেজের সাথে অন্য শ্রেণীর সাথে "বন্ধুত্বপূর্ণ" হতে জাভা.ইটিলে কিছু থাকার জন্য এটি ধারণাগত দৃষ্টিকোণ থেকে বোঝা যায়। পূর্ববর্তী ক্ষেত্রে ক্লাসগুলি একই লেখক, বা কমপক্ষে একই সংস্থার কোডারদের দ্বারা লিখিত হতে পারে।


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