কেন গেটার এবং সেটার / এক্সেসর ব্যবহার করবেন?

1540

গিটারস এবং সেটটারগুলি ব্যবহার করার সুবিধা কী - যা কেবলমাত্র পাওয়া যায় এবং সেট হয় - পরিবর্তে এই ভেরিয়েবলগুলির জন্য সর্বজনীন ক্ষেত্রগুলি ব্যবহার করার পরিবর্তে?

যদি গেটার্স এবং সেটটাররা কেবল সরল গেট / সেটের চেয়ে বেশি কিছু করে থাকে তবে আমি এটি খুব দ্রুত খুঁজে বের করতে পারি, তবে আমি কীভাবে 100% স্পষ্ট নই:

public String foo;

এর চেয়ে খারাপ কি:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

যদিও প্রাক্তনটি অনেক কম বয়লারপ্লেট কোড নেয়।

java  oop  setter  getter  abstraction 
— ডিন জে
সূত্র
6
@Dean জে: অন্যান্য অনেক প্রশ্নের সাথে সদৃশ: stackoverflow.com/search?q=getters+setters
— আসফ
8
অবশ্যই, উভয়ই সমানভাবে খারাপ যখন বস্তুর কোনও পরিবর্তনের জন্য কোনও সম্পত্তির প্রয়োজন হয় না। আমি বরং সমস্ত কিছু ব্যক্তিগত করে তুলব এবং তারপরে দরকারী হলে গেটার যুক্ত করব এবং প্রয়োজনে সেটারগুলিও যুক্ত করব।
— টর্দেক
26
গুগল "অ্যাক্সেসররা মন্দ are"
— ওএমজি পনিস
34
"অ্যাক্সেসরগুলি দুষ্কর" যদি আপনি ঘটনামূলক কোড বা অপরিবর্তনীয় বস্তুগুলি লেখেন। যদি আপনি রাষ্ট্রীয় পরিবর্তনযোগ্য অবজেক্টগুলি লিখতে থাকেন তবে সেগুলি বেশ প্রয়োজনীয়।
— ক্রিশ্চান হেইটার
18
বলুন, জিজ্ঞাসা করবেন না। pragprog.com/articles/tell-dont-ask
— ডেভ জার্ভিস

উত্তর:

980

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

আমি যে কারনে সচেতন তা এখানে রইল:

  • সম্পত্তি পেতে বা সেট করার সাথে সম্পর্কিত আচরণের সজ্জিত - এটি অতিরিক্ত কার্যকারিতা (বৈধকরণের মতো) পরে আরও সহজে যুক্ত হতে দেয়।
  • বিকল্প উপস্থাপনা ব্যবহার করে সম্পত্তি প্রকাশ করার সময় সম্পত্তির অভ্যন্তরীণ প্রতিনিধিত্ব লুকিয়ে রাখা।
  • আপনার সর্বজনীন ইন্টারফেসটিকে পরিবর্তন থেকে অন্তরকরণ - বিদ্যমান গ্রাহকদের প্রভাবিত না করে বাস্তবায়ন পরিবর্তিত হওয়ার সময় সর্বজনীন ইন্টারফেসকে স্থির থাকতে দেয়।
  • সম্পত্তিটির আজীবন এবং মেমরি পরিচালনা (নিষ্পত্তি) শব্দার্থবিজ্ঞান নিয়ন্ত্রণ করা - অ-পরিচালিত মেমরি পরিবেশে (যেমন সি ++ বা উদ্দেশ্য-সি) বিশেষত গুরুত্বপূর্ণ।
  • রানটাইমের সময় যখন কোনও সম্পত্তি পরিবর্তিত হয় তার জন্য একটি ডিবাগিং ইন্টারসেপশন পয়েন্ট সরবরাহ করা - যখন কোনও সম্পত্তি কোনও নির্দিষ্ট মানে পরিবর্তিত হয় তখন ডিবাগিং কিছু ভাষায় এটি ব্যতীত বেশ কঠিন হতে পারে।
  • প্রপার্টি গেটার / সেটটারদের বিরুদ্ধে পরিচালনার জন্য নকশাকৃত লাইব্রেরিগুলির সাথে উন্নত আন্তঃক্রিয়াশীলতা - উপহাস, সিরিয়ালাইজেশন এবং ডাব্লুপিএফ মাথায় আসে।
  • সম্পত্তি কীভাবে আচরণ করে এবং গিটার / সেটার পদ্ধতিগুলিকে ওভাররাইড করে উন্মুক্ত করে কীভাবে তার উত্তোলনকারীদের উত্তরাধিকারীদের অনুমতি দেওয়া হচ্ছে।
  • গেটর / সেটারকে মানগুলির চেয়ে ল্যাম্বডা এক্সপ্রেশন হিসাবে ঘুরে বেড়াতে দেওয়া হচ্ছে।
  • গ্রাহকরা এবং সেটটাররা বিভিন্ন অ্যাক্সেস স্তরের অনুমতি দিতে পারে - উদাহরণস্বরূপ পাওয়াটি পাবলিক হতে পারে তবে সেটটি সুরক্ষিত হতে পারে।
— LBushkin
সূত্র
59
+1 টি। কেবল যোগ করতে: অলস লোডিংয়ের অনুমতি দেওয়া হচ্ছে। লেখার অনুমতি অনুলিপি।
— নিউবিজেড
6
@ বারজারেফ: আমি বিশ্বাস করি যে publicঅ্যাকসেসর পদ্ধতিগুলি কোড নকল সৃষ্টি করে এবং তথ্য প্রকাশ করে। মার্শেলিংয়ের জন্য পাবলিক অ্যাক্সেসরগুলি প্রয়োজনীয় নয় (সিরিয়ালাইজেশন)। কিছু ভাষায় (জাভা), publicঅ্যাক্সেসরগুলি নির্ভর ক্লাস না ভেঙে রিটার্নের ধরন পরিবর্তন করতে পারে না get তদুপরি, আমি বিশ্বাস করি তারা ওও নীতির বিপরীতে চলে। আরও দেখুন: স্ট্যাকওভারফ্লো.com
— ডেভ জার্ভিস
15
@ এসবিআই: একটি জিনিস যা সম্পত্তি সেটটার ব্যবহার করে কেনা হয়, এমনকি একটি ভাল নকশাকৃত কাঠামোর মধ্যেও, কোনও সম্পত্তি পরিবর্তিত হলে কোনও বস্তুকে অন্যকে অবহিত করার ক্ষমতা।
— সুপারক্যাট
22
@ সুপের্যাট: তবে আমি সাধারণভাবে জনসাধারণের ডেটা প্রচার করি না। অন্যান্য অবজেক্টের বিজ্ঞপ্তিটি কেবলমাত্র (আরও কম বা কম) পাবলিক ডেটা ফিল্ডের সাথে নিছক ডেটা ধারকটিতে একটি উল্লেখযোগ্য বিমূর্ততা সরবরাহ করার বাস্তব পদ্ধতিগুলি থেকে করা যেতে পারে। পরিবর্তে plane.turnTo(dir); plane.setSpeed(spd); plane.setTargetAltitude(alt); plane.getBreaks().release();আমি বলতে চাই plane.takeOff(alt)। বিমানটি takingOffমোডে রাখার জন্য অভ্যন্তরীণ ডেটা ক্ষেত্রগুলি কী পরিবর্তন করতে হবে তা আমার উদ্বেগের কিছু নয়। এবং অন্যান্য কী কী অবজেক্টস ( breaks) পদ্ধতিটি জানায় আমি তাও জানতে চাই না।
— এসবিআই
8
@ বেনলি: অন্যভাবে কীভাবে বলতে হয় তা আমি সত্যিই জানি না। "অ্যাক্সেসরগুলি" "গেটার / সেটার্স" এর প্রতিশব্দ, এবং আমার প্রথম দুটি মন্তব্যে আমি ব্যাখ্যা করেছি যে সেগুলি কেন "ওওপি" শব্দটির অপব্যবহার। আপনার যদি এটিতে পৌঁছানোর দরকার হয় এবং সরাসরি রাজ্যটিকে চালিত করতে হয় তবে এটি শব্দটির ওওপি অর্থে কোনও বিষয় নয়।
— sbi
480

