আপনি কোনও অবজেক্ট পদ্ধতির মধ্যে থেকে কীভাবে অবজেক্টের বৈশিষ্ট্যগুলি অ্যাক্সেস করবেন? [বন্ধ]


96

গিটার / সেটার পদ্ধতি নয় এমন কোনও অবজেক্ট পদ্ধতির মধ্যে থেকে কোনও বস্তুর বৈশিষ্ট্য অ্যাক্সেস করার "পিউরিস্ট" বা "সঠিক" উপায় কী?

আমি জানি যে অবজেক্টের বাইরে থেকে আপনার একটি গেটর / সেটার ব্যবহার করা উচিত তবে এর মধ্যে থেকে আপনি কেবল এটি করবেন:

জাভা:

String property = this.property;

পিএইচপি:

$property = $this->property;

বা আপনি কি করবেন:

জাভা:

String property = this.getProperty();

পিএইচপি:

$property = $this->getProperty();

আমার জাভা একটু দূরে থাকলে আমাকে ক্ষমা করুন, আমি জাভাতে প্রোগ্রামিং করে এক বছর হয়ে গেল ...

সম্পাদনা:

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

উত্তর:


62

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


জাভাতে ভুল ব্যবহারের উদাহরণ হিসাবে সম্পত্তিটির মূল্য নির্ধারণ করা ব্যতীত কোনও সেটারে আর কিছুই করছে না।
euphoria83

4
@ euphoria83 সম্ভবত, তবে এটি ঘটতে বাধা দেয় না।
গ্রেগ হারলম্যান

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

43

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

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


26

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

মূলত, আপনার কাছে gettersএবং settersপ্রতিটি ব্যক্তিগত ক্ষেত্রের জন্য, আপনি সেই ক্ষেত্রগুলিকে জনসাধারণের মতো ভাল করে তুলছেন। আপনি যে ক্লাসকে ডেকে আনে তার কোনও প্রভাব নেই এমন একটি ব্যক্তিগত ক্ষেত্রের ধরণটি পরিবর্তন করতে আপনি খুব কঠোর চাপ দিয়ে চলেছেন getter

তদুপরি, দৃ strictly়তার সাথে ওও দৃষ্টিকোণ থেকে, বস্তুগুলি তাদের (আশাকরি) একক দায়িত্বের সাথে সম্পর্কিত বার্তাগুলি (পদ্ধতিগুলি) তে সাড়া দেওয়া উচিত। বিপুল সংখ্যাগরিষ্ঠ gettersএবং settersতাদের উপাদান উপাদানগুলির জন্য অর্থবোধ করে না; Pen.dispenseInkOnto(Surface)আমার চেয়ে বেশি বোঝায় Pen.getColor()

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

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


19

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

এখন আসুন আমরা বলি যে আপনার অবজেক্টে একটি প্রাইভেট ইন্টিজার কাউন্টার রয়েছে যা নামটি কল করার সময় গণনা করে। আপনি অবজেক্টের অভ্যন্তর থেকে get পদ্ধতিটি ব্যবহার না করতে চাইতে পারেন কারণ এটি একটি অবৈধ গণনা তৈরি করে।


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

আপনি যদি গেটরে কিছু ধরণের বুলিয়ান যুক্ত করেন তবে: পিএইচপি: পাবলিক ফাংশন getName ($ আউটডোর কল = সত্য) {যদি ($ আউটক্যাল) {$ এই-> ইনক্রিমেন্টনামকেল্ট (); } ফেরত} এই-> নাম; then এবং তারপরে অবজেক্টের মধ্যে থেকেই, আপনি নামটি ডাকলে, আপনি এটিকে বাড়ানো থেকে বিরত রাখতে পারেন: পিএইচপি: $ নাম = $ এটি-> getName (মিথ্যা); আমি কি এখানে ওভারবোর্ডে যাচ্ছি?
সে.এম.সি.সি.ক্রোলোহ

14

পিএইচপি উপায়ে যাদু পদ্ধতি সহ এই হ্যান্ডেলের জন্য একটি অগণ্য উপলব্ধ করা হয় __getএবং __set, কিন্তু আমি স্পষ্ট getters এবং setters পছন্দ করে। কারণটা এখানে:

  1. বৈধতা সেটারগুলিতে স্থাপন করা যেতে পারে (এবং এই বিষয়টির জন্য যাত্রীরা)
  2. ইন্টেলিজেন্স সুস্পষ্ট পদ্ধতিগুলির সাথে কাজ করে
  3. কোনও সম্পত্তি কেবল পঠনযোগ্য, কেবল লিখতে বা পঠন-লেখার প্রশ্ন নেই
  4. ভার্চুয়াল বৈশিষ্ট্য (যেমন গণনা করা মান) পুনরুদ্ধার করা নিয়মিত বৈশিষ্ট্যগুলির সমান দেখায়
  5. আপনি সহজেই এমন কোনও বস্তুর সম্পত্তি সেট করতে পারেন যা বাস্তবে কখনও কোথাও সংজ্ঞায়িত হয় না, যা পরে অনির্ধারিত হয়ে যায়

13

আমি কি এখানে ওভারবোর্ডে যাচ্ছি?

সম্ভবত;)

অন্য পদ্ধতিটি হ'ল বাস্তবায়ন (ক্যাচিং / ডিবি / ইত্যাদি) করার জন্য একটি ব্যক্তিগত / সুরক্ষিত পদ্ধতি এবং এর জন্য একটি পাবলিক মোড়কে ব্যবহার করা যা গণনা বাড়িয়ে তোলে:

