গেটার্সে কতটা লজিক

Question

আমার সহকর্মীরা আমাকে বলছেন যে গেটার্স এবং সেটারগুলিতে যতটা সম্ভব যুক্তিযুক্ত হওয়া উচিত।

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

আমি যা করি তার একটি উদাহরণ:

public List<Stuff> getStuff()
{
   if (stuff == null || cacheInvalid())
   {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

কীভাবে কাজ আমাকে কাজগুলি করতে বলে তার উদাহরণ (তারা আঙ্কেল বব থেকে 'ক্লিন কোড' উদ্ধৃত করে):

public List<Stuff> getStuff()
{
    return stuff;
}

public void loadStuff()
{
    stuff = getStuffFromDatabase();
}

একটি সেটার / গেটারে কত যুক্তি যুক্ত? ডেটা আড়াল করার লঙ্ঘন বাদে খালি গেটার এবং সেটটার ব্যবহার কী?

Comments

এটি আমার কাছে ট্রাইগেট স্টাফ () এর মতো আরও মনে হচ্ছে ...

— বিল

এটি 'গেটর' নয়। এই শব্দটি কোনও সম্পত্তির পঠিত অ্যাক্সেসরের জন্য ব্যবহৃত হয়, এমন কোনও পদ্ধতি নয় যা আপনি ঘটনাক্রমে নামে 'গেট' রাখেন।

— বরিস ইয়াঙ্কভ

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

— জন হান্না

@ বরিসইয়ানকভ ভাল ... দ্বিতীয় পদ্ধতি হ'ল। public List<Stuff> getStuff() { return stuff; }

— আর স্মিটজ

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

— আলেকজান্ডার

Answer 1

কাজ আপনাকে যেভাবে কাজ করতে বলেছে তা লম্পট।

থাম্বের নিয়ম হিসাবে, আমি যেভাবে জিনিসগুলি করি তা নিম্নরূপ: স্টাফগুলি পাওয়া যদি গণনার তুলনায় সস্তা হয়, (বা যদি বেশিরভাগ সম্ভাবনা থাকে তবে এটি ক্যাশে পাওয়া যায়), তবে আপনার স্টেট স্টাফ () খুব ভাল। স্টাফটি পাওয়া যদি কম্পিউটারের জন্য ব্যয়বহুল হিসাবে পরিচিত হয়, এত ব্যয়বহুল যে এর ব্যয়বহুলতার বিজ্ঞাপনটি ইন্টারফেসে করা জরুরি, তবে আমি এটিকে getStuff () বলব না, আমি একে ক্যালকুলেট স্টাফ () বা এমন কিছু বলব, যাতে এটি ইঙ্গিত দেওয়া যায় কিছু কাজ করতে হবে।

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

Comments

ক্রিয়াকলাপ ক্রম জটিলতার কথা উল্লেখ করার জন্য +1। কার্যকারণ হিসাবে, সম্ভবত কাজটি আমাকে সর্বদা কনস্ট্রাক্টরে লোড স্টাফ () কল করতে বলবে, তবে এটি খুব খারাপ হবে কারণ এর অর্থ এটি সর্বদা লোড করতে হবে। প্রথম উদাহরণে, ডেটা অলসভাবে কেবল তখনই লোড করা হয় যখন প্রয়োজন হয় ততটাই ভাল।

— লরেন্ট

আমি সাধারণত "যদি এটি সত্যিই সস্তা হয় তবে একটি সম্পত্তি প্রাপ্তি ব্যবহার করুন it এটি ব্যয়বহুল হলে একটি ফাংশন ব্যবহার করুন" follow এটি সাধারণত আমার ভাল পরিবেশন করে এবং যথাযথ নামকরণ যেমনটি আপনি জোর দেওয়ার জন্য ইঙ্গিত করেছিলেন তাও আমার কাছে ভাল বলে মনে হয়।

— ডেনিস ট্রোলার

যদি এটি ব্যর্থ হতে পারে - এটি প্রাপ্তি নয়। এক্ষেত্রে ডিবির লিঙ্ক নিচে থাকলে কী হবে?

— মার্টিন বেকেট

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

— ইজকাটা

ভুলে যাবেন না যে loadStuff()ফাংশনটি আগে ফাংশনটির আগে ডাকা দরকার getStuff()তারও অর্থ ক্লাসটি হুডের নীচে যা চলছে তা সঠিকভাবে বিমূর্ত করা হচ্ছে না।

— rjzii

Answer 2

গেটারদের মধ্যে যুক্তি পুরোপুরি ঠিক আছে।

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

অন্যদিকে, বেশিরভাগ ওআরএম সংগ্রহের অলস লোডকে সমর্থন করে, যা মূলত আপনি যা করছেন।

Answer 3

আমি মনে করি যে 'ক্লিন কোড' অনুসারে এটিকে যথাসম্ভব বিভক্ত করা উচিত, এমন কিছুতে:

public List<Stuff> getStuff() {
   if (hasStuff()) {
       return stuff;
   }
   loadStuff();
   return stuff;
}

private boolean hasStuff() {
    if (stuff == null) {
       return false;
    }
    if (cacheInvalid()) {
       return false;        
    }
    return true;
} 

private void loadStuff() {
    stuff = getStuffFromDatabase();
}

অবশ্যই, এটি সম্পূর্ণ বোকামি, আপনি যে সুন্দর রূপটি লিখেছেন তা কোডের একটি ভগ্নাংশের সাথে সঠিক জিনিসটি করেছে যা যে কেউ এক নজরে বুঝতে পারে:

public List<Stuff> getStuff() {
   if (stuff == null || cacheInvalid()) {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

জিনিসগুলি কীভাবে হুডের নীচে যায় তা কলারের মাথা ব্যথা হওয়া উচিত নয় এবং বিশেষত কোনও কিছু নির্বিচারে "ডান অর্ডার" করে জিনিসগুলি কল করা মনে রাখা কলারের মাথাব্যথা হওয়া উচিত নয়।

Comments

-1। আসল মাথাব্যথা হবে যখন কলার আটকে গিয়ে এই বিষয়টি নির্ণয় করে যে কেন একটি সাধারণ গেটর কলটির ফলে ধীর-নরকের ডাটাবেস অ্যাক্সেস হয়েছিল।

— ডোমেনিক

@ ডমিনিক: ডাটাবেস অ্যাক্সেস যাইহোক সম্পন্ন করতে হবে, আপনি কারও কর্মক্ষমতা না করে সংরক্ষণ করছেন না। আপনার যদি List<Stuff>এটির প্রয়োজন হয় তবে এটি পাওয়ার একমাত্র উপায়।

— ডেড এমএমজি

@ লুলাকাস: ধন্যবাদ, কোডের তুচ্ছ বিটগুলি তৈরি করার জন্য 'ক্লিন' কোডে ব্যবহৃত সমস্ত কৌশলগুলি আমি এখনও মনে করতে পারি নি ;-) এখন ঠিক আছে।

— জুনাস পুলাক্কা

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

— কেভিন ক্লিন

আমি এই উত্তরের শুরুটি পড়েছি, এবং "বাইরের পুস্তক সেখানে অন্য বইয়ের উপাসক যায়" ভেবে আমি এটিকে বাইপাস করতে যাচ্ছিলাম এবং তারপরে "অবশ্যই এটি সম্পূর্ণ বোকামি" অংশটি আমার নজর কেড়েছিল। ভাল বলেছ! সি -: =

— মাইক নকিস

Answer 4

তারা আমাকে জানিয়েছে যে গেটার্স এবং সিটারগুলিতে যতটা সম্ভব যুক্তিযুক্ত হওয়া উচিত।

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

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

Answer 5

আপনি ঠিক বলেছেন, আপনার সহকর্মীরা ভুল।

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

আপনি তাদের হাইবারনেটে নির্দেশ করতে পারেন, যেখানে 'getStuff ()' কিছু খুব জটিল জিনিস করতে পারে এবং ব্যর্থতার জন্য একটি রানটাইম এক্সেকশন ছুড়ে দেয়।

Comments

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

— এফএমজাগুয়ার

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

— কেভিন cline

যদি সেই শ্রেণিটি একটি ওআরএম শ্রেণি হয়, তবে অন্য প্রসঙ্গে ইতিমধ্যে অভিপ্রায়টি প্রকাশ করা হয়েছে: প্রশ্নটি রয়ে গেছে: "অন্য প্রোগ্রামার কীভাবে গেটরকে কল করার পার্শ্ব প্রতিক্রিয়াগুলি জানতে পারে?"। প্রোগ্রামটিতে 1k ক্লাস এবং 10 কে গেটার রয়েছে, এমন নীতি যা তাদের যে

— কোনওটিতে

Answer 6

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

List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

উল্টোদিকে:

myObject.load();
List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

বা আরও খারাপ:

myObject.loadNames();
List<String> names = clientRoster.getNames();
myOjbect.loadEmails();
List<String> emails = clientRoster.getEmails();

যা কেবলমাত্র অন্যান্য কোডকে আরও বেশি বাড়াবাড়ি এবং পড়া আরও শক্ত করে তোলে কারণ আপনাকে একই ধরণের সমস্ত কলগুলির মাধ্যমে ওয়াডিং শুরু করতে হবে। অতিরিক্তভাবে, লোডার ফাংশনগুলি বা অনুরূপকে কল করা এমনকি ওওপি ব্যবহারের পুরো উদ্দেশ্যটিকেও ভেঙে দেয় যাতে আপনি যে বস্তুর সাথে কাজ করছেন তার বাস্তবায়ন বিবরণ থেকে দূরে সরে যাচ্ছেন না। আপনার যদি কোনও clientRosterঅবজেক্ট থাকে তবে আপনাকে কীভাবে getNamesকাজ করে সে সম্পর্কে যত্ন নেওয়ার দরকার নেই, যেমন আপনাকে যদি কোনও কল করতে হয় তবে আপনাকে loadNamesকেবল এটি জানা উচিত getNamesযা আপনাকে List<String>ক্লায়েন্টদের নাম দিয়ে দেয় ।

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

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

Answer 7

একজন গ্রাহককে কল করা ক্ষেত্র পড়ার মত একই আচরণ প্রদর্শন করা উচিত:

• মানটি পুনরুদ্ধার করার জন্য এটি সস্তা হওয়া উচিত
• আপনি যদি সেটার দিয়ে কোনও মান সেট করেন এবং তারপরে এটি গেটরের সাথে পড়েন, মানটি একই হওয়া উচিত
• মানটি পেতে কোনও পার্শ্ব প্রতিক্রিয়া থাকা উচিত
• এটি একটি ব্যতিক্রম নিক্ষেপ করা উচিত নয়

Comments

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

— সর্বোচ্চ

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

— টিএমএন

@ টিএমএন: সর্বোত্তম ক্ষেত্রে দৃশ্যে শ্রেণিটি এমনভাবে সংগঠিত করা উচিত যাতে গ্রাহকদের ব্যতিক্রম ছিন্ন করতে সক্ষম অপারেশন চালানোর প্রয়োজন হয় না । যে জায়গাগুলি ব্যতিক্রম ছুঁড়ে ফেলতে পারে তা হ্রাস করা কম অপ্রত্যাশিত বিস্ময়ের দিকে নিয়ে যায়।

— hugomg

আমি একটি নির্দিষ্ট উদাহরণ দিয়ে দ্বিতীয় বিন্দু সঙ্গে মতানৈক্য যাচ্ছি: foo.setAngle(361); bar = foo.getAngle()। barহতে পারে 361, তবে এটি 1বৈধভাবেও হতে পারে যদি কোণগুলি একটি সীমার সাথে আবদ্ধ থাকে।

— zzzzBov

-1। (1) হয় এই উদাহরণে সস্তা - অলস লোড পর। (2) বর্তমানে কোন "সেটার" উদাহরণে, কিন্তু যদি কেউ পর এক, এবং এটা সেট যোগ stuff, সংগ্রহকারী হবে একই মান ফিরে। (3) উদাহরণ হিসাবে দেখানো হিসাবে অলস লোডিং "দৃশ্যমান" পার্শ্ব প্রতিক্রিয়া তৈরি করে না। (4) বিতর্কযোগ্য, সম্ভবত একটি বৈধ পয়েন্ট, যেহেতু "অলস লোডিং" প্রবর্তন করার পরে প্রাক্তন এপিআই চুক্তিটি পরিবর্তিত হতে পারে - তবে সিদ্ধান্ত নেওয়ার জন্য সেই চুক্তির দিকে নজর দিতে হবে।

— ডক ব্রাউন

Answer 8

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

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

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

ঠিক যখন সূচনা ঘটে তখন গুরুত্বপূর্ণ বা নাও হতে পারে।

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

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

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

Answer 9

@ মাইকনাকিস যেমন বলেছিলেন ঠিক তেমনই করুন ... আপনি যদি কেবল জিনিসটি পান তবে তা ঠিক আছে ... আপনি যদি অন্য কিছু করেন তবে কাজটি করে এবং এটি সর্বজনীন করে এমন একটি নতুন ফাংশন তৈরি করে।

আপনার সম্পত্তি / ফাংশন যদি কেবল নামটি যা বলে তা করছে তবে জটিলতার বেশি জায়গা নেই। একাত্মতা হ'ল মূল আইএমও

Comments

এটি সম্পর্কে সতর্কতা অবলম্বন করুন, আপনি আপনার অভ্যন্তরীণ অবস্থাটির অত্যধিক পরিমাণের বহিঃপ্রকাশ ঘটাতে পারেন। আপনি খালি অনেক সঙ্গে গুটান চাই না loadFoo()বা preloadDummyReferences()বা createDefaultValuesForUninitializedFields()পদ্ধতি মাত্র কারণ আপনার বর্গ প্রাথমিক বাস্তবায়ন তাদের প্রয়োজন ছিল।

— টিএমএন

অবশ্যই ... আমি কেবল বলছিলাম যে আপনি যদি নামটি করেন তবে

— এমনটি করা হয়েছে

Answer 10

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

Answer 11

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

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

2. আপনি যদি এই ধরণের শ্রেণি তৈরি করতে না পারেন তবে সিদ্ধান্ত নিন যে আপনার যদি ট্রেড অফ রয়েছে এবং আপনি ভোক্তাকে ক্যাশে-চেকিং কোডটি এড়াতে বা না দেওয়ার অনুমতি দিতে চান তবে সিদ্ধান্ত নিতে হবে।

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

   2. যদি ক্যাশে চেকটি বাদ দেওয়া ঠিক থাকে বা এটি খুব জরুরী যে আপনি গেটে অভিনেতা (1) পারফরম্যান্সের গ্যারান্টিযুক্ত হন তবে আলাদা কল ব্যবহার করুন।

আপনি ইতিমধ্যে লক্ষ করেছেন যে, আমি "ক্লিন-কোড", "ছোট কিছুতে বিভক্ত সমস্ত কিছু" দর্শনের বড় ভক্ত নই। আপনার যদি অर्थোগোনাল ফাংশনগুলির একটি গুচ্ছ থাকে তবে যে কোনও ক্রমকে বিভক্ত করার জন্য ডাকা যেতে পারে আপনাকে অল্প ব্যয়ে আপনাকে আরও অভিব্যক্তিযুক্ত শক্তি দেবে। তবে, যদি আপনার ফাংশনগুলিতে অর্ডার নির্ভরতা থাকে (বা কেবলমাত্র একটি নির্দিষ্ট ক্রমে সত্যই কার্যকর) তবে সেগুলি বিভক্ত করার ফলে অল্প উপকার যোগ করার সাথে সাথে আপনি ভুল কাজগুলি করার উপায়গুলি কেবল বাড়িয়ে তোলেন।

Comments

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

— ডোমেনিক

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

— hugomg

Answer 12

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

Answer 13

এটি অলস লোডিংয়ের সাথে ক্যাশে থেকে পঠনের মতো দেখাচ্ছে। অন্যরা যেমন উল্লেখ করেছে, চেকিং এবং লোডিং অন্যান্য পদ্ধতিতে থাকতে পারে। লোডিং সিঙ্ক্রোনাইজ করার দরকার হতে পারে তাই আপনি একই সাথে বিশ থ্রেড সমস্ত লোড না পান।

getCachedStuff()গেটারের জন্য একটি নাম ব্যবহার করা উপযুক্ত হতে পারে কারণ এটির সাথে ধারাবাহিক কার্যকর সময় হয় না।

cacheInvalid()রুটিন কীভাবে কাজ করে তার উপর নির্ভর করে নাল পরীক্ষা করার প্রয়োজন হবে না। stuffডেটাবেস থেকে পপুলেশন না করা থাকলে আমি ক্যাশেটি বৈধ হওয়ার আশা করতাম না ।

Answer 14

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

কিছুটা এইরকম:

public List<Stuff> getStuff()
{
    return Collections.unmodifiableList(stuff);
}

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

Answer 15

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

interface StuffGetter {
     public List<Stuff> getStuff();
}

class StuffComputer implements StuffGetter {
     public List<Stuff> getStuff() {
         getStuffFromDatabase()
     }
}

class StuffCacher implements StuffGetter {
     private stuffComputer; // DI this
     private Cache<List<Stuff>> cache = new Cache<>();

     public List<Stuff> getStuff() {
         if cache.hasStuff() {
             return cache.getStuff();
         }

         List<Stuffs> stuffs = stuffComputer.getStuff();
         cache.store(stuffs);
         return stuffs;
     }
}

এই নকশাটি আপনাকে সহজেই ক্যাচিং যুক্ত করতে, ক্যাচিং সরিয়ে দিতে, অন্তর্নিহিত ডেরাইভেশন যুক্তিকে পরিবর্তন করতে দেয় (উদাঃ একটি ডিবি বনাম ফিরতি মক ডেটা অ্যাক্সেস) ইত্যাদি etc.

Answer 16

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

Comments

+1: আমি আপনার সাথে একমত! যদি অবজেক্টটি কেবল কিছু ডেটা ধরে রাখার জন্য বোঝানো হয়, তবে প্রাপ্তরা কেবলমাত্র বস্তুর বর্তমান সামগ্রীটি ফিরিয়ে আনবে। এক্ষেত্রে ডেটা লোড করা অন্য কিছু বস্তুর দায়িত্ব। যদি চুক্তিটি বলে যে অবজেক্টটি একটি ডাটাবেস রেকর্ডের প্রক্সি, তবে প্রাপ্তিটিকে ফ্লাইতে ডেটা আনতে হবে। এটি আরও জটিল হয়ে উঠতে পারে যদি ডেটা লোড করা হয়ে থাকে তবে তা আপ টু ডেট না থাকে: ডাটাবেসের পরিবর্তনের বিষয়ে অবজেক্টটি কি অবহিত করা উচিত? আমি মনে করি এই প্রশ্নের কোনও অনন্য উত্তর নেই।

— জর্জিও