কারণ এখন থেকে 2 সপ্তাহ (মাস, বছর) যখন আপনি বুঝতে পারছেন যে আপনার সেটারের জন্য মান নির্ধারণের চেয়ে আরও বেশি কিছু করা দরকার , আপনি বুঝতে পারবেন সম্পত্তিটি 238 অন্যান্য শ্রেণিতে সরাসরি ব্যবহৃত হয়েছে :-)

— ChssPly76
সূত্র
84
আমি বসে বসে 500k লাইনের অ্যাপ্লিকেশনটি দেখছি যেখানে এটির কখনই প্রয়োজন ছিল না। এটি বলেছিল, যদি এটির একবার প্রয়োজন হয় তবে এটি রক্ষণাবেক্ষণের দুঃস্বপ্নের কারণ হতে শুরু করবে। আমার জন্য একটি চেকমার্কের জন্য যথেষ্ট ভাল।
— ডিন জে
20
আমি কেবল আপনাকে এবং আপনার অ্যাপটিকে -র্ষা করতে পারি :-) এটি বলেছে, এটি আপনার সফ্টওয়্যার স্ট্যাকের উপরও নির্ভর করে। ডেল্ফি, উদাহরণস্বরূপ (এবং সি # - আমি মনে করি?) আপনাকে প্রথম শ্রেণির নাগরিক হিসাবে বৈশিষ্ট্যগুলি সংজ্ঞায়িত করতে দেয় যেখানে তারা সরাসরি প্রাথমিকভাবে কোনও ক্ষেত্রটি পড়তে / লিখতে পারে তবে - আপনার প্রয়োজন হওয়া উচিত - এটি গেটর / সেটার পদ্ধতিগুলির মাধ্যমেও করুন। সুবিধাজনক জাভা, হায়, জবাবিয়ান স্ট্যান্ডার্ডের কথা উল্লেখ না করা যা আপনাকে গেটার / সেটটারগুলিও ব্যবহার করতে বাধ্য করে।
— ChssPly76
14
এটি প্রকৃতপক্ষে অ্যাক্সেসর ব্যবহারের জন্য একটি ভাল কারণ, এখন অনেক প্রোগ্রামিং এনভায়রনমেন্ট এবং সম্পাদকরা এখন রিফ্যাক্টরিংয়ের জন্য সমর্থন সরবরাহ করে (আইডিইতে বা ফ্রি অ্যাড-ইন হিসাবে) যা সমস্যার প্রভাব কিছুটা কমিয়ে দেয়।
— এল বুশকিন
62
প্রাক-পরিপক্ক অপ্টিমাইজেশনের মতো শোনাচ্ছে
— 21
41
গেটার্স এবং সেটটারগুলি প্রয়োগ করতে হবে কিনা তা আপনি যখন ভাবছেন তখন আপনার যে প্রশ্নটি জিজ্ঞাসা করা উচিত তা হ'ল: কোনও শ্রেণির ব্যবহারকারীদের কেন ক্লাসের অভ্যন্তরে প্রবেশের প্রয়োজন হবে না? তারা এটি সরাসরি করে বা পাতলা সিউডো স্তর দ্বারা রক্ষা করে কিনা তা সত্য নয় - ব্যবহারকারীদের যদি প্রয়োগের বিশদটি অ্যাক্সেস করতে হয় তবে এটি এমন একটি লক্ষণ যা ক্লাসটি যথেষ্ট পরিমাণ বিমূর্ততা সরবরাহ করে না। আরও দেখুন এই মন্তব্যটি ।
— sbi
357

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

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

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

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

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

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

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

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

ক্লায়েন্ট : "আমি এই শ্রেণীর কোনও বস্তুর সাথে কী করতে পারি?"
ডিজাইনার : "আপনি বেশ কয়েকটি চলক পড়তে এবং লিখতে পারেন।"
ক্লায়েন্ট : "ওহ ... শীতল, আমার ধারণা?"

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

— আর মার্টিনহো ফার্নান্দেস
সূত্র
12
দুর্দান্ত উত্তর (+1)। আমার একমাত্র সমালোচনা হ'ল চূড়ান্ত অনুচ্ছেদে "বৈধতা" প্রথম কয়েকটিতে "বৈধতা" থেকে কীভাবে পৃথক হয়েছিল (যা আপনি পরবর্তী ক্ষেত্রে ছুঁড়েছিলেন তবে প্রাক্তন হিসাবে প্রচার করেছিলেন) তা জানতে বেশ কয়েকটি পাঠ গ্রহণ আমার কাছে হয়েছিল; শব্দটি সামঞ্জস্য করা সেই ক্ষেত্রে সহায়তা করতে পারে।
— অরবিটে
14
এটি একটি দুর্দান্ত উত্তর তবে হায় আফসান যুগটি "তথ্য গোপন করা" কী বা এটি কী তা ভুলে গেছে। তারা কখনও অপরিবর্তনীয়তা এবং সর্বাধিক চতুর জন্য তাদের সন্ধানে পড়েনি, এমন কোনও রাষ্ট্র-রূপান্তর-চিত্রটি আঁকেনি যে কোনও জিনিসের আইনি অবস্থা কী এবং এভাবে কী ছিল না তা সংজ্ঞায়িত করে।
— ড্যারেল টিগু
2
একটি মূল পর্যবেক্ষণ হ'ল সেটারদের তুলনায় গেটররা অনেক বেশি কার্যকর। একজন প্রাপ্ত ব্যক্তি একটি গণিত মান, বা একটি ক্যাশেড গণিত মান প্রদান করতে পারে। সমস্ত সেটার কিছু করতে পারে যা privateক্ষেত্র পরিবর্তন করার চেয়ে কিছু বৈধতা । যদি কোনও শ্রেণীর কোনও সেটটার না থাকে তবে এটিকে অপরিবর্তনীয় করে তোলা সহজ।
— রায়েডওয়াল্ড
7
এর, আমি অনুমান করি আপনি ক্লাস ইনগ্রানেন্ট কী তা জানেন না। যদি এটি একটি তুচ্ছ-কাঠামো কাঠামো হয়, তবে এর বেশিরভাগ অর্থ হ'ল এটির সমর্থনকারীদের আগমন রয়েছে এবং মনের কথা বাদ দিয়ে কেউ এটিকে নকশা করতে পারবেন না। "একটি ত্রুটি ছিল, একটি সদস্য ভুলভাবে আপডেট হয়েছিল" " "সদস্যের আপডেট শ্রেণি আক্রমণকারীদের লঙ্ঘন করেছে" এর মতো আরও বেশ কিছুটা পড়ে। একটি ভাল ডিজাইন করা শ্রেণি ক্লায়েন্ট কোডটিকে তার আক্রমণকারীদের লঙ্ঘন করতে দেয় না।
— আর মার্টিনহো ফার্নান্দিস
5
'1 বোবা ডেটা ধারকরা বোবা তথ্যধারীদের মতো হওয়া উচিত 'দুর্ভাগ্যক্রমে, প্রত্যেকে আজকাল বোবা ডেটা ধারকদের চারপাশে সমস্ত কিছু ডিজাইন করে বলে মনে হচ্ছে, এবং প্রচুর ফ্রেমওয়ার্ক এমনকি এটির প্রয়োজনও রয়েছে ...
— জোয়ারি হেন্ড্রিকেক্স
92

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

বলুন যে আপনি কয়েকশ লাইন কোডের সন্ধান করছেন এবং আপনি এটির মাধ্যমে এসেছেন:

person.name = "Joe";

যতক্ষণ না আপনি তার সেটটারটি উপলব্ধি করেন এটি এটিকে একটি সুন্দরভাবে কোডের টুকরো। এখন, আপনি সেই সেটারটি অনুসরণ করেন এবং দেখতে পান যে এটি person.firstName, person.lastName, person.isHman, person.hasReallyCommonFrstName সেট করে এবং person.update () কে ডাকে, যা ডেটাবেজে একটি জিজ্ঞাসা প্রেরণ করে, ইত্যাদি, ওহ, এটি যেখানে আপনার স্মৃতি ফুটো হচ্ছে।

স্থানীয় নজরে কোডের প্রথম নজরে বোঝা ভাল পাঠযোগ্যতার একটি গুরুত্বপূর্ণ সম্পত্তি যা গ্রাহকরা এবং সেটেটরগুলি বিরতি দেয়। এ কারণেই আমি যখন পারি তখন এগুলি এড়াতে চেষ্টা করি এবং আমি যখন তাদের ব্যবহার করি তখন তারা কী করে তা ন্যূনতম করে দেয়।

— কাই
সূত্র
8
হ্যাঁ. বর্তমানে একটি বৃহত কোডবেস রিফ্যাকচারিং এবং এটি একটি দুঃস্বপ্ন। গেটার্স এবং সেটটাররা খুব ব্যস্ততার সাথে অন্যান্য খুব ব্যস্ত গেটার এবং সেটটারদের কল করে যা কিছুটা পঠনযোগ্যতা হ্রাস করে না। অ্যাক্সেসর ব্যবহারের জন্য বৈধতা একটি দুর্দান্ত কারণ, তবে এর থেকে অনেক বেশি ব্যবহার করার ফলে কোনও সম্ভাব্য সুবিধা হ'ল বলে মনে হয়।
— ফাদেকমিক
31
এটি সিনট্যাকটিক চিনির বিরুদ্ধে যুক্তি, সাধারণভাবে সেটটারগুলির বিরুদ্ধে নয়।
— ফিলি
6
সত্য এবং সত্য তবে ততোধিক, এটি নির্দেশ করে যে কীভাবে পৃথক সম্পত্তি সেটটাররা অবৈধ রাষ্ট্রগুলির জন্য দ্বার উন্মুক্ত করে যে কোনও প্রদত্ত বস্তুর অখণ্ডতা নিশ্চিত করার জন্য একেবারে কোনও প্রতিকার নেই যা বিমূর্ততা ফাঁস হতে দেয়।
— ড্যারেল টিগু
"এটি একটি সুন্দরভাবে কোডের টুকরো যতক্ষণ না আপনি তার সেটটারটি উপলব্ধি করেন" - আরে, জাভা সম্পর্কে নাকি সি # সম্পর্কে মূল পোস্ট ছিল? :)
— হনজা জিদেক
আমি পঠনযোগ্যতা সম্পর্কে সম্পূর্ণরূপে একমত। যখন person.name = "Joe";ডাকা হবে তখন এটি সম্পূর্ণ স্পষ্ট । তথ্যের পথে কোনও ক্রাফ্ট নেই, সিনট্যাক্স হাইলাইটিং এ দেখায় যে এটি একটি ক্ষেত্র এবং রিফ্যাক্টরিং সহজ (দুইটি পদ্ধতি এবং একটি ক্ষেত্রের রিফ্যাক্টরের প্রয়োজন নেই)। দ্বিতীয়ত, "getIsValid ()" বা এটি "isValid ()" ইত্যাদি হওয়া উচিত মনে করে সেই সমস্ত নষ্ট মস্তিষ্কের চক্রগুলি ভুলে যেতে পারে। আমি কোনও সময় একজন গিটার / সেটারের মাধ্যমে বাগ থেকে রক্ষা পেয়েছি বলে মনে করতে পারি না।
— উইল
53

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

আপনি তাদের সম্পর্কে আরও মার্জিত বিষয়গুলির বিভাগের ৩.৫ বিভাগে (অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং সম্পর্কিত আমার বই) পেতে পারেন।

— yegor256
সূত্র
7
গ্রাহকরা এবং সেটটাররা অ্যানিমিক ডোমেন মডেলটির পরামর্শ দেয়।
— রায়েডওয়াল্ড
7
আকর্ষণীয় দৃষ্টিকোণ। তবে বেশিরভাগ প্রোগ্রামিং প্রসঙ্গে আমাদের যা দরকার তা হ'ল ডেটা স্ট্রাকচার। সংযুক্ত নিবন্ধের "কুকুর" উদাহরণ গ্রহণ করা। হ্যাঁ, আপনি কোনও অ্যাট্রিবিউট সেট করে কোনও আসল-বিশ্বের কুকুরের ওজন পরিবর্তন করতে পারবেন না ... তবে new Dog()কুকুর নয়। এটি এমন একটি বস্তু যা কুকুর সম্পর্কে তথ্য ধারণ করে। এবং সেই ব্যবহারের জন্য, ভুলভাবে রেকর্ড করা ওজন সংশোধন করতে সক্ষম হওয়া স্বাভাবিক।
— স্টিফেন সি
3
ভাল, আমি এটি আপনার কাছে রেখেছি যে সর্বাধিক দরকারী প্রোগ্রামগুলিকে বাস্তব বিশ্বের বস্তুগুলির মডেল / সিমুলেট করার দরকার নেই। আইএমও, প্রোগ্রামিং ল্যাঙ্গুয়েজ সম্পর্কে এটি মোটেই নয়। এটি আমরা কী জন্য প্রোগ্রাম লিখি তা সম্পর্কে।
— স্টিফেন সি
3
রিয়েল ওয়ার্ল্ড বা না, ইয়েগোর পুরোপুরি ঠিক। আপনার কাছে যা আছে তা যদি সত্যই "স্ট্রাক্ট" হয় এবং আপনার নাম উল্লেখ করে এমন কোনও কোড লেখার দরকার নেই, এটি একটি হ্যাশটেবল বা অন্যান্য ডেটা কাঠামোতে রেখে দিন। এর জন্য যদি আপনার কোড লিখতে হয় তবে এটি একটি শ্রেণীর সদস্য হিসাবে রাখুন এবং সেই কোডটি রাখুন যা সেই চলকটি একই শ্রেণিতে চালিত করে এবং সেটার এবং গিটারটি বাদ দেয়। পুনশ্চ. যদিও আমি বেশিরভাগ ইয়েগরের দৃষ্টিভঙ্গি ভাগ করে নিই, আমি বিশ্বাস করে এসেছি যে কোড ছাড়াই টীকাকৃত মটরশুটিগুলি কিছুটা উপাত্ত কাঠামো - এছাড়াও গেটরসও কখনও কখনও প্রয়োজনীয় হয়, সেটারগুলির অস্তিত্ব কখনও না থাকা উচিত।
— বিল কে
1
আমি দূরে সরে গিয়েছি - এই পুরো উত্তরটি সঠিক এবং প্রাসঙ্গিক হলেও প্রশ্নটির সরাসরি সমাধান করে না। সম্ভবত এটি বলা উচিত "উভয় সেটটার / গেটার এবং পাবলিক ভেরিয়েবলগুলি ভুল" ... একেবারে নির্দিষ্টভাবে বলতে গেলে সেটার এবং রাইটেবল পাবলিক ভেরিয়েবলগুলি কখনই ব্যবহার করা উচিত নয় যদিও গেটররা পাবলিক ফাইনাল ভেরিয়েবলের মতো প্রায় একই রকম এবং মাঝে মাঝে প্রয়োজনীয় দুষ্টু তবে উভয়ই অপরের তুলনায় অনেক ভাল।
— বিল কে
52

এখানে অনেক কারণ আছে. আমার প্রিয়টি হ'ল যখন আপনার আচরণ পরিবর্তন করতে হয় বা আপনি কোনও ভেরিয়েবলের উপর কী সেট করতে পারেন তা নিয়ন্ত্রণ করতে হয়। উদাহরণস্বরূপ, ধরুন যে আপনার কাছে একটি সেটস্পিড (ইনট স্পিড) পদ্ধতি ছিল। তবে আপনি চান যে আপনি কেবল সর্বোচ্চ 100 গতি সেট করতে পারবেন You আপনি এমন কিছু করতে চাইবেন:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

এখন যদি আপনার কোডটিতে সমস্ত কিছু থাকে তবে আপনি সর্বজনীন ক্ষেত্রটি ব্যবহার করছেন এবং তখন আপনি বুঝতে পেরেছেন যে উপরের প্রয়োজনীয়তাটি আপনার প্রয়োজন? আপনার সেটারটি পরিবর্তনের পরিবর্তে সর্বজনীন ক্ষেত্রের প্রতিটি ব্যবহার শিকারে মজা করুন।

আমার 2 সেন্ট :)

