"গভীর সংমিশ্রনের স্তরক্রম" কি খুব খারাপ নয়?


19

"কম্পোজিশন হায়ারার্কি" কোনও জিনিস না হলে ক্ষমা প্রার্থনা করছি, তবে আমি প্রশ্নটিতে এর অর্থ কী তা ব্যাখ্যা করব।

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

ধরা যাক আমাদের পরীক্ষার ফলাফল বিশদ বিবরণী সংগ্রহের প্রয়োজন:

class Model {
    // ... interface

    Array<Result> m_results;
}

প্রতিটি ফলাফলের নির্দিষ্ট বৈশিষ্ট্য রয়েছে। এর মধ্যে রয়েছে পরীক্ষার সময়, পাশাপাশি পরীক্ষার প্রতিটি স্তর থেকে কিছু মেটা-ডেটা:

enum Stage {
    Pre = 1,
    Post
};

class Result {
    // ... interface

    Epoch m_epoch;
    Map<Stage, ExperimentModules> m_modules; 
}

ঠিকাছে দারুন. এখন, প্রতিটি পরীক্ষামূলক মডিউলটিতে পরীক্ষার ফলাফল বর্ণনা করার পাশাপাশি একটি পরীক্ষামূলক নমুনা সেটের উল্লেখগুলির একটি স্ট্রিং রয়েছে:

class ExperimentalModules {
    // ... interface

    String m_reportText;
    Array<Sample> m_entities;
}

এবং তারপরে প্রতিটি নমুনায় রয়েছে ... ভাল, আপনি ছবিটি পাবেন।

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

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


বাহ্যিক প্রসঙ্গ অংশটি বোঝেন না।
তুলাইনস কর্ডোভা

@ তুলিনস কর্ডোভা যা আমি এখানে জিজ্ঞাসা করার চেষ্টা করছি তা কি "এমন পরিস্থিতি রয়েছে যার জন্য গভীর রচনাটি একটি ভাল সমাধান"?
আশ্চর্যজনক

আমি একটি উত্তর যুক্ত করেছি।
তুলাইনস কর্ডোভা

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

3
গভীর ডেটা মডেলগুলির সাথে আমি কোনও ভুল দেখছি না। তবে আমি এটিও দেখছি না যে আপনি কীভাবে এটি উত্তরাধিকারের সাথে মডেল করতে পারতেন কারণ এটি প্রতিটি স্তরের 1: N এর সম্পর্ক।
usr

উত্তর:


17

এই কি Demeter / কমপক্ষে জ্ঞান নীতিকে আইন সম্পর্কে। ব্যবহারকারীর অবশ্যই তাদের কাজটি করার জন্য 'ইন্টারফেস' Modelসম্পর্কে জেনে রাখা উচিত নয় ExperimentalModules

সাধারণ সমস্যাটি হ'ল যখন কোনও শ্রেণি অন্য ধরণের থেকে উত্তরাধিকার সূত্রে আসে বা কোনও প্রকারের সাথে সর্বজনীন ক্ষেত্র থাকে বা যখন কোনও পদ্ধতি প্যারামিটার হিসাবে কোনও প্রকার গ্রহণ করে বা কোনও প্রত্যাবর্তন করে, তখন all সমস্ত ধরণের ইন্টারফেসগুলি আমার শ্রেণির কার্যকর ইন্টারফেসের অংশ হয়ে যায়। প্রশ্নটি হয়ে ওঠে: এই ধরণের যেগুলির উপর আমি নির্ভর করি: সেগুলি কি আমার শ্রেণির পুরো পয়েন্টটি ব্যবহার করছে? বা এগুলি কি কেবল বাস্তবায়নের বিশদ যা আমি দুর্ঘটনাক্রমে প্রকাশ করেছি? কারণ যদি তারা বাস্তবায়নের বিশদ হয় তবে আমি কেবল তাদের প্রকাশ করেছি এবং আমার ক্লাসের ব্যবহারকারীদের তাদের উপর নির্ভর করতে দিয়েছি - আমার ক্লায়েন্টরা এখন আমার বাস্তবায়নের বিবরণে দৃly়ভাবে মিলিত হয়েছে।

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

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

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

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


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

7

"গভীর সংমিশ্রনের স্তরক্রম" কি খুব খারাপ নয়?

অবশ্যই. নিয়মে আসলে বলা উচিত "সমস্ত শ্রেণিবিন্যাস যতটা সম্ভব সমতল রাখুন"।

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

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


4

প্যারাফ্রেসিং আইনস্টাইন:

সমস্ত শ্রেণিবিন্যাস যথাসম্ভব সমতল রাখুন, তবে চাটুকার নয়

অর্থ আপনি মডেলিংয়ের সমস্যাটি যদি এমন হয় তবে এটির মডেলিংটি যেমন হয় তেমন আপনার কোয়ালিটি থাকা উচিত নয়।

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


1

হ্যাঁ, আপনি এটি সম্পর্কিত টেবিলগুলির মতো মডেল করতে পারেন

Result {
    Id
    ModelId
    Epoch
}

ইত্যাদি যা প্রায়শই সহজেই প্রোগ্রামিং এবং ডেটাবেজে সহজ ম্যাপিংয়ের দিকে পরিচালিত করতে পারে। তবে আপনার সম্পর্কের হার্ড কোডিং হারানোর ব্যয়ে


0

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

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

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