কীভাবে "বলুন, জিজ্ঞাসা করবেন না" ব্যাখ্যা ভাল ওও হিসাবে বিবেচিত হয়


49

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

যেমন উদাহরণ # 2:

খারাপ:

def check_for_overheating(system_monitor)
  if system_monitor.temperature > 100
    system_monitor.sound_alarms
  end
end

বনাম ভাল:

system_monitor.check_for_overheating

class SystemMonitor
  def check_for_overheating
    if temperature > 100
      sound_alarms
    end
  end
end

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

উদাহরণ 4:

খারাপ:

def street_name(user)
  if user.address
    user.address.street_name
  else
    'No street name on file'
  end
end

বনাম ভাল:

def street_name(user)
  user.address.street_name
end

class User
  def address
    @address || NullAddress.new
  end
end

class NullAddress
  def street_name
    'No street name on file'
  end
end

Userকোনও সম্পর্কযুক্ত ত্রুটির স্ট্রিংটি ফর্ম্যাট করার দায়িত্ব কেন ? যদি 'No street name on file'রাস্তায় রাস্তা না থাকে তবে আমি মুদ্রণের পাশাপাশি কিছু করতে চাই ? যদি রাস্তার নাম একই জিনিস হয়?


কেউ কি আমাকে "বলুন, জিজ্ঞাসা করবেন না" সুবিধাগুলি এবং যৌক্তিকতা সম্পর্কে আলোকিত করতে পারে? আমি কোনটি ভাল তা সন্ধান করছি না, পরিবর্তে লেখকের দৃষ্টিভঙ্গি বোঝার চেষ্টা করছি।


কোড উদাহরণগুলি রুবি হতে পারে এবং পাইথন নয়, আমি জানি।
পাব্বি

2
আমি সবসময় ভাবছি যে প্রথম উদাহরণের মতো কিছু যদি এসআরপি লঙ্ঘন না হয়?
stijn

1
আপনি এটি পড়তে পারেন: pragprog.com/articles/tell-dont-ask
Mik378

রুবি। @ উদাহরণস্বরূপ শর্টহ্যান্ড এবং পাইথন তার ব্লকগুলি পুরোপুরি সাদা স্থানের সাথে শেষ করে।
এরিক রিপেন

3
"সি ++ এর পরামর্শ হ'ল মেম্বার ফাংশনগুলির পরিবর্তে ফ্রি ফাংশনগুলি পছন্দ করা উচিত কারণ তারা এনক্যাপসুলেশন বাড়ায়।" আপনাকে কে বলেছিল আমি জানি না, তবে এটি সত্য নয়। এনক্যাপসুলেশন বাড়াতে ফ্রি ফাংশন ব্যবহার করা যেতে পারে তবে এগুলি প্রয়োজনীয়ভাবে এনক্যাপসুলেশন বাড়ায় না।
রব কে

উত্তর:


81

বস্তুর অবস্থান সম্পর্কে জিজ্ঞাসা করা, এবং তারপরে বস্তুর বাইরের সিদ্ধান্তের ভিত্তিতে সেই বস্তুর উপর পদ্ধতি কল করার অর্থ হল যে বস্তুটি এখন একটি ফাঁস বিমূর্ততা; এর কিছু আচরণ অবজেক্টের বাইরে অবস্থিত এবং অভ্যন্তরীণ অবস্থা বহির্বিশ্বে প্রকাশিত (সম্ভবত অযথা)।

আপনি অবজেক্টগুলি তাদের কী করতে চান তা বলার চেষ্টা করা উচিত; তাদের রাষ্ট্র সম্পর্কে প্রশ্ন জিজ্ঞাসা করবেন না, সিদ্ধান্ত নিন এবং তারপরে তাদের কী করবেন তা বলুন।

সমস্যাটি হ'ল, আহ্বানকারী হিসাবে, আপনাকে বলা হওয়া অবজেক্টের অবস্থার উপর ভিত্তি করে সিদ্ধান্ত নেওয়া উচিত নয় যা ফলস্বরূপ আপনাকে বস্তুর অবস্থা পরিবর্তন করে changing আপনি যে যুক্তিটি বাস্তবায়ন করছেন এটি সম্ভবত আপনার নয়, বলা অবজেক্টের দায়িত্ব। আপনি অবজেক্টের বাইরে সিদ্ধান্ত নেওয়ার জন্য এর এনক্যাপসুলেশন লঙ্ঘন করে।

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

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