— পিটার ডি
সূত্র
61
সর্বজনীন ক্ষেত্রের প্রতিটি ব্যবহার হান্টিং এমন কঠিন হওয়া উচিত নয়। এটিকে ব্যক্তিগত করুন এবং সংকলকটি তাদের সন্ধান করুন।
— নাথান ফেলম্যান 18
12
এটি অবশ্যই সত্য, তবে এটি কেন ডিজাইন করা হয়েছিল তার চেয়ে আরও শক্ত করে তুলুন। গেট / সেট পদ্ধতির এখনও আরও ভাল উত্তর।
— হার্ডরিভ
28
@Nathan: খোঁজা অন্যান্য ব্যবহারগুলির সমস্যা হয় না। তাদের সব পরিবর্তন হয়।
— গ্রামীণ পেরো
22
@ গ্রেমেপেরো এগুলি পরিবর্তন করতে একটি সুবিধা, কোনও সমস্যা নয় :( আপনার যদি ধারণা কোড থাকে যে গতি 100 এর চেয়েও বেশি হতে পারে (কারণ, আপনি জানেন যে চুক্তি ভঙ্গ করার আগে এটি সম্ভব!) ( while(speed < 200) { do_something(); accelerate(); })
— আর। মার্টিনহো ফার্নান্দেস
29
এটি একটি খুব খারাপ উদাহরণ! কারও কাছে ফোন করা উচিত: myCar.setSpeed(157);এবং কয়েকটি লাইনের পরে speed = myCar.getSpeed();এবং এখন ... আমি কেন speed==100এটি হওয়া উচিত তা বোঝার চেষ্টা করার সময় আপনাকে খুশী ডিবাগিংয়ের ইচ্ছা করি157
— পাইওত্রে আলেকসান্দার চামিলোভস্কি
38

অ্যাক্সেসর এবং মিউটরগুলির একটি সুবিধা হ'ল আপনি বৈধতা সম্পাদন করতে পারেন।

উদাহরণস্বরূপ, যদি fooসর্বজনীন হয় তবে আমি এটিকে সহজেই সেট করতে পারতাম nullএবং তারপরে অন্য কোনও ব্যক্তি অবজেক্টে কোনও পদ্ধতি কল করার চেষ্টা করতে পারে। কিন্তু এটা আর নেই! একটি setFooপদ্ধতি সহ, আমি নিশ্চিত করতে পারি যে fooএটি কখনও সেট করা হয়নি null।

অ্যাকসেসর এবং মিউটররাও এনক্যাপসুলেশন করার অনুমতি দেয় - আপনি যদি সেটটি একবার সেট করে দেখেন না (সম্ভবত এটি কনস্ট্রাক্টারে সেট হয়ে যায় এবং তারপরে পদ্ধতিগুলি ব্যবহার করে তবে কখনও পরিবর্তন করা উচিত নয়), এটি কখনও কারও দ্বারা দেখা যায় না। তবে আপনি যদি অন্য শ্রেণিকে এটি দেখতে বা এটির পরিবর্তনের অনুমতি দিতে পারেন তবে আপনি সঠিক অ্যাক্সেসর এবং / অথবা মিউটর সরবরাহ করতে পারেন।

— টমাস ওভেনস
সূত্র
28

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

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)
— jcdyer
সূত্র
2
হ্যাঁ, আমি আমার উত্তরের নীচে একটি মন্তব্যে যতটা বলেছি। জাভা একমাত্র ভাষা হিসাবে গিটার / সেটটারগুলি ক্র্যাচ হিসাবে ব্যবহার করে না ঠিক একইভাবে পাইথনের বৈশিষ্ট্য নির্ধারণ করতে সক্ষম একমাত্র ভাষা নয় language মূল বিষয়টি অবশ্য এখনও রয়ে গেছে - "সম্পত্তি" একই "পাবলিক ফিল্ড" নয়।
— ChssPly76
1
@ জেসিডি - মোটেও নয়। আপনি আপনার সার্বজনীন ক্ষেত্রগুলি উন্মোচন করে আপনার "ইন্টারফেস" (পাবলিক এপিআই আরও ভাল শব্দ হবে) সংজ্ঞায়িত করছেন। একবার হয়ে গেলে, আর ফিরে আসবে না। সম্পত্তিগুলি ক্ষেত্র নয় কারণ তারা আপনাকে ক্ষেত্রগুলিতে অ্যাক্সেসের প্রচেষ্টা বন্ধ করতে একটি ব্যবস্থা সরবরাহ করে (সেগুলি যদি সংজ্ঞায়িত হয় তবে তাদের পদ্ধতিতে রাউটিং করে); এটি অবশ্য গিটার / সেটার পদ্ধতিতে সিনট্যাক্স চিনির চেয়ে বেশি কিছু নয়। এটি অত্যন্ত সুবিধাজনক তবে এটি অন্তর্নিহিত দৃষ্টান্তের কোনও পরিবর্তন করে না - ক্ষেত্রগুলিতে অ্যাক্সেসের কোনও নিয়ন্ত্রণ ছাড়াই এক্সপোজিংগুলি এনক্যাপসুলেশনের নীতি লঙ্ঘন করে।
— ChssPly76
14
@ ChssPly76 — আমি একমত নই। আমার যেমন ঠিক তেমন সম্পত্তি আছে তেমনি আমারও নিয়ন্ত্রণ রয়েছে কারণ যখনই আমার প্রয়োজন হয় আমি তাদের সম্পত্তি তৈরি করতে পারি। বয়লারপ্লেট গেটার্স এবং সেটটার ব্যবহার করে এমন কোনও সম্পত্তি এবং একটি কাঁচা বৈশিষ্ট্যের মধ্যে কোনও ত্রুটি নেই, কাঁচা অ্যাট্রিবিউটটি দ্রুততর, কারণ এটি কল করার পদ্ধতিগুলির পরিবর্তে অন্তর্নিহিত ভাষাটি ব্যবহার করে। কার্যত, তারা অভিন্ন। এনক্যাপসুলেশন লঙ্ঘনের একমাত্র উপায় হ'ল যদি আপনি ভাবেন যে প্রথম বন্ধনী ( obj.set_attr('foo')) সমান চিহ্নগুলির ( obj.attr = 'foo') এর চেয়ে সহজাতভাবে উন্নত । পাবলিক অ্যাক্সেস হল পাবলিক অ্যাক্সেস।
— jcdyer
1
@ জিসিডিয়ার হ্যাঁ নিয়ন্ত্রণ করুন, তবে ততটা পাঠযোগ্যতা নয়, অন্যরা প্রায়শই ভুলভাবে ধরে obj.attr = 'foo'নেন যে অন্য কিছু না হয়ে কেবল পরিবর্তনশীল নির্ধারণ করে
— টিমো হুভিনেন
9
@ টিমোহুভিনেন কীভাবে জাভাতে থাকা কোনও ইউজারের চেয়ে আলাদা যে এই ধারণা করে যে obj.setAttr('foo')"অন্য কিছু ঘটছে না সেহেতু ভেরিয়েবল সেট করে"? যদি এটি সর্বজনীন পদ্ধতি হয় তবে এটি একটি সর্বজনীন পদ্ধতি। আপনি যদি এটি কোনও পার্শ্ব-প্রতিক্রিয়া অর্জনের জন্য ব্যবহার করেন এবং এটি সর্বজনীন হয় তবে আপনি যে কোনও কাজ করে তার উপর নির্ভর করতে পারতেন তবে কেবলমাত্র সেই উদ্দেশ্যে করা পার্শ্ব প্রতিক্রিয়া ঘটেছে ( অন্যান্য সমস্ত বাস্তবায়নের বিশদ এবং অন্যান্য পার্শ্ব প্রতিক্রিয়া, সংস্থানসমূহের ব্যবহার সহ, যাই হোক না কেন , ব্যবহারকারীর উদ্বেগ থেকে গোপন)। পাইথনের সাথে এটি একেবারেই আলাদা নয়। প্রভাব অর্জনের জন্য পাইথনের বাক্য গঠনটি কেবল সহজ।
— এলী
25

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

