জাভা কেন কিছু ক্লাসের সাথে এনক্যাপসুলেশন ব্যবহার করে না?

Question

আমার প্রশ্নটি ক্লাসের সাথে সম্পর্কিত System.inএবং System.out(স্ট্যান্ডার্ড লাইব্রেরিতে থাকা অন্যদের মতো হতে পারে)। তা কেন? ওওপি-তে কি এটি খারাপ অভ্যাস নয়? এটি ব্যবহার করা উচিত নয়: System.getIn()এবং System.getOut()? আমি সবসময় এই প্রশ্ন ছিল এবং আমি আশা করি আমি এখানে একটি ভাল উত্তর খুঁজে পেতে পারেন।

Answer 1

শ্রেণীর মধ্যে inএবং outক্ষেত্রগুলির জন্য সংজ্ঞাটি হ'ল System:

public final static PrintStream out;
public final static InputStream in;

এগুলি ধ্রুবক। এগুলিও বস্তু হতে পারে তবে তারা ধ্রুবক। এটি ম্যাথ ক্লাসের মতো একই রকম:

public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;

বা বুলিয়ান শ্রেণিতে:

public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);

বা রঙ শ্রেণিতে:

public final static Color white     = new Color(255, 255, 255);
public final static Color black     = new Color(0, 0, 0);
public final static Color red       = new Color(255, 0, 0);

পরিবর্তিত হয় না এমন পাবলিক ধ্রুবক অ্যাক্সেস করার সময়, এটি encapsulate করার একটি উল্লেখযোগ্য সুবিধা নেই - ধারণাগতভাবে বা পারফরম্যান্স ভিত্তিক। এটা ওইখানে. এটি পরিবর্তন হবে না।

তার মাঝে কোনো সত্যিকারের পার্থক্য নেই Color.whiteএবং System.out।

Comments

ভাল, আমি এটি সেভাবে দেখিনি, তারা ধ্রুবক বস্তু। এটি একটি বেশ ভাল ব্যাখ্যা।

— Clawdidr

আজকের জাভাতে @ ক্লাডিডিডার, এটি ধরে রাখার জন্য কেউ ব্যবহার করার কথা বিবেচনা করতে পারেনenum ... যদিও enumজাভা 1.5 এর সাথে নতুন ছিল (1.0 দিনের মধ্যে কোনও বিকল্প নয়)।

কৌতূহলের বাইরে (নিজে নিজে জাভা বিকাশকারী নন): final staticএবং এর মধ্যে পার্থক্য রয়েছে static finalকি? যদি তাই হয়, এটা কি?

— মার্জান ভেনেমা

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

:) এবং মাইকেলকে ধন্যবাদ, সাড়া দেওয়ার জন্য সময়টি এবং লিঙ্কটির জন্য।

— মার্জন ভেনেমা

Answer 2

আসল কারণ হ'ল এটি একটি উত্তরাধিকার সংক্রান্ত সমস্যা issue System.in,out,errধ্রুবক জাভা 1.0 অংশ ... এবং সম্ভবত অনেক আরও ফিরে ছিল। এই সময়টি পরিষ্কার হয়ে গেল যে ডিজাইনে সমস্যা ছিল, এটি ঠিক করতে খুব দেরী হয়েছিল। System.setIn,setOut,setErrজাভা ১.১- এ পদ্ধতিগুলি যুক্ত করা এবং তারপরে ভাষার স্পেসিফিকেশন সমস্যাগুলি ^{1 এর} সাথে ডিল করা তাদের পক্ষে সবচেয়ে ভাল ছিল ।

এটির স্থির System.arraycopyপদ্ধতি কেন যার নাম জাভা নামকরণ কনভেনশন লঙ্ঘন করে তা ইস্যুটির সাথে সমান ।

---

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

যাইহোক, আমি এই যুক্তির সাথেও যুক্ত করতে পারি যে জিনিসগুলি করার বর্তমান পদ্ধতি অনেক ক্ষেত্রে আরও বেশি সুবিধাজনক ।

---

^{1 - এটি আকর্ষণীয় বিষয় যে System.in,out,errভেরিয়েবলগুলি জেএলএসে "বিশেষ শব্দার্থবিজ্ঞান" হিসাবে বিশেষ উল্লেখ পেয়ে থাকে। জেএলএস বলে যে আপনি যদি কোনও finalক্ষেত্রের মান পরিবর্তন করেন তবে আচরণটি অপরিজ্ঞাত হয় ... এই ক্ষেত্রগুলির ক্ষেত্রে বাদে ।}

