কোনও শ্রেণীর পক্ষে নিজস্ব পাবলিক পদ্ধতি ব্যবহার করা কি ঠিক আছে?

23

পটভূমি

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

public void ReverseData()
public void ScheduleTransmission()

ScheduleTransmissionপদ্ধতি দরকার কল করার ReverseDataপদ্ধতি যখনই বলা হয়। যাইহোক, এমন অনেক সময় আছে যেখানে আমাকে ReverseDataবাহ্যিকভাবে কল করতে হবে (এবং আমার পুরোপুরি নামের জায়গার বাইরে যুক্ত করা উচিত ) সেখান থেকে অ্যাপ্লিকেশনটিতে অবজেক্টটি ইনস্ট্যান্ট করা হয়েছে।

"গ্রহন" হিসাবে আমার অর্থ ডেটা আন-রিভার্স করার জন্য ইভেন্ট-হ্যান্ডলারের কাছে ReverseDataবাহ্যিকভাবে ডাকা হবে object_received।

প্রশ্ন

কোনও বস্তুর নিজস্ব পাবলিক পদ্ধতিগুলি কল করা কি সাধারণভাবে গ্রহণযোগ্য?

c# design-patterns object-oriented methods

— স্নুপ
সূত্র

5

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

— কান

@ কান এগুলি আমার পদ্ধতির আসল নাম নয়, তবে ঘনিষ্ঠভাবে সম্পর্কিত। প্রকৃতপক্ষে "বিপরীত তথ্য" মোট শব্দের 8 বিট বিপরীত করে এবং যখন আমরা গ্রহণ করি এবং সঞ্চার করি তখন তা সম্পন্ন হয়।

— স্নুপ

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

— ড্যানিয়েল টি।

2

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

— jpmc26

2

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

— সিএসিজ

33

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

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

— JimmyJames
সূত্র

বাহ, আমার কাছে সত্যিই অদ্ভুত লাগছিল তবে এটি সাহায্য করে। আরও কিছু লোক কী বলে তাও দেখতে চাই। ধন্যবাদ.

— স্নুপ

2

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

— আর্সেনী মোরজেনকো

2

@ মাইনমা বা virtual... এবং আপনি যদি পদ্ধতিটিকে ওভাররাইড করছেন তবে সংজ্ঞা অনুসারে এটি হওয়া দরকার virtualবা abstract।

— পোকেছু

1

@ পোকেছু 22: সত্যই, virtualকাজ করে। সমস্ত ক্ষেত্রে, ওপি অনুসারে স্বাক্ষরটি public void ReverseData()তাই ওভাররাইডিং স্টাফ সম্পর্কে উত্তরের অংশটি কিছুটা বিভ্রান্তিকর।

— আরসেনি মরজেনকো 20 '10

@ ম্যানমা আপনি বলছেন যে একটি বেস ক্লাস পদ্ধতি যদি ভার্চুয়াল পদ্ধতিটিকে কল করে তবে এটি যদি না হয় তবে সাধারণ ভার্চুয়াল পদ্ধতিতে আচরণ করে না abstract? আমি abstractবনাম সম্পর্কে উত্তরগুলি সন্ধান করেছি virtualএবং এটি উল্লিখিতটি দেখতে পেলাম না: বরং বিমূর্তির অর্থ হ'ল কোনও মূল সংস্করণ নেই no

— জেডিগোগস

20

একেবারে।

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

জনসাধারণের পদ্ধতিতে কল করার ক্ষেত্রে কোনও ভুল নেই। আপনার প্রশ্নের উদাহরণটি এমন একটি পরিস্থিতির নিখুঁত উদাহরণ যেখানে দুটি জনসাধারণের পদ্ধতি হ'ল আপনার যা করা উচিত।

তবে, আপনি নিম্নোক্ত নিদর্শনগুলির জন্য সাবধানতার সাথে লক্ষ্য রাখতে পারেন:

একটি পদ্ধতিতে এইরকম Hello()কল হয় World(string, int, int):
```
Hello()
{
    this.World("Some magic value here", 0, 100);
}
```
এই প্যাটার্নটি এড়িয়ে চলুন। পরিবর্তে, ব্যবহার করুন চ্ছিক আর্গুমেন্ট । Alচ্ছিক আর্গুমেন্টগুলি আবিষ্কারের সহজতর করে তোলে: কলকারী যিনি টাইপ করেন Hello(তা অগত্যা জানতে পারবেন না যে এমন একটি পদ্ধতি রয়েছে যা ডিফল্ট মান সহ পদ্ধতিটিকে কল করা সম্ভব করে। Alচ্ছিক যুক্তিগুলি স্ব-ডকুমেন্টিংও। World()প্রকৃত ডিফল্ট মানগুলি কী তা কলকারীকে দেখায় না।
একটি পদ্ধতি Hello(ComplexEntity)World(string, int, int)এইরকম কল হয় :
```
Hello(ComplexEntity entity)
{
    this.World(entity.Name, entity.Start, entity.Finish);
}
```
পরিবর্তে, ওভারলোডগুলি ব্যবহার করুন । একই কারণ: ভাল আবিষ্কার। কলকারী ইন্টেলিজেন্সের মাধ্যমে সমস্ত ওভারলোডগুলি একবারে দেখতে পায় এবং সঠিকটি চয়ন করতে পারে।
একটি পদ্ধতি কোনও উল্লেখযোগ্য মান যোগ না করেই অন্যান্য জনসাধারণ পদ্ধতিতে কল করে।

আবার ভাব. আপনার কি সত্যিই এই পদ্ধতিটি দরকার? অথবা আপনি কি এটি সরিয়ে ফেলা উচিত এবং কলকারীকে বিভিন্ন পদ্ধতি জিজ্ঞাসা করতে দেওয়া উচিত? একটি ইঙ্গিত: যদি পদ্ধতির নামটি সঠিক না মনে হয় বা এটি খুঁজে পাওয়া শক্ত হয় তবে আপনার সম্ভবত এটি অপসারণ করা উচিত।
একটি পদ্ধতি ইনপুটকে বৈধতা দেয় এবং তারপরে অন্য পদ্ধতিটিকে কল করে:
```
Hello(string name, int start, int end)
{
    if (name == null) throw new ArgumentNullException(...);
    if (start < 0) throw new OutOfRangeException(...);
    ...
    if (end < start) throw new ArgumentException(...);

    this.World(name, start, end);
}
```
পরিবর্তে, Worldএর পরামিতিগুলি নিজেই বৈধ করা উচিত, বা ব্যক্তিগত হওয়া উচিত।

— আরসেনি মরজেনকো
সূত্র

রিভার্সডেটা আসলে অভ্যন্তরীণ থাকলে এবং "অবজেক্ট" এর উদাহরণ সহ পুরো নেমস্পেসে ব্যবহার করা যদি একই চিন্তাভাবনাগুলি প্রয়োগ করে?

— স্নুপ

1

@ স্টেভিভি: হ্যাঁ, অবশ্যই

— আর্সেনী মরজেনকো

@ মাইনমা আমি 1 এবং 2

— কাপল

@ কাপল: আপনার মতামতের জন্য আপনাকে ধন্যবাদ আমি প্রথম দুটি বিষয় সম্পর্কে ব্যাখ্যা যুক্ত করে আমার উত্তর সম্পাদনা করেছি।

— আর্সেনী মোরজেনকো 15:38

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

— ব্রায়ান

8

যদি কিছু প্রকাশ্যে হয় তবে যে কোনও সময় এটি কোনও সিস্টেমের দ্বারা কল হতে পারে। আপনিও সেই সিস্টেমে অন্যতম হতে পারবেন না এমন কোনও কারণ নেই!

অত্যন্ত অনুকূলিত পাঠাগারগুলিতে, আপনি যে প্রতিমাটি রেখেছেন তা অনুলিপি করতে চান java.util.ArrayList#ensureCapacity(int) ।

ensureCapacity

ensureCapacity প্রকাশ্য
ensureCapacity সমস্ত প্রয়োজনীয় সীমা পরীক্ষা করা এবং ডিফল্ট মান ইত্যাদি রয়েছে has
ensureCapacity কল ensureExplicitCapacity

ensureCapacityInternal

ensureCapacityInternal ব্যক্তিগত
ensureCapacityInternal সর্বনিম্ন ত্রুটি পরীক্ষা করে দেখা হয়েছে কারণ সমস্ত ইনপুট ক্লাসের ভিতরে থেকে আসে
ensureCapacityInternal ALSO কল ensureExplicitCapacity

ensureExplicitCapacity

ensureExplicitCapacity ALSO বেসরকারী
ensureExplicitCapacityহয়েছে কোন ত্রুটি পরীক্ষা
ensureExplicitCapacity প্রকৃত কাজ করে
ensureExplicitCapacityকোথাও থেকে ensureCapacityএবং ছাড়াও কল করা হয় নাensureCapacityInternal

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

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

— corsiKa
সূত্র

3

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

পাবলিক পদ্ধতিতে সাধারণত "অব্যাহত অবস্থায় অবজেক্টটি গ্রহণ করুন, বুদ্ধিমান কিছু করুন, অবজেক্টটিকে একটি (সম্ভবত ভিন্ন) সামঞ্জস্যপূর্ণ অবস্থায় রেখে দিন" এর একটি চুক্তি রয়েছে। এখানে, "সামঞ্জস্যপূর্ণ" এর অর্থ হতে পারে, উদাহরণস্বরূপ, যে Lengthএকটি এর List<T>তার চেয়ে বড় হয় Capacityএবং যে থেকে সূচকের এ উপাদানের উল্লেখ 0করতেLength-1 নিক্ষেপ করা হবে না।

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

— Joker_vD
সূত্র

1

অন্য কোনও পাবলিক পদ্ধতির অভ্যন্তরে জনসাধারণকে কল করার ক্ষেত্রে আরেকটি উদাহরণ হ'ল কানেক্সেকিউট / এক্সিকিউটিভ পদ্ধতির। আমার যখন বৈধতা এবং আক্রমণকারী সংরক্ষণ উভয় প্রয়োজন তখন আমি এটি ব্যবহার করি ।

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

— Zapadlo
সূত্র

-5

দুঃখিত তবে আমি অন্যান্য 'হ্যাঁ আপনি করতে পারেন' উত্তরগুলির সাথে বেশিরভাগের সাথে একমত হতে এবং বলতে পারেন:

আমি একজন শ্রেণিকে অন্যের কাছ থেকে জনসাধারণের পদ্ধতিতে ডাকতে নিরুৎসাহিত করব

এই অনুশীলনটি নিয়ে বেশ কয়েকটি সম্ভাব্য সমস্যা রয়েছে।

1: উত্তরাধিকারসূত্রে প্রাপ্ত শ্রেণিতে অসীম লুপ

সুতরাং আপনার বেস শ্রেণিটি পদ্ধতি 2 থেকে মেথড 1 কে কল করে কিন্তু তারপরে আপনি বা অন্য কেউ তা থেকে উত্তরাধিকার সূত্রে আসে এবং মেথড 1 কে একটি নতুন পদ্ধতির সাথে লুকিয়ে রাখে যাকে মেথড 2 বলে।

2: ইভেন্টস, লগিং ইত্যাদি

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

3: থ্রেডিং এবং অন্যান্য ডেডলকস

উদাহরণস্বরূপ InsertComplexData একটি db সংযোগ খোলে, লেনদেন শুরু করে, একটি টেবিল লক করে, তারপরে InsertSimpleData কে সংযোগ খোলে একটি লেনদেন শুরু করে, টেবিলটি আনলক হওয়ার জন্য অপেক্ষা করে ....

আমি নিশ্চিত যে এর আরও বেশি কারণ রয়েছে, অন্য একটি উত্তর 'আপনি পদ্ধতি 1 সম্পাদনা করেন এবং অবাক হন পদ্ধতি 2 ভিন্ন আচরণ শুরু করে' এ স্পর্শ করে

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

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

ওপিতে নির্দিষ্ট ক্ষেত্রে প্রসারিত করতে দেয়।

আমাদের প্রচুর বিশদ নেই তবে আমরা জানি যে রিভার্সডাটা কোনও ধরণের ইভেন্ট হ্যান্ডলার পাশাপাশি শিডিয়ুল ট্রান্সমিশন পদ্ধতি দ্বারা ডাকা হয়।

আমি ধরে নিই যে বিপরীত তথ্যও বস্তুর অভ্যন্তরীণ স্থিতি পরিবর্তন করে

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

রিভার্সডাটা থ্রেডটিকে নিরাপদ করতে আপনি একটি লক যুক্ত করতে পারেন। তবে শিডিয়ুল ট্রান্সমিশনটিতে থ্রেড নিরাপদ থাকা দরকার থাকলে আপনি একই লকটি ভাগ করতে চাইবেন।

এটি করার সবচেয়ে সহজ উপায় হ'ল রিভার্সডেটা কোডটি একটি ব্যক্তিগত পদ্ধতিতে সরানো এবং উভয় জনসাধারণের পদ্ধতিতে এটি কল করা। এরপরে আপনি সর্বজনীন পদ্ধতিতে লক স্টেটমেন্টটি রেখে একটি লক অবজেক্টটি ভাগ করতে পারেন।

অবশ্যই আপনি তর্ক করতে পারেন "এটি কখনই ঘটবে না!" বা "আমি অন্য উপায়ে লকটি প্রোগ্রাম করতে পারতাম" তবে ভাল কোডিং অনুশীলনের মূল বিষয়টি হ'ল প্রথমে আপনার কোডটি ভালভাবে গঠন করা।

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

হেরস আরেকটি: আপনিও সম্ভাব্যভাবে ডিডিডি লঙ্ঘন করেন। যদি আপনার অবজেক্ট কোনও ডোমেন অবজেক্ট হয় তবে এর সর্বজনীন পদ্ধতিগুলি ডোমেন শর্তাদি হওয়া উচিত যা ব্যবসায়কে কিছু বোঝায়। এক্ষেত্রে এর খুব কমই সম্ভাবনা রয়েছে যে 'এক ডজন ডিম কিনুন' 12 বার 1 ডিম কিনে 'একইভাবে শুরু হয় এমনকি যদি এটি শুরু হয়।

— ইওয়ান
সূত্র

3

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

— ডপপেলগ্র্রেনার

হুবহু, যদি তা না হয় তবে আপনার ইভেন্টটি রাখার জায়গা নেই। একইভাবে # 3 দিয়ে সমস্ত কিছু ঠিক আছে যতক্ষণ না আপনার শৃঙ্খলে নিচে একটি পদ্ধতি লেনদেনের প্রয়োজন হয়, তারপরে আপনি বিভ্রান্ত হন

— ইভান

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

— ডপপেলগ্রিনিয়ার

আমার উদাহরণ শেয়ারের একমাত্র 'কোড'টি হ'ল একটি পাবলিক পদ্ধতি যা অন্যজনকে কল করে। আপনি যদি তার 'খারাপ কোড' ভাল বলে মনে করেন! এটি আমার মতামত

— ইওয়ান

আপনি নিজের হাত ভেঙে হাতুড়ি ব্যবহার করতে পারবেন তার অর্থ এই হাতুড়িটি খারাপ is এর অর্থ এটি আপনার এমন কিছু করা উচিত নয় যা আপনার হাতটি ভেঙে দেবে।

— ডপপেলগ্রিনিয়ার