— জর্গে আগুইলার
সূত্র
24

ধন্যবাদ, যা সত্যই আমার চিন্তাভাবনা স্পষ্ট করেছে। এখন এখানে (প্রায়) 10 (প্রায়) ভাল কারণ এবং সেটটার ব্যবহার না করার জন্য ভাল কারণ রয়েছে:

  1. যখন আপনি উপলব্ধি করেছেন যে আপনার মূল্য সেট করা এবং মূল্য অর্জনের চেয়ে আরও বেশি কিছু করা দরকার, আপনি কেবল ক্ষেত্রটি ব্যক্তিগত করতে পারেন, যা তাত্ক্ষণিকভাবে আপনাকে বলবে যে আপনি কোথায় সরাসরি এটি ব্যবহার করেছেন।
  2. সেখানে আপনি যে কোনও বৈধতা যাচাই করেন তা কেবল প্রসঙ্গমুক্ত হতে পারে, যা বৈধতা খুব কমই অনুশীলনযোগ্য।
  3. আপনি সেট করা মানটি পরিবর্তন করতে পারেন - কলর যখন আপনাকে এমন একটি মান দেয় যখন তারা [শক হরর] চায় যে আপনি AS হিসাবে সঞ্চয় করতে চান এটি একেবারে দুঃস্বপ্ন।
  4. আপনি অভ্যন্তরীণ উপস্থাপনাটি লুকিয়ে রাখতে পারেন - চমত্কার, তাই আপনি নিশ্চিত করছেন যে এই সমস্ত ক্রিয়াকলাপগুলি প্রতিসম্মত ঠিক আছে?
  5. আপনি শীটগুলির অধীনে পরিবর্তনগুলি থেকে আপনার সর্বজনীন ইন্টারফেসকে উত্তাপিত করেছেন - যদি আপনি কোনও ইন্টারফেস ডিজাইন করেন এবং কোনও কিছুর সরাসরি অ্যাক্সেস ঠিক আছে কিনা তা নিশ্চিত না হন, তবে আপনার নকশা করা উচিত ছিল।
  6. কিছু লাইব্রেরি এটি প্রত্যাশা করে তবে অনেকগুলি নয় - প্রতিচ্ছবি, সিরিয়ালাইজেশন, মক অবজেক্টসগুলি সর্বজনীন ক্ষেত্রগুলির সাথে ঠিক কাজ করে।
  7. এই শ্রেণীর উত্তরাধিকারী হয়ে, আপনি ডিফল্ট কার্যকারিতা ওভাররাইড করতে পারেন - অন্য কথায় আপনি কেবল প্রয়োগকারীদের আড়াল করেই নয় বরং একে অসম্পূর্ণ করে কলারদের বিভ্রান্ত করতে পারেন।