http://pragprog.com/articles/tell-dont-ask


4
উদাহরণ পাঠ্যটি এমন অনেকগুলি বিষয়কে অস্বীকার করে যা স্পষ্টভাবে ভাল অনুশীলন।
ডেডএমজি

13
@ ডিএডএমজি এটি কেবল সেই লোকদেরই বলে যা যা তারা অনর্থকভাবে অনুসরণ করে, যারা সাইটের নাম এবং সাইট লেখকদের মূল চিন্তায় তাদের মূল বইয়ে পরিষ্কারভাবে বলে দেওয়া হয়েছে যে "অনুশীলনকারী" অন্ধভাবে উপেক্ষা করেছেন: " সর্বোত্তম সমাধানের মতো কোনও বিষয় নেই is ... "
gnat

2
বইটি কখনও পড়বেন না। আমিও চাই না। আমি কেবল উদাহরণের পাঠ্যটি পড়েছি, যা সম্পূর্ণ ন্যায্য।
ডেডএমজি

3
পছন্দ করুন এখন আপনি যে মূল পয়েন্টটি জানেন যা এই উদাহরণটি (এবং সেই বিষয়ে প্রাগপ্রোগ থেকে অন্য যে কোনও একটি) উদ্দেশ্য প্রসঙ্গে ("সর্বোত্তম সমাধান হিসাবে এরকম কিছু নয় ..."), বইটি না পড়া ঠিক আছে
জিনাত

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

16

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

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

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

আরও লক্ষ করুন যে দ্বিতীয় উদাহরণটি নিরবচ্ছিন্নভাবে নাল অবজেক্ট অ্যান্টি-প্যাটার্নটি ব্যবহার করে।


19
"নাল অবজেক্ট" এটাকে আমি অ্যান্টি-প্যাটার্ন বলি না, তাই আমি ভাবছি যে এটি করার আপনার কারণ কী?
কনরাড রুডলফ

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

4
আমি যুক্তি দেব যে এটি পুরোপুরি সমস্যার ডোমেনের উপর নির্ভর করে।
কনরাড রুডলফ

5
@DeadMG সে ব্যাপারে আমি সম্মত উপরোক্ত উদাহরণে নাল অবজেক্ট প্যাটার্ন একটি খারাপ ব্যবহার, কিন্তু হয় এটি ব্যবহার করার জন্য একটি মেধার। নাল চেক করা বা সিস্টেমের সত্যিকারের 'নাল' হওয়া এড়াতে কয়েকবার আমি কিছু ইন্টারফেস বা অন্য কোনও 'অপ-অপ' প্রয়োগকরণ ব্যবহার করেছি।
সর্বোচ্চ

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

9

আপনার অত্যধিক গরমের উদাহরণের সাথে আসল সমস্যাটি হ'ল ওভারহিট হিসাবে যোগ্যতা অর্জনের নিয়মগুলি বিভিন্ন সিস্টেমে সহজেই পরিবর্তিত হয় না। ধরুন সিস্টেম এটি আপনার যেমন রয়েছে (টেম্পোর> ১০০ অতিরিক্ত গরম হচ্ছে) তবে সিস্টেম বি আরও সূক্ষ্ম (টেমপ্লেট> ৯৩ বেশি গরম হচ্ছে)। সিস্টেমের ধরণটি পরীক্ষা করতে এবং তারপরে সঠিক মানটি প্রয়োগ করতে আপনি নিজের নিয়ন্ত্রণের কার্যকারিতা পরিবর্তন করেন?

if (system is a System_A and system_monitor.temp >100)
  system_monitor.sound_alarms
else if (system is a System_B and system_monitor.temp > 93)
  system_monitor.sound_alarms
end

বা আপনার কি প্রতিটি ধরণের সিস্টেমের তার গরম করার ক্ষমতা সংজ্ঞায়িত করা হয়?

সম্পাদনা করুন:

system.check_for_overheating

class SystemA : System
  def check_for_overheating
    if temperature > 100
      sound_alarms
    end
  end
end

class SystemB : System
  def check_for_overheating
    if temperature > 93
      sound_alarms
    end
  end
end

আপনি আরও সিস্টেমের সাথে ডিল শুরু করার সাথে পূর্ববর্তী উপায়টি আপনার নিয়ন্ত্রণের ক্রিয়াকে কুৎসিত করে তোলে। পরেরটি সময় হিসাবে কন্ট্রোল ফাংশন স্থিতিশীল হতে দেয়।