পিএইচপি:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

এবং তারপরেই বস্তুর মধ্যে থেকে:

পিএইচপি:

$name = $this->_getName();

এইভাবে আপনি সেই প্রথম যুক্তিটি অন্য কোনও কিছুর জন্য এখনও ব্যবহার করতে পারেন (যেমন সম্ভবত এখানে ক্যাশেড ডেটা ব্যবহার করা হয়েছে কিনা তা জন্য পতাকা পাঠানো)।


12

আমি অবশ্যই এখানে পয়েন্টটি মিস করছি, আপনি কেন সেই বস্তুর কোনও সম্পত্তি অ্যাক্সেস করার জন্য কোনও জিনিসের অভ্যন্তরে গেটর ব্যবহার করবেন?

এটিকে তার উপসংহারে নিয়ে যাওয়ার সাথে সাথে প্রাপককে একজন গিটারকে কল করা উচিত, যা গ্রাহককে কল করতে হবে।

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


আমি আপনাকে একই মতামত দিয়ে চালিত হয়েছিলাম ... এছাড়াও এটির উত্তর দেওয়া হয়নি বন্ধ নয়;)
ডিম ভ্যান

8

পিউরিস্ট ওও উপায় হ'ল না জিজ্ঞাসা করুন না বলুন পদ্ধতির ব্যবহার করে উভয়কে এড়িয়ে চলুন এবং ডেমিটারের আইন অনুসরণ করুন ।

বস্তুর সম্পত্তির মান পাওয়ার পরিবর্তে, যা দুটি শ্রেণীর সাথে শক্তভাবে মিলিত হয়, বস্তুকে প্যারামিটার হিসাবে ব্যবহার করুন যেমন

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

যেখানে সম্পত্তিটি একটি দেশীয় টাইপ, যেমন ইন্ট, কোনও অ্যাক্সেস পদ্ধতি ব্যবহার করুন, প্রোগ্রামিং ডোমেন নয় সমস্যা ডোমেনের জন্য এটির নাম দিন।

  doSomethingWithProperty( this.daysPerWeek() ) ;

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


8

অ্যাক্সেসরের পদ্ধতিগুলি ব্যবহার করা আরও ভাল, এমনকি বস্তুর মধ্যেও। এই মুহূর্তে আমার মনে যে বিষয়গুলি আসে তা এখানে:

  1. এটি অবজেক্টের বাইরে থেকে তৈরি অ্যাক্সেসের সাথে ধারাবাহিকতা বজায় রাখার স্বার্থে করা উচিত।

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


8

যদি আপনি "পিউরিস্ট" দ্বারা "সর্বাধিক এনক্যাপসুলেশন" বলতে চান তবে আমি সাধারণত আমার সমস্ত ক্ষেত্রকে ব্যক্তিগত হিসাবে ঘোষণা করি এবং তারপরে ক্লাসের মধ্যে থেকেই "this.field" ব্যবহার করি। সাবক্লাস সহ অন্যান্য ক্লাসের জন্য, আমি গ্রাহকগণকে ব্যবহার করে উদাহরণের স্থিতিতে প্রবেশ করি।


7

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


7

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

.NET বিকাশকারীরা এটি প্রয়োগ করতে স্বয়ংক্রিয় বৈশিষ্ট্যগুলি ব্যবহার করতে পারে যেহেতু আপনি ডিজাইনের সময় ব্যাকিং ভেরিয়েবলগুলি দেখতেও পান না।


7

এটা নির্ভর করে. এটি অন্য যে কোনও কিছুর চেয়ে স্টাইলের সমস্যা, এবং কোনও কঠোর নিয়ম নেই।


7

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


7

যদি আমি সম্পত্তিটি সম্পাদনা না করি তবে আমি একটি সর্বজনীন পদ্ধতি ব্যবহার করব get_property()না যদি না এটি কোনও বিশেষ অনুষ্ঠান যেমন মাইএসকিউএলআই অবজেক্টের মধ্যে অন্য কোনও অবজেক্টের মধ্যে থাকে যেখানে আমি কেবল সম্পত্তিটি প্রকাশ করি এবং এটি হিসাবে উল্লেখ করি $obj->object_property

বস্তুর ভিতরে এটি আমার জন্য সর্বদা $ এটি-> সম্পত্তি।


5

ঠিক আছে, এটি সি # 3.0 প্রোপার্টি'র ডিফল্ট প্রয়োগের সাথে মনে হয়, সিদ্ধান্তটি আপনার জন্য নেওয়া হয়; আপনার সম্পত্তিটি (সম্ভবত ব্যক্তিগত) সম্পত্তি সেটারের সাহায্যে সেট করতে হবে।

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


5

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

অন্যদিকে, আমি ব্যক্তিগতভাবে পাই যে গেটর / সেটার ব্যবহার করে কোডটি পড়া এবং পরে ডিবাগ করা সহজ হয়।


4

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

বিপরীত কেসটি তৈরি করা যেতে পারে যে আপনি যদি গেটর / সেটার ব্যবহার করেন এবং কেউ যদি গিটার / সেটারটি পরিবর্তন করেন তবে তাদের সমস্ত স্থানের বিশ্লেষণ করতে হবে গিটার এবং সেটারটি অভ্যন্তরীণভাবে ব্যবহার করছে যাতে এটি কিছু বিভ্রান্ত হয় কিনা তা দেখার জন্য।

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