শেষ তিনটি আমি সবে যাচ্ছি (এন / এ বা ডি / সি) ...

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

আমি জানি এটি কিছুটা দেরি হয়ে গেছে, তবে আমি মনে করি এমন কিছু লোক আছেন যারা পারফরম্যান্সে আগ্রহী।

আমি একটু পারফরম্যান্স পরীক্ষা করেছি। আমি একটি ক্লাস "নাম্বার হোল্ডার" লিখেছিলাম যা ভাল, একটি পূর্ণসংখ্যা রয়েছে। আপনি হয় গেটার পদ্ধতি ব্যবহার করে সেই পূর্ণসংখ্যাটি পড়তে পারেন anInstance.getNumber() বা সরাসরি ব্যবহার করে নম্বরটি অ্যাক্সেস করেanInstance.number । আমার প্রোগ্রামামটি দুটি উপায়েই সংখ্যাটি 1,000,000,000 বার পড়ে। এই প্রক্রিয়াটি পাঁচবার পুনরাবৃত্তি হয় এবং সময়টি মুদ্রিত হয়। আমি নিম্নলিখিত ফলাফল পেয়েছি:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(সময় 1 সরাসরি উপায়, সময় 2 উত্তোলক)

আপনি দেখুন, প্রাপ্তি (প্রায়) সর্বদা কিছুটা দ্রুত। তারপরে আমি বিভিন্ন সংখ্যক চক্র দিয়ে চেষ্টা করেছি। 1 মিলিয়ন এর পরিবর্তে, আমি 1 মিলিয়ন এবং 0.1 মিলিয়ন ব্যবহার করেছি। ফলাফলগুলো:

১০ মিলিয়ন চক্র: 

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

১ কোটি চক্র সহ, সময়গুলি প্রায় একই রকম। এখানে 100,000 (0.1 মিলিয়ন) চক্র রয়েছে:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

এছাড়াও বিভিন্ন পরিমাণে চক্র সহ, নিয়মিত উপায়ে তুলনামূলকভাবে কিছুটা দ্রুত। আমি আশা করি এটি আপনাকে সাহায্য করেছে

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

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

সহজ, সহজ চিন্তা করুন, প্রয়োজন হলে জটিলতা যুক্ত করুন।

আমি গভীর প্রযুক্তিগত ব্যবসায়ের মালিকদের সম্পর্কে অজ্ঞতার সুযোগ নেব না কারণ কেবলমাত্র আমি মনে করি যে এটি সঠিক বা আমি পদ্ধতির পছন্দ করি।

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

— মোহাম্মদ
সূত্র
16

আমরা গিটার এবং সেটটার ব্যবহার করি:

  • পুনঃব্যবহারযোগ্যতার জন্য
  • প্রোগ্রামিং পরবর্তী পর্যায়ে বৈধতা সম্পাদন

গেটর এবং সেটার পদ্ধতিগুলি ব্যক্তিগত শ্রেণীর সদস্যদের অ্যাক্সেসের জন্য সর্বজনীন ইন্টারফেস।