1
প্রতিটি সিস্টেমে মনিটরের সাথে নিবন্ধ কেন নেই। নিবন্ধনের সময় তারা অতিরিক্ত তাপীকরণ ঘটে তা নির্দেশ করতে পারে।
মার্টিন ইয়র্ক

@ লোকিআস্তারি - আপনি পারতেন তবে আপনি আর্দ্রতা বা বায়ুমণ্ডলের চাপের সংবেদনশীল এমন একটি নতুন সিস্টেমে চলে যেতে পারেন। নীতিটি কী তারতম্য তা বিমূর্ত করা - এই ক্ষেত্রে এটি অতিরিক্ত গরম করার সংবেদনশীলতা
ম্যাথু ফ্লিন

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

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

6

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

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

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

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

সুতরাং এমন ঘটনাও ঘটতে পারে যেখানে "এতটা ভাল নয়" হ'ল উপায়, তবে সাধারণত "বেটার" ভাল, আরও ভাল।


3

ডেটা / অবজেক্ট অ্যান্টি-সিমেট্রি

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

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

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

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

বব মার্টিন তাঁর "ক্লিন কোড" বইটিতে এটিকে "ডেটা / অবজেক্ট অ্যান্টি-সিমমেট্রি" (পি। 95 ফাফ) বলেছেন, অন্যান্য সম্প্রদায় এটিকে " এক্সপ্রেশন সমস্যা " হিসাবে উল্লেখ করতে পারে ।


3

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

এই নিয়মটি "ডাবল-ডট" বা "ডাবল তীর" কোড এড়ানোর বিষয়ে নিয়মের সাথে সম্পর্কিত, প্রায়শই 'কেবলমাত্র তাত্ক্ষণিক বন্ধুদের সাথে কথা বলুন' হিসাবে উল্লেখ করা হয়, যা বলা foo->getBar()->doSomething()হয় খারাপ, পরিবর্তে foo->doSomething();বারের কার্যকারিতার চারপাশে মোড়কের কল, এবং সহজভাবে প্রয়োগ করা হয়েছে return bar->doSomething();- যদি fooপরিচালনার জন্য দায়বদ্ধ হয় bar, তবে এটি এটি করতে দিন!


1

"বলুন, জিজ্ঞাসা করবেন না" সম্পর্কে অন্যান্য ভাল উত্তরের পাশাপাশি আপনার নির্দিষ্ট উদাহরণগুলিতে কিছু মন্তব্য যা সহায়তা করতে পারে:

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

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

কোনও সম্পর্কযুক্ত ত্রুটির স্ট্রিংটি ফর্ম্যাট করা কেন ব্যবহারকারীর দায়িত্ব? যদি রাস্তায় রাস্তা না থাকে তবে 'ফাইলের কোনও রাস্তার নাম নেই' মুদ্রণের পাশাপাশি কিছু করতে চাইলে কী হবে? যদি রাস্তার নাম একই জিনিস হয়?

'রাস্তার নাম' পাওয়া এবং 'ত্রুটির বার্তা সরবরাহ করা' দু'জনেরই কেন 'রাস্তার_নাম' এর দায়িত্ব? কমপক্ষে 'ভাল' সংস্করণে, প্রতিটি টুকরোটির একটি দায়িত্ব রয়েছে। তবুও, এটি একটি দুর্দান্ত উদাহরণ নয়।


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

অবশ্যই, বা যদি থার্মোস্ট্যাট এবং অ্যালার্মগুলি বিভিন্ন শ্রেণিতে বিদ্যমান ছিল (যেমন তাদের সম্ভবত হওয়া উচিত)।
টেলাস্টিন

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

অনুশীলন 'মেহ' হওয়া সম্পর্কে একটি নিবন্ধে একটি উদাহরণ এটি বিতর্ক করে। এই অনুশীলনটি যদি এর দুর্দান্ত সুবিধার কারণে মানসম্মত হয়, তবে একটি উপযুক্ত উদাহরণ খুঁজে পেতে সমস্যা কেন?
স্টিজন ডি উইট

1

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

Product product = productMgr.get(productUuid)
if (product.userUuid != currentUser.uuid) {
    throw BlahException("This product doesn't belong to this user")
}

তার অর্থ আপনার কাছে আরও ভাল কিছু থাকতে হবে:

Product product = productMgr.get(productUuid, currentUser)

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


0

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

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

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

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

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