কোড এর মতো:
public Thing[] getThings(){
return things;
}
আপনার অ্যাক্সেস পদ্ধতিটি সরাসরি অভ্যন্তরীণ ডেটা কাঠামোটি ফিরিয়ে দেওয়া ছাড়া কিছুই করছে না বলে বেশি অর্থবোধ করে না। আপনি ভাল হিসাবে শুধু ঘোষণা পারে Thing[] thingsহতে public। অ্যাক্সেস পদ্ধতির পিছনে ধারণাটি এমন একটি ইন্টারফেস তৈরি করা যা ক্লায়েন্টকে অভ্যন্তরীণ পরিবর্তনগুলি থেকে অন্তরিত করে এবং ইন্টারফেসের দ্বারা অনুমোদিত বিচক্ষণ পদ্ধতি ব্যতীত প্রকৃত ডেটা কাঠামোয় হেরফের থেকে বিরত থাকে। আপনার সমস্ত ক্লায়েন্ট কোডটি ভেঙে যখন আপনি আবিষ্কার করেছেন, আপনার অ্যাক্সেস পদ্ধতিটি এটি করেনি - এটি কেবল কোড নষ্ট। আমি মনে করি প্রচুর প্রোগ্রামাররা কোডটি লেখার প্রবণতা রাখে কারণ তারা কোথাও শিখেছিল যে অ্যাক্সেসের পদ্ধতিতে সমস্ত কিছু আবশ্যক - তবে এটি আমি ব্যাখ্যা করার কারণেই করেছি। অ্যাক্সেস পদ্ধতি কোনও উদ্দেশ্যে পরিবেশন না করে কেবল "ফর্ম অনুসরণ করুন" করার জন্য এটি করা কেবল গোলমাল।
আমি অবশ্যই আপনার প্রস্তাবিত সমাধানটি সুপারিশ করব, যা এনক্যাপসুলেশনের কয়েকটি গুরুত্বপূর্ণ লক্ষ্য পূরণ করে: ক্লায়েন্টদের একটি শক্তিশালী, বিচক্ষণ ইন্টারফেস প্রদান করা যা তাদেরকে আপনার শ্রেণীর অভ্যন্তরীণ বাস্তবায়নের বিশদ থেকে অন্তরক করে এবং তাদের অভ্যন্তরীণ ডেটা কাঠামোটি স্পর্শ করতে দেয় না আপনি যেভাবে সিদ্ধান্ত নেন তা যথাযথভাবে প্রত্যাশা করুন - "কমপক্ষে প্রয়োজনীয় বিশেষাধিকারের আইন"। আপনি যদি সিএলআর, এসটিএল, ভিসিএল এর মতো বড় জনপ্রিয় ওওপি ফ্রেমওয়ার্কগুলিতে নজর দেন তবে ঠিক সেই কারণেই আপনার প্রস্তাবিত প্যাটার্নটি ব্যাপক।
আপনার কি সবসময় করা উচিত? অগত্যা। উদাহরণস্বরূপ, যদি আপনার সহায়ক বা বন্ধু শ্রেণি থাকে যা মূলত আপনার মূল শ্রমিক শ্রেণীর একটি উপাদান এবং "সামনের মুখোমুখি" না হয় তবে এটি প্রয়োজনীয় নয় - এটি একটি ওভার্কিল যা প্রচুর অপ্রয়োজনীয় কোড যুক্ত করতে চলেছে। এবং সেই ক্ষেত্রে, আমি কোনও অ্যাক্সেস পদ্ধতি ব্যবহার করব না - এটি নির্বোধ, যেমনটি ব্যাখ্যা করা হয়েছে। কেবলমাত্র ডেটা স্ট্রাকচারটি এমনভাবে ঘোষণা করুন যা এটি ব্যবহার করে এমন প্রধান শ্রেণীর জন্য - বেশিরভাগ ভাষাগুলি এটি করার বিভিন্ন উপায়কে সমর্থন করে - friendবা এটিকে একই ফাইলটিতে প্রধান কর্মী শ্রেণি হিসাবে ঘোষণা করে ইত্যাদি
শুধুমাত্র downside আমি তোমার প্রস্তাবে দেখতে পারেন এটা এটি কোডে আরো কাজ (এবং এখন আপনি পুনরায় কোড আপনার ভোক্তা শ্রেণীর আছে চলুন - কিন্তু আপনি / যে যাহাই হউক না কেন কি ছিল।) কিন্তু যে সত্যিই একটি downside হয় না - আপনার এটি সঠিকভাবে করা দরকার এবং কখনও কখনও এটি আরও বেশি কাজ করে।
একটি ভাল প্রোগ্রামারকে যে জিনিসগুলি ভাল করে তোলে সেগুলির একটি হ'ল তারা জানে যে অতিরিক্ত কাজ কখন মূল্যবান হয় এবং কখন তা হয় না। দীর্ঘমেয়াদে এখন অতিরিক্ত রাখলে ভবিষ্যতে বড় লভ্যাংশ প্রদান করা হবে - যদি এই প্রকল্পে না হয় তবে অন্যকেও। সঠিকভাবে কোড করতে শিখুন এবং এটি সম্পর্কে আপনার মাথা ব্যবহার করুন, কেবল রোবটিকভাবে নির্ধারিত ফর্মগুলি অনুসরণ করবেন না।
নোট করুন যে অ্যারেগুলির চেয়ে আরও জটিল সংগ্রহগুলি কেবল অভ্যন্তরীণ ডেটা স্ট্রাকচার অ্যাক্সেসের জন্য আরও তিনটি পদ্ধতির প্রয়োগের জন্য এনক্লোজিং ক্লাসের প্রয়োজন হতে পারে।
যদি আপনি একটি ধারণকৃত শ্রেণীর মাধ্যমে একটি সম্পূর্ণ ডেটা স্ট্রাকচার উন্মোচন করেন, আইএমওটি আপনাকে অবশ্যই সেই ক্লাসটি কেন মোটামুটিভাবে encapsated করা উচিত তা চিন্তা করতে হবে, যদি এটি কেবল একটি নিরাপদ ইন্টারফেস সরবরাহ না করা হয় - "একটি র্যাপার ক্লাস"। আপনি বলছেন যে সেটির জন্য ধারণক্ষম শ্রেণীর উপস্থিতি নেই - তাই সম্ভবত আপনার নকশাটি সম্পর্কে সঠিক কিছু নেই। আপনার ক্লাসগুলি আরও বিচক্ষণ মডিউলগুলিতে ভাঙ্গার এবং সেগুলি স্তর বিবেচনা করার বিষয়টি বিবেচনা করুন।
একটি শ্রেণীর একটি স্পষ্ট এবং বিচক্ষণ উদ্দেশ্য থাকতে হবে এবং সেই কার্যকারিতাটি সমর্থন করার জন্য একটি ইন্টারফেস সরবরাহ করতে হবে - আর নেই। আপনি একসাথে নয় এমন জিনিসগুলি একসাথে বান্ডিল করার চেষ্টা করছেন। যখন আপনি এটি করেন, প্রতিবার পরিবর্তনটি প্রয়োগ করতে হলে জিনিসগুলি ভঙ্গ হবে। আপনার ক্লাস যত ছোট এবং তত বেশি বিচক্ষণ, চারপাশে জিনিসগুলি পরিবর্তন করা আরও সহজ: লেগো চিন্তা করুন।
get(index),add(),size(),remove(index), এবংremove(Object)। প্রস্তাবিত কৌশলটি ব্যবহার করে, এই অ্যারেলিস্টযুক্ত শ্রেণিতে কেবলমাত্র অভ্যন্তরীণ সংগ্রহে ডেলিগেশন দেওয়ার জন্য পাঁচটি পাবলিক পদ্ধতি থাকতে হবে। প্রোগ্রামটিতে এই শ্রেণীর উদ্দেশ্যটি সম্ভবত এই অ্যারেলিস্টকে encapsulate না করে বরং অন্য কিছু করছে। অ্যারেলিস্টটি কেবল একটি বিশদ। [...]