এনক্যাপসুলেশন মন্ত্র

এনক্যাপসুলেশন মন্ত্রটি ক্ষেত্রগুলি ব্যক্তিগত এবং পদ্ধতিগুলি জনসাধারণ্যে করা।

প্রাপ্তির পদ্ধতি: আমরা ব্যক্তিগত ভেরিয়েবলগুলিতে অ্যাক্সেস পেতে পারি।

সেটার পদ্ধতি: আমরা ব্যক্তিগত ক্ষেত্রগুলি পরিবর্তন করতে পারি।

যদিও গেটর এবং সেটার পদ্ধতিগুলি নতুন কার্যকারিতা যুক্ত করে না, আমরা সেই পদ্ধতিটি তৈরি করতে আমাদের মনকে পরে ফিরে আসতে পারি

  • উত্তম;
  • নিরাপদ; এবং
  • দ্রুত।

যে কোনও জায়গায় মান ব্যবহার করা যেতে পারে, এমন একটি পদ্ধতি যা সেই মানটি যুক্ত করে যোগ করা যায়। পরিবর্তে:

int x = 1000 - 500

ব্যবহার

int x = 1000 - class_name.getValue();

সাধারণ লোকের ভাষায়

"ব্যক্তি" শ্রেণির প্রতিনিধিত্ব

ধরুন আমাদের এর বিবরণ সংরক্ষণ করতে হবে Person। এটি Personক্ষেত্র আছে name, ageএবং sex। এটি করার জন্য name, ageএবং এর জন্য পদ্ধতি তৈরি করা জড়িত sex। এখন যদি আমরা প্রয়োজন অন্য ব্যক্তির তৈরি করেন, তার জন্য পদ্ধতি তৈরি করতে প্রয়োজনীয় হয়ে name, age,sex সব আবার।

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

— Devrath
সূত্র
15

আমি জাভা মামলার জন্য এটি ভাবতে বেশ কিছুক্ষণ ব্যয় করেছি এবং আমি বিশ্বাস করি যে আসল কারণগুলি হ'ল:

  1. ইন্টারফেসের কোড, বাস্তবায়ন নয়
  2. ইন্টারফেসগুলি কেবল ক্ষেত্রগুলি নয়, পদ্ধতিগুলি নির্দিষ্ট করে

অন্য কথায়, ইন্টারফেসে আপনি ক্ষেত্র নির্দিষ্ট করার একমাত্র উপায় হ'ল নতুন মান লেখার জন্য একটি পদ্ধতি এবং বর্তমান মানটি পড়ার একটি পদ্ধতি providing

এই পদ্ধতিগুলি হ'ল কুখ্যাত গেটর এবং সেটার ....

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

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

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

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

সুতরাং প্রাপ্তি প্রতিটি সন্তানের পৃষ্ঠায়, আমার কী প্রয়োজন হবে তা বের করার চেষ্টা থেকে আমাকে বাঁচায়। আমার যদি এটির প্রয়োজন হয়, আমি প্রহরকে কল করি এবং এটি যদি আমার কাছে ইতিমধ্যে না থাকে তবে এটি আমার জন্য এটি সন্ধান করবে।

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }
— quillbreaker
সূত্র
তাহলে গ্রাহক সেটটারকে কল করবেন?
— icc97
আমি অতীতে এটি কীভাবে করেছি তার কোড নমুনা যুক্ত করেছি - মূলত, আপনি প্রকৃত শ্রেণিটি কোনও সুরক্ষিত সদস্যের মধ্যে সঞ্চয় করেন, তারপরে সেই সুরক্ষিত সদস্যকে গেট অ্যাকসেসরে ফিরিয়ে দিন, যদি এটি আরম্ভ না করা হয় তবে এটি আরম্ভ করুন।
— কুইলব্রেকার
— সারা এম
13

একটি দিক আমি এখন পর্যন্ত উত্তরগুলিতে মিস করেছি, অ্যাক্সেসের বিশদকরণ:

  • সদস্যদের জন্য আপনার কাছে উভয়ই সেটিং এবং পাওয়ার জন্য একমাত্র অ্যাক্সেসের স্পেসিফিকেশন রয়েছে
  • সেটেটর এবং গেটার্সের জন্য আপনি এটি টিউন করতে পারেন এবং এটি আলাদাভাবে সংজ্ঞায়িত করতে পারেন
— jdehaan
সূত্র
13

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

দুটি প্রধান বিষয় হ'ল বহুমুখীতা এবং বৈধতা। এমনকি যদি এটি কেবল একটি বোকা ডেটা কাঠামো।

ধরা যাক আমাদের এই সাধারণ বর্গ রয়েছে:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

একটি খুব সাধারণ শ্রেণি যা এটিতে তরল কী পরিমাণ এবং এর ক্ষমতা (মিলিলিটারে) কী তা ধারণ করে।

আমি যখন করি তখন কী হয়:

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

ঠিক আছে, আপনি আশা করেন না যে এটি কাজ করবে, তাই না? আপনি চান কিছু ধরণের বিলোপযুক্ত পরীক্ষা। এবং সবচেয়ে খারাপ, আমি যদি সর্বাধিক ক্ষমতা নির্দিষ্ট না করি তবে কী হবে? ওহে প্রিয়, আমাদের সমস্যা আছে।

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

আমরা এরকম কিছু দিয়ে শেষ করব:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

গ্রেট! এবং এখন আমরা কেবল বোতলটি এতে পরিবর্তন করি:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

আমি অনুশীলন হিসাবে বোতলওভারফ্লো এক্সপশনটির সংজ্ঞা পাঠকের কাছে ছেড়ে দেব।

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

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

এবং হ্যাঁ, মনে হচ্ছে আমরা খুব সহজ ধারণা থেকে দ্রুত আরও ভাল উত্তর পেতে চলেছি।

দয়া করে মনে রাখবেন যে আপনি বোতলটির ক্ষমতা পরিবর্তন করতে পারবেন না। এটি এখন পাথর স্থাপন করা হয়। আপনি এটি কোনও চূড়ান্ত ঘোষণা করে কোন int দিয়ে এটি করতে পারেন। তবে এটি যদি একটি তালিকা হয়ে থাকে তবে আপনি এটিকে খালি করতে পারতেন, এতে নতুন কিছু যুক্ত করতে পারেন। আপনি অভ্যন্তরের অভ্যন্তরে স্পর্শ করার অ্যাক্সেসকে সীমাবদ্ধ করতে পারবেন না।

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

— হাকন লাটভিট
সূত্র
2
আমি যে ইন্টারফেসগুলি পড়েছি তার প্রথম অর্ধ-শালীন ব্যাখ্যার জন্য ধন্যবাদ, "রিমোট কন্ট্রোল" বা "গাড়ি" এর জন্য কোনও রেফারেন্স সান করেছে
— ডিজেভিএস
1
"আপনার কাছে এমন বোতল থাকতে পারে যেগুলি যখন রাষ্ট্র পরিবর্তন করে তখন ডিস্কে লেখেন, বা বোতলগুলি যা এসকিউএল ডাটাবেসে সংরক্ষণ করে" আমি এত শক্ত এক্সডি লোলড করেছিলাম। তবে যাইহোক, এটি উপস্থাপন করার জন্য দুর্দান্ত ধারণা!
— জেরাস
10

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

যে ভাষাগুলি "রিয়েল" বৈশিষ্ট্যগুলিকে সমর্থন করে (পাইথন, রুবি, সম্ভবত ছোট্টকল?) পদ্ধতিগুলি সেট / সেট করার কোনও মানে নেই।