Answer 3

আমি বিশ্বাস করি আউট অবজেক্টটি অপরিবর্তনীয়, যা পাবলিক ফাইনাল স্ট্যাটিক ফিল্ডে রাখার জন্য এটি কোনওরকম নিরাপদ করে তোলে (এটি বিতর্কযোগ্য)।

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

Comments

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

— বিল কে

@ বিলক: হ্যাঁ, এটি ডেমিটারের আইন হিসাবেও পরিচিত (যদিও এটি কোনও আইন নয় বরং নির্দেশিকা)।

— sleske

Answer 4

এই উত্তরটি দুর্দান্ত এবং সত্য।

আমি যুক্ত করতে চেয়েছিলাম যে কিছু ক্ষেত্রে ব্যবহারের স্বার্থে আপস করা হয়েছিল।

স্ট্রিং প্রকারের অবজেক্টগুলি নতুন, ইভেন্ট ছাড়াই ইনস্ট্যান্ট করা যায় যখন স্ট্রিং কোনও আদিম না থাকে:

String s = "Hello";

স্ট্রিং একটি অ-আদিম হিসাবে, এটি ইনস্ট্যান্ট করা উচিত:

String s = new String("Hello");          // this also works 

তবে সংকলকটি সংক্ষিপ্ত, কম ওও বিকল্পের জন্য অনুমতি দেয় কারণ স্ট্রিং এপিআই-র মধ্যে সবচেয়ে বেশি ব্যবহৃত ক্লাস।

এছাড়াও অ্যারেগুলি অ-ওও পদ্ধতিতে শুরু করা যেতে পারে:

int i[] = {1,2,3};

যথেষ্ট অদ্ভুত, একটি বস্তু হয় বর্গ বা একটি অ্যারের উদাহরণ । অর্থ অ্যারেগুলি সম্পূর্ণ পৃথক শ্রেণীর।

অ্যারেগুলির একটি lengthসার্বজনীন ক্ষেত্র রয়েছে যা ধ্রুবক নয়। এছাড়াও শ্রেণীর অ্যারেতে কোনও ডকুমেন্টেশন নেই এটির উদাহরণ। (অ্যারে ক্লাস বা java.reflect.Array এর সাথে বিভ্রান্ত না করা)।

int a = myArray.length;    // not length()

Comments

আপনি বিভিন্ন জিনিস - new String("Hello")সর্বদা একটি নতুন স্ট্রিং অবজেক্ট তৈরি করবে। String s = "Hello";ইন্টার্নযুক্ত অবজেক্ট ব্যবহার করার সময় । তুলনা করুন: "Hello" == "Hello"সত্য হতে পারে, যদিও new String("Hello") == new String("Hello")সর্বদা মিথ্যা। সেখানে কম্পাইল সময় অপ্টিমাইজেশান জাদু প্রথম যে সঙ্গে সম্ভব নয় ঘটছে new String("Hello")। দেখুন en.wikipedia.org/wiki/String_interning

@ মিশেলটি আমি কেবলমাত্র পরিপূর্ণতার জন্য, অ্যারেগুলিতে কিছু অতিরিক্ত বৌদ্ধিকতা যুক্ত করেছি।

— তুলাইনস কর্ডোভা

@ তারিক আমি "স্ট্রিং একটি অ-আদিম হওয়ায় এটিকে তত্ক্ষণাতিত করা উচিত: String s = new String("Hello");" যা আপত্তি জানিয়েছিল তা ভুল is সংক্ষিপ্ত বিকল্প ( String s = "Hello";) স্ট্রিং ইন্টার্নিংয়ের কারণে আরও সঠিক।

সাথে String, কোনও "আরও সঠিক" বিকল্প নেই। দুটোই সঠিক. যদিও মাইকেলটি যেমন বলেছে, স্ট্রিং ইন্টার্নিংয়ের কারণে সংক্ষিপ্ততরটি পছন্দ করা হয়।

— অ্যান্ড্রেস এফ।

@AndresF। আমি "কম ওও" এর জন্য "কম সঠিক" পরিবর্তন করেছি।

— Tulains কর্ডোভা