তথ্য সীমানা জুড়ে তথ্য স্পিলিং

Question

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

উদাহরণ হিসাবে ধরা যাক যে আমাদের কাছে একটি অর্ডার রয়েছে যার বেশিরভাগ অর্ডার আইটেম রয়েছে যা একটি ইনভেন্টরি আইটেমকে বোঝায় যার দাম রয়েছে। আমি অর্ডার.গেটটোটাল () কে অনুরোধ করছি যা অর্ডার আইটেম.গেটপ্রিস () এর ফলাফলের যোগান দেয় যা ইনভেন্টরি আইটেম.গেটপ্রাইস () দ্বারা পরিমাণকে বহুগুণ করে। এ পর্যন্ত সব ঠিকই.

তবে তারপরে আমরা জানতে পারি যে কয়েকটি আইটেম দুটি করে একটি চুক্তিতে বিক্রি হয়। আমরা অর্ডার আইটেম.গেটপ্রিস () ইনভেন্টরি আইটেম.গেটপ্রিস (পরিমাণ) এর মতো কিছু করে এবং ইনভেন্টরি আইটেমকে এর সাথে চুক্তি করে এটি পরিচালনা করতে পারি।

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

তবে তারপরে আমাদের গ্রাহক সিস্টেমে কত দিন থেকেছেন তার উপর নির্ভর করে আমাদের বিভিন্ন মূল্য সমর্থন করতে হবে: ইনভেন্টরি আইটেম.গেটপ্রিস (পরিমাণ, অর্ডার.গেটডেট (), অর্ডার।গেটকাস্টমার ())

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

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

এটি মোকাবেলার জন্য ভাল কৌশল আছে? অন্যরাও কি একই সমস্যা খুঁজে পায়?

Comments

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

— ক্রিস

@ ক্রিস, হ্যাঁ, মূল্য নির্ধারণের যুক্তি ছড়িয়ে দেওয়া সম্ভবত একটি ভাল ধারণা। আমার সমস্যাটি হ'ল এই জাতীয় বস্তুটি অর্ডার সম্পর্কিত সমস্ত বস্তুর সাথে শক্তভাবে মিলিত হবে। আমাকে যে অংশটি বিরক্ত করে এবং আমি এড়াতে পারি তা ভাবছি ering

— উইনস্টন ইওয়ার্ট

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

— ক্রিস

Answer 1

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

এটি কি একটি নিখুঁত সমাধান, না। আমাদের কাছে এখনও অন্য শ্রেণীর সম্পর্কে জ্ঞানার্জনের এক শ্রেণি রয়েছে তবে কমপক্ষে আমরা সেই প্রয়োজনটি ব্যবসায়িক অবজেক্টের বাইরে এবং ব্যবসায়িক যুক্তি শ্রেণিতে স্থান করে নিয়েছি।

Comments

সন্দেহ হলে অন্য একটি ক্লাস যুক্ত করুন।

— ক্রিস

Answer 2

আপনি মত শোনাচ্ছে একটি পৃথক ছাড়ের বস্তু (বা তাদের একটি তালিকা) যে যে সব উপাদান ট্র্যাক রাখে প্রয়োজন, এবং তারপর কিছু মত, অর্ডার ছাড়ের (গুলি) আবেদন Order.getTotal(Discount)বা Discount.applyTo(Order)বা অনুরূপ।

Comments

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

— উইনস্টন ইওয়ার্ট

আমি মনে করি ছাড়ের বস্তুর একটি ভাল ধারণা, কিন্তু আমি এটা একটি পর্যবেক্ষক ধরণ (বাস্তবায়ন করতে হবে en.wikipedia.org/wiki/Observer_pattern ), বিষয় হিসেবে ডিসকাউন্ট প্যাটার্ন (গুলি) সঙ্গে

— BlackICE

Answer 3

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

সম্পাদনা: উইনস্টনের মন্তব্যের প্রতিক্রিয়া

আমি মনে করি না যে আপনার কোনও আইটেম আইটেমের মোটেই প্রয়োজন ... কমপক্ষে আপনি যেভাবে ব্যবহার করছেন সেভাবে। আমার পরিবর্তে একটি ইনভেন্টরি ক্লাস থাকবে যা একটি ইনভেন্টরি ডাটাবেস পরিচালনা করে।

আমি কোনও আইডি দ্বারা ইনভেন্টরি আইটেমগুলি উল্লেখ করব। প্রতিটি অর্ডারে ইনভেন্টরি আইডির তালিকা এবং সংশ্লিষ্ট পরিমাণের পরিমাণ থাকবে।

তারপরে আমি এরকম কিছু দিয়ে অর্ডারের মোট গণনা করব।
Inventory.GetCost (আইটেম, customerName, তারিখ)

তারপরে আপনার মতো অন্যান্য সহায়ক ফাংশন থাকতে পারে:

ইনভেন্টরি.আইটেমলিফ্টস (ইন আইটেমআইডি)
ইনভেন্টরি.এডডিটেম (ইন আইটেমআইডি, ইনট পরিমাণ)
ইনভেন্টরি.আরমোভ আইটেম
(ইন আইটেম আইডি, ইনট পরিমাণ) ইনভেন্টরি.এডড বিজনেসরুল (...)
ইনভেন্টরি.ডিলিট বিজনেসআরুল (...)

Comments

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

— উইনস্টন ইওয়ার্ট

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

— উইনস্টন এওয়ার্ট

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

— উইনস্টন ইওয়ার্ট

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

— পেমদাস

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

— পেমদাস

Answer 4

এই সম্পর্কে আরও চিন্তা করার পরে, আমি আমার নিজস্ব বিকল্প কৌশল নিয়ে এসেছি।

একটি মূল্য শ্রেণীর সংজ্ঞা দিন। Inventory.GetPrice()একটি মূল্য বস্তু প্রদান করে

Price OrderItem::GetPrice()
{
    return inventory.GetPrice().quantity(quantity);
}

Currency OrderItem::GetTotal()
{
    Price price = empty_price();
    for(item in order_items)
    {
         price = price.combine( item.GetPrice() )
    }
    price = price.date(date).customer(customer);
    return price.GetActualPrice();
}

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