— জন মিলিকিন
সূত্র
1
উত্তর: সি # আপনি যদি কোনও গেট / সেটে কার্যকারিতা যুক্ত করেন তবে এর জন্য কি পুনরায় সংশোধনের প্রয়োজন হবে না?
— স্টিমার 25
@ স্টিমার 25: দুঃখিত, ভুল টাইপ করেছেন। আমি বোঝাতে চাইছি ক্লাসের ক্লায়েন্টদের পুনরায় সংযুক্ত করতে হবে।
— জন মিলিকিন
5
একটি সেটফু পদ্ধতিতে বৈধতা যুক্তি যুক্ত করার জন্য ভাষার স্তরে কোনও শ্রেণির ইন্টারফেস পরিবর্তনের প্রয়োজন হবে না , তবে এটি প্রকৃত ইন্টারফেস , ওরফে চুক্তি পরিবর্তন করে, কারণ এটি পূর্ব শর্তগুলি পরিবর্তন করে। কেন কেউ চাইবে যে সংকলকটি যখন এটি হ'ল ভাঙ্গা পরিবর্তন হিসাবে বিবেচনা না করে ?
— আর মার্টিনহো ফার্নান্দেস
@ আর.মার্টিনহো ফার্নান্দেস কীভাবে এই "ভাঙ্গা" সমস্যাটিকে সমাধান করতে পারে? সংঘটিতকারী এটি ভেঙে গেছে কিনা তা বলতে পারে না। আপনি কেবল অন্যদের জন্য লাইব্রেরি লেখার সময় এটি কেবল উদ্বেগের বিষয়, তবে আপনি এখানে সর্বজনীন জੋਮজি হিসাবে তৈরি করছেন ড্রাগন!
— ফিলি
3
উত্তরে বর্ণিত হিসাবে পুনঃসংশোধনের প্রয়োজন, সংকলক আপনাকে সম্ভাব্য ব্রেকিং পরিবর্তন সম্পর্কে সচেতন করতে পারে এমন এক উপায়। এবং আমি যা লিখি প্রায় সবই কার্যকরভাবে "অন্যের জন্য একটি গ্রন্থাগার", কারণ আমি একা কাজ করি না। আমি এমন কোড লিখি যাতে ইন্টারফেস রয়েছে যা প্রকল্পের অন্যান্য লোকেরা ব্যবহার করবে। পার্থক্য কি? হ্যালো, এমনকি যদি আমি এই ইন্টারফেসগুলির ব্যবহারকারী হয়ে থাকি তবে কেন আমি আমার কোডটিকে নিম্নমানের মান হিসাবে ধরে রাখব? আমি কষ্টকর ইন্টারফেসের সাথে কাজ করা পছন্দ করি না, এমনকি আমি সেগুলি লিখছি।
— আর মার্টিনহো ফার্নান্দেস
6

ওও ডিজাইনের অন্যতম প্রধান প্রিন্সিপাল: এনক্যাপসুলেশন!

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

— জাস্টিন নিসনার
সূত্র
23
এনক্যাপসুলেশন গেটর এবং সেটটার অফার হেসে পাতলা। এখানে দেখুন ।
— sbi
যদি আপনার সার্বজনীন ইন্টারফেস বলে যে 'foo' টাইপ 'T' টাইপের এবং কোনও কিছুর জন্য সেট করা যায় তবে আপনি কখনই এটি পরিবর্তন করতে পারবেন না। আপনি এটিকে 'ওয়াই' টাইপ করার সিদ্ধান্ত নিতে পারবেন না, আপনি আকারের বাধাগুলির মতো নিয়মও চাপিয়ে দিতে পারবেন না। সুতরাং আপনার কাছে যদি পাবলিক গেট / সেট থাকে যা খুব বেশি সেট / পায় না তবে আপনি এমন কোনও কিছু পাচ্ছেন না যা কোনও পাবলিক ফিল্ড অফার করবে না এবং এটি আরও জটিল করে তুলবে। আপনার যদি কোনও বাধা থাকে যেমন বস্তুটি বাতিল হয়ে যেতে পারে, বা মানটি একটি সীমার মধ্যে থাকতে হবে তবে হ্যাঁ, একটি পাবলিক সেট পদ্ধতি প্রয়োজন হবে তবে আপনি এখনও এই মানটি সেট করার থেকে একটি চুক্তি উপস্থাপন করতে পারেন যা ' টি পরিবর্তন
— থোকোশম্যান
কেন চুক্তি পরিবর্তন হতে পারে না?
— ফিলি
5
চুক্তি পরিবর্তিত হলে কেন বিষয়গুলি সংকলন করা উচিত?
— আর মার্টিনহো ফার্নান্দেস
5

আপনার যখন গ্রাহক এবং সেটটার ব্যবহার করা উচিত তখন:

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

সুতরাং এটি খুব কমই একটি সাধারণ ওও প্রশ্ন; এটি একটি ভাষা-নির্দিষ্ট প্রশ্ন, বিভিন্ন ভাষার বিভিন্ন উত্তর (এবং বিভিন্ন ব্যবহারের ক্ষেত্রে) সহ।

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

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

* এমনকি সেই সাধারণ শ্রেণীর জন্য, আপনি অগত্যা মান xএবং yমানগুলি সেট করার অনুমতি দিতে চান না । যদি এটি সত্যিই একটি বর্গ, এটা মত পদ্ধতি না থাকা উচিত translate, rotateইত্যাদি? যদি এটি কেবলমাত্র একটি শ্রেণি কারণ আপনার ভাষায় রেকর্ড / স্ট্রাক্ট / নামযুক্ত টিপলস নেই, তবে এটি সত্যই ওও এর প্রশ্ন নয় ...

তবে কেউ কখনও সাধারণ ওও ডিজাইন করেন না। তারা একটি নির্দিষ্ট ভাষায় ডিজাইন এবং বাস্তবায়ন করছে। এবং কিছু ভাষায়, গেটর এবং সেটটারগুলি অকেজো থেকে অনেক দূরে।

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

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

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

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

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

— abarnert
সূত্র
4

কোনও অবজেক্ট ওরিয়েন্টেশন ডিজাইনের দৃষ্টিকোণ থেকে উভয় বিকল্পই ক্লাসগুলির এনক্যাপসুলেশনকে দুর্বল করে কোডের রক্ষণাবেক্ষণের জন্য ক্ষতিকারক হতে পারে। একটি আলোচনার জন্য আপনি এই দুর্দান্ত নিবন্ধটি দেখতে পারেন: http://typicalprogrammer.com/?p=23 23

— andrers52
সূত্র
3

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

গেটর এবং সেটার পদ্ধতিগুলি ব্যবহার করার কিছু সুবিধা রয়েছে যেমন আপনি পরিশীলিত কার্যকারিতা সহ সদস্য তৈরি করতে দেওয়ার ক্ষমতা যা আপনি বৈশিষ্ট্যের মতো অ্যাক্সেস করতে পারেন। তারা আপনাকে কেবল পঠনযোগ্য এবং কেবল লেখার বৈশিষ্ট্য তৈরি করতে দেয়।

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

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

— সুমিত সিং
সূত্র
3

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

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

int getVar() const { return var ; }

সুতরাং তোমার আছে:

doSomething( obj->getVar() ) ;

পরিবর্তে

doSomething( obj->var ) ;

