ডেটা ওরিয়েন্টেড ইন্টারফেসগুলিতে প্রোগ্রামিং

Question

আমাদের কোডবেসের একটি অংশ নিম্নলিখিত স্টাইলে লেখা আছে:

// IScheduledTask.cs
public interface IScheduledTask
{
    string TaskName { get; set; }
    int TaskPriority { get; set; }
    List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein
}

// ScheduledTaskImpl.cs
public class ScheduledTaskImpl : IScheduledTask
{
    public string TaskName { get; set; }
    public int TaskPriority { get; set; }
    public List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein, 
    // perhaps a constructor or two for convenience.
}

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

Comments

আমি যে কারণটি করেছি তা COM সামঞ্জস্যের জন্য, তবে এটি এখানে আপনার কারণ বলে মনে হয় না।

— মাইক 0

@ মাইক আকর্ষণীয়, আমি কখনই COM ব্যবহার করি নি এবং এটি এখানে ব্যবহার করা হয় না। আমি কোডের এই বিভাগটির লেখককে জিজ্ঞাসা করব যে সে সিওএম ব্যবহার করার পরিকল্পনা করেছিল বা অন্য কিছু।

— ভলপেন

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

— Ixrec

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

— রডারবব

পূর্ববর্তী বেশিরভাগ মন্তব্য অকাল বিমূর্ততার একক প্রয়োগ "কোড গন্ধ" এ যায়; তবে এখানে একটি অ্যানিমিক ডোমেন মডেল "কোড গন্ধ "ও রয়েছে, দেখুন: মার্টিনফাউলার

— এরিক

Answer 1

আমার দুটি সেন্ট এখানে:

• আমরা নিশ্চিত না যে কোনও ডিটিও-তে কখনও কমপক্ষে কিছুটা আচরণ করা হবে না। সুতরাং আমার জন্য এমন কিছু জিনিস রয়েছে যা ভবিষ্যতে আচরণ করতে পারে বা নাও পারে।
• তাই অনেক একমাত্র-বাস্তবায়ন শ্রেণীর থাকার একটি সম্ভাব্য কারণ নকশা একটি অভাব , উদাহরণস্বরূপ দেখতে ব্যর্থ ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspection, ইত্যাদি, শুধুমাত্র এক পৃথকীকৃত হওয়া উচিত Schedulableকোনো প্রয়োগ schedulable উপার্জন ইন্টারফেস।
• ইন্টারফেসগুলি প্রথমে তৈরি করা একটি খুব ভাল অনুশীলন, এটি আপনাকে আপনার প্রয়োজনীয়তার অন্তর্দৃষ্টি দেয়। অনেকগুলি ইন্টারফেস কোনও বাস্তবায়ন না করেই শুরু হয়। তারপরে কেউ একটি বাস্তবায়ন লিখেন এবং তাদের কাছে এটি রয়েছে। আমি দ্বিতীয় দফায় যা উল্লেখ করেছি তা যদি আপনি এড়িয়ে যান তবে একক বাস্তবায়ন হওয়ার অবস্থা অস্থায়ী। আপনি কীভাবে আগেই জানবেন যে কোনও কোনও ইন্টারফেসের তৃতীয় বাস্তবায়নের দ্বিতীয়টি কখনই থাকবে না?
• আমরা একটি সুচিন্তিত ইন্টারফেসের জন্য যে নামটি বেছে নিই তার ভবিষ্যতে পরিবর্তন না হওয়ার প্রবণতা রয়েছে, সুতরাং সেই ইন্টারফেসের উপর নির্ভরতা প্রভাবিত হবে না। অন্যদিকে একটি কংক্রিট শ্রেণীর নামকরণের প্রবণতা রয়েছে যখন এটি কার্যকর করার পথে গুরুত্বপূর্ণ কিছু পরিবর্তিত হয়, উদাহরণস্বরূপ নামক একটি কংক্রিট শ্রেণি TaxSheetপরিবর্তিত হতে পারে SessionAwareTaxSheetকারণ একটি উল্লেখযোগ্য ওভারহল তৈরি হয়েছিল তবে ইন্টারফেসটি ITaxSheetসম্ভবত এত সহজে নামকরণ করা হবে না।

শেষের সারি:

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

Comments

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

— রবার্ট হার্ভে

Answer 2

একটি বিশেষ সমস্যা যা আমি ডিটিও'র সাথে দেখেছি যা ইন্টারফেস ব্যবহার করে তা হ'ল এটির অনুমতি দেয়:

public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}

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

SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!

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

ডিটিওগুলি ডোমেন মডেল নয়। ডিটিওরা অ্যানিমিক হলে আমাদের উদ্বিগ্ন হওয়া উচিত নয়। রক্তস্বল্প ডোমেন মডেল সম্পর্কে মার্টিন ফাউলারের আলোচনার উদ্ধৃতি দিতে :

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