কেবল getVar()দৃষ্টিগোচর নয় , এটি এই মায়া দেয় যা gettingVar()যেহেতু সত্যিকারের চেয়ে আরও জটিল প্রক্রিয়া। আপনি (শ্রেণীর লেখক হিসাবে) পবিত্রতার বিষয়টি varকীভাবে বিবেচনা করছেন তা যদি আপনার শ্রেণীর কোনও ব্যবহারকারীর কাছে পাস্ত্র্রু সেটার থাকে তবে তা দেখে মনে হচ্ছে - এমন কিছু যা আপনি জোর দিয়েছিলেন তা "সুরক্ষা" দেওয়ার জন্য আপনি এই গেটগুলি স্থাপন করছেন মূল্যবান, (এর পবিত্রতা var) তবে আপনি এমনকি varসুরক্ষার বিষয়টি স্বীকার করেন যে কারও পক্ষে কেবল আসার ক্ষমতা এবং set varযা কিছু মূল্য তারা চান তার চেয়ে মূল্যবান নয়, এমনকি আপনি কী করছেন সেদিকে নজর না দিয়ে।

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

1) ডেটা এবং আচরণের সাথে বেসিক অবজেক্টগুলির জন্য সমস্ত পাবলিক সদস্যদের সাথে শুরু করুন। এ কারণেই আমার সমস্ত সি ++ "উদাহরণ" কোডে আপনি আমাকে সর্বত্র ব্যবহারের structপরিবর্তে লক্ষ্য করবেন class।

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

3) যে ক্লাসগুলি পুরোপুরি সজ্জিত হয় এবং তাদের অভ্যন্তরগুলি সম্পর্কে কঠোর নিয়ম আছে (যেমন তারা ঠিক কী কাজ করছে তা তারা জানে এবং আপনি এর অভ্যন্তরীণগুলির সাথে "ফাক" (প্রযুক্তিগত শব্দটি) করতে পারেন না) classপদকে ডিফল্ট ব্যক্তিগত সদস্য, এবং কেবলমাত্র কয়েকটি নির্বাচিত সদস্যেরই অনুমতি রয়েছে public।

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

— bobobobo
সূত্র
1
"... একটি সুনির্দিষ্ট সংজ্ঞাযুক্ত ইন্টারফেস যা আপনি কেবল" ইন্টারটারাল এবং সেটারগুলিতে বৈধতা দিয়ে স্ক্রু করতে পারবেন না।
— আগি হ্যামার্থিফ
3

কোনও সম্পত্তির উত্তরাধিকার নেই বলে অ্যাকসেসরগুলি ব্যবহার করার পক্ষে বিবেচনা করার উপযুক্ত কারণ রয়েছে। পরবর্তী উদাহরণ দেখুন:

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

আউটপুট:

0
0
4
— GeZo
সূত্র
3

Getters এবং setters অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং এর মৌলিক দিক আছে যার দুই প্রয়োগ করতে ব্যবহৃত হয়:

  1. বিমূর্তন
  2. encapsulation

মনে করুন আমাদের একটি কর্মচারী শ্রেণি রয়েছে:

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

এখানে পুরো নামের বাস্তবায়নের বিশদটি ব্যবহারকারীর কাছ থেকে লুকানো রয়েছে এবং এটি কোনও পাবলিক বৈশিষ্ট্যের বিপরীতে সরাসরি ব্যবহারকারীর কাছে অ্যাক্সেসযোগ্য নয়।

— প্রীতম ব্যানার্জি
সূত্র
1
আমার কাছে প্রচুর সংখ্যক গেটর এবং সেটটার রয়েছে যা অনন্য কিছুই করেন না। getFullName ব্যতিক্রম কারণ এটি অন্য কিছু করে। মাত্র তিনটি ভেরিয়েবল পাবলিক থাকার পরে getFullName রাখা প্রোগ্রামটি পড়া সহজ করে তুলবে তবে এখনও সেই পুরো নাম জিনিসটি লুকানো রয়েছে। সাধারণত আমি গেটার এবং সেটটারদের সাথে পুরোপুরি ভাল আছি যদি ক। তারা অনন্য কিছু করে এবং / অথবা খ। আপনার কেবল একটি আছে, হ্যাঁ আপনি একটি সর্বজনীন ফাইনাল করতে পারেন এবং যা কিছু না
— ফেসলেসটাইজার
1
এর সাথে সুবিধাটি হ'ল আপনি ইন্টারফেসটি পরিবর্তন না করে ক্লাসের ইন্টার্নালগুলি পরিবর্তন করতে পারেন। বলুন, তিনটি বৈশিষ্ট্যের পরিবর্তে আপনার একটি ছিল - স্ট্রিংগুলির একটি অ্যারে। যদি আপনি গেটার এবং সেটটার ব্যবহার করে চলেছেন তবে আপনি সেই পরিবর্তনটি করতে পারেন এবং তারপরে নামগুলি [0] নাম, নাম [1] মাঝারি, ইত্যাদি ইত্যাদি জেনার / সেটটারগুলি আপডেট করতে পারেন তবে আপনি যদি সর্বজনীন বৈশিষ্ট্যগুলি ব্যবহার করেন তবে , আপনাকে প্রতিটি শ্রেণীর অ্যাক্সেসকৃত কর্মচারীও পরিবর্তন করতে হবে, কারণ তারা যে প্রথম নাম সম্পত্তিটি ব্যবহার করে আসছে তা আর বিদ্যমান নেই।
— অ্যান্ড্রু হাউস
1
@ অ্যান্ড্রু আমি বাস্তব জীবনে যা দেখেছি তার থেকে দেখায়, লোকেরা যখন শ্রেণীর অভ্যন্তরীণ পরিবর্তন করে তারা ইন্টারফেসও পরিবর্তন করে এবং সমস্ত কোডের একটি
— বৃহত প্রতিস্থাপন করে
2

অন্য একটি ব্যবহার (বৈশিষ্ট্যগুলিকে সমর্থন করে এমন ভাষাগুলিতে) সেটার্স এবং গেটররা বোঝাতে পারে যে কোনও অপারেশন অ-তুচ্ছ। সাধারণত, আপনি কোনও সম্পত্তিতে গণনামূলকভাবে ব্যয়বহুল এমন কিছু করা এড়াতে চান।

— জেসন বেকার
সূত্র
আমি কখনই কোনও গেটর বা সেটটারকে ব্যয়বহুল অপারেশন হওয়ার আশা করতাম না। এই ক্ষেত্রে আরও ভাল একটি কারখানা ব্যবহার করুন: আপনার প্রয়োজন সমস্ত সেটটার ব্যবহার করুন এবং তারপরে ব্যয়বহুল executeবা buildপদ্ধতিটি শুরু করুন।
— হুবার্ট গ্রেজস্কোইয়াক
2

গেটার্স / সেটারগুলির একটি অপেক্ষাকৃত আধুনিক সুবিধা হ'ল এটি ট্যাগড (ইনডেক্সড) কোড সম্পাদকদের কোড ব্রাউজ করা সহজ করে। উদাহরণস্বরূপ আপনি যদি দেখতে চান যে কে সদস্য কে সেট করে, আপনি সেটারের কল স্তরক্রম খুলতে পারেন।

অন্যদিকে, সদস্য যদি জনসাধারণ হয়, সরঞ্জামগুলি সদস্যকে পঠন / লেখার অ্যাক্সেস ফিল্টার করা সম্ভব করে না। সুতরাং আপনাকে ট্রড করতে হবে যদিও সদস্যের সমস্ত ব্যবহার রয়েছে।

— রাকেশ সিং
সূত্র
আপনি ডান ক্লিক করতে পারেন>
— কোনও গেটর
2

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

— antz
সূত্র
1

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

— পিট
সূত্র
2
আমি মনে করি গেটর বা সেটারের আচরণ পরিবর্তন করা কোনও ব্রেকিং পরিবর্তন নয়। </arcasm>
— আর মার্টিনহো ফার্নান্দিস
@ আর.মার্টিনহো ফার্নান্দিস সর্বদা থাকা উচিত নয়। TBYS
— ফিলি
1

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

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