একই পদ্ধতিতে দুটি বার অবজেক্ট পাস বা সংযুক্ত ইন্টারফেসের সাথে একত্রীকরণ?

Question

আমার একটি পদ্ধতি রয়েছে যা একটি ডিজিটাল বোর্ডের সাথে কথা বলার পরে একটি ডেটা ফাইল তৈরি করে:

CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer)

এখানে boardFileAccessএবং boardMeasurerকোনও Boardবস্তুর একই উদাহরণ যা উভয় IFileAccessএবং কার্যকর করে IMeasurer। IMeasurerএক্ষেত্রে একক পদ্ধতির জন্য ব্যবহৃত হয় যা সাধারণ পরিমাপ করতে সক্রিয় বোর্ডে একটি পিন সেট করে। এই পরিমাপ থেকে প্রাপ্ত ডেটা ব্যবহার করে বোর্ডে স্থানীয়ভাবে সংরক্ষণ করা হয় IFileAccess। Boardএকটি পৃথক প্রকল্পে অবস্থিত।

আমি এই সিদ্ধান্তে পৌঁছেছি যে CreateDataFileএকটি তাত্ক্ষণিক পরিমাপ করে একটি কাজ করছে এবং তারপরে ডেটা সংরক্ষণ করে এবং একই কোড দুটি ব্যবহার করে অন্য কেউ এই কোডটি ব্যবহার করে তারপরে একটি পরিমাপ করে একটি ফাইলকে লিখতে হবে তার জন্য আরও স্বজ্ঞাত পৃথক পদ্ধতি কল হিসাবে।

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

Comments

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

— মার্টিন মাট

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

— ব্যবহারকারী 253751

যদিও এখানে আরও একটি প্রশ্ন এখানে রয়েছে - প্রথম স্থানে ডেটা ফাইল অ্যাক্সেস এবং পরিমাপের বিষয়গুলি কেন একই?

— ব্যবহারকারী 253751

Answer 1

না, এটা ঠিক আছে। এটির অর্থ হ'ল এপিআই আপনার বর্তমান অ্যাপ্লিকেশনটির সাথে শ্রদ্ধার সাথে অতিরিক্ত ইঞ্জিনিয়ারড ।

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

Answer 2

@ কিলিয়ানফথের উত্তরের সাথে সম্মত হন যে এটি পুরোপুরি ঠিক আছে।

তবুও, আপনি চাইলে আপনি এমন একটি পদ্ধতি তৈরি করতে পারেন যা একটি একক অবজেক্ট নেয় যা উভয় ইন্টারফেস প্রয়োগ করে:

public object CreateDataFile<T_BoardInterface>(
             T_BoardInterface boardInterface
    )
    where T_BoardInterface : IFileAccess, IMeasurer
{
    return CreateDataFile(
                boardInterface
            ,   boardInterface
        );
}

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

Answer 3

আমি এই সিদ্ধান্তে পৌঁছেছি যে CreateDataFileএকটি তাত্ক্ষণিক পরিমাপ করে একটি কাজ করছে এবং তারপরে ডেটা সংরক্ষণ করে এবং একই কোড দুটি ব্যবহার করে অন্য কেউ এই কোডটি ব্যবহার করে তারপরে একটি পরিমাপ করে একটি ফাইলকে লিখতে হবে তার জন্য আরও স্বজ্ঞাত পৃথক পদ্ধতি কল হিসাবে।

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

• একটি পরিমাপ আনুন
• ফলাফলটি কোথাও কোনও ফাইলে সংরক্ষণ করুন

এগুলি দুটি পৃথক আই / ও অপারেশন। উল্লেখযোগ্যভাবে, প্রথমটি কোনওভাবেই ফাইল সিস্টেমকে রূপান্তরিত করে না।

আসলে, আমাদের লক্ষ করা উচিত যে একটি অন্তর্নিহিত মাঝারি পদক্ষেপ রয়েছে:

• একটি পরিমাপ আনুন
• পরিমাপটিকে একটি পরিচিত বিন্যাসে সিরিয়াল করুন
• সিরিয়ালযুক্ত পরিমাপ একটি ফাইলে সংরক্ষণ করুন

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

উদাহরণ হিসাবে, আপনি সম্ভবত অপারেশনগুলি পৃথক করতে পারেন।

IMeasurer পরিমাপ আনার একটি উপায় আছে:

public interface IMeasurer
{
    IMeasurement Measure(int someInput);
}

আপনার পরিমাপের ধরণটি সহজ stringবা সাধারণ কোনও কিছু হতে পারে decimal। আমি এটির জন্য আপনাকে একটি ইন্টারফেস বা ক্লাসের প্রয়োজন বলে জোর দিচ্ছি না, তবে এটি উদাহরণটিকে আরও সাধারণ করে তুলেছে।

IFileAccess ফাইল সংরক্ষণের জন্য কিছু পদ্ধতি রয়েছে:

interface IFileAccess
{
    void SaveFile(string fileContents);
}

তারপরে আপনার একটি পরিমাপকে সিরিয়ালাইজ করার একটি উপায় প্রয়োজন। শ্রেণি বা ইন্টারফেসে কোনও পরিমাপের প্রতিনিধিত্ব করে বা ইউটিলিটি পদ্ধতিতে এটি তৈরি করুন:

interface IMeasurement
{
    // As part of the type
    string Serialize();
}

// Utility method. Makes more sense if the measurement is not a custom type.
public static string SerializeMeasurement(IMeasurement m)
{
    return ...
}

আপনার এই সিরিয়ালাইজেশন অপারেশনটি আলাদা হয়ে গেছে কিনা তা এখনও পরিষ্কার নয়।

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

আপনার প্রতিটি ক্রিয়াকলাপের জন্য পৃথক বাস্তবায়ন CreateDataFileহয়ে গেলে , আপনার পদ্ধতিটি কেবল একটি সংক্ষিপ্তরূপে পরিণত হয়

fileAccess.SaveFile(SerializeMeasurement(measurer.Measure()));

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

---

সমস্ত প্রাসঙ্গিক অংশগুলি একবার প্রমাণিত হয়ে গেলে এবং আমরা স্বীকার করে নিয়েছি যে পদ্ধতিটি কেবল একটি সুবিধার জন্য, আমাদের আপনার প্রশ্নটি পুনরায় মন্তব্য করা দরকার:

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

যদি পুরো পয়েন্টটি একই বোর্ড থেকে মাপার এবং লেখার জন্য সাধারণ ব্যবহারের ক্ষেত্রে কিছুটা সুবিধাজনক করে তোলা হয় তবে Boardক্লাসে এটি সরাসরি উপলব্ধ করার জন্য এটি সঠিক ধারণা দেয় :

public class Board : IMeasurer, IFileAccess
{
    // Interface methods...

    /// <summary>
    /// Convenience method to measure and immediate record measurement in
    /// default location.
    /// </summary>
    public void ReadAndSaveMeasurement()
    {
        this.SaveFile(SerializeMeasurement(this.Measure()));
    }
}

এটি যদি সুবিধার উন্নতি না করে তবে আমি পদ্ধতিটি মোটেই বিরক্ত করব না।

---

এটি একটি সুবিধার পদ্ধতি হ'ল অন্য একটি প্রশ্ন উত্থাপন।

করা উচিত IFileAccessইন্টারফেস পরিমাপ প্রকার এবং কিভাবে এটা ধারাবাহিকভাবে সম্পর্কে জানেন? যদি তা হয় তবে আপনি এতে একটি পদ্ধতি যুক্ত করতে পারেন IFileAccess:

interface IFileAccess
{
    void SaveFile(string fileContents);
    void SaveMeasurement(IMeasurement m);
}

কলকারীরা এখন এটি করেন:

fileAccess.SaveFile(measurer.Measure());

যা আপনার সুবিধার পদ্ধতির তুলনায় ঠিক যেমন সংক্ষিপ্ত এবং সম্ভবত আরও স্পষ্ট প্রশ্ন হিসাবে ধারণা করা হয়েছে।

Answer 4

গ্রাহককে যখন একক আইটেম যথেষ্ট হয় তখন একজোড়া আইটেম নিয়ে কাজ করা উচিত নয়। আপনার ক্ষেত্রে, তারা প্রায় আহবান না করা অবধি না করে CreateDataFile।

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

তবে, আরেকটি পদ্ধতির যা বাস্তবায়নের প্রতি কম বাধা দিচ্ছে তা হ'ল এটি IFileAccessএকটি IMeasurerরচনার সাথে যুক্ত , যাতে তাদের একটির সাথে অন্যটির আবদ্ধ এবং রেফারেন্স থাকে। (এটি কিছুটা তাদের বিমূর্ততা বাড়ায় যেহেতু এটি এখন জুটিটিকেও উপস্থাপন করে)) তারপরে CreateDataFileকেবলমাত্র একটি উল্লেখ উল্লেখ করতে, বলতে IFileAccessএবং প্রয়োজনের সাথে অন্যটি পেতে পারে। একটি অবজেক্ট হিসেবে আপনার বর্তমান বাস্তবায়ন যে কার্যকরী দুটি ইন্টারফেস would কেবল return this;রচনা রেফারেন্সের জন্য, এখানে জন্য সংগ্রহকারী IMeasurerমধ্যে IFileAccess।

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

---

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

Answer 5

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

তবে, আমরা যদি ধরে নিই যে এটি কোনও ভুল নয়, তবে বড় সমস্যা হ'ল এই ক্ষেত্রে ইন্টারফেসটি ক্লায়েন্ট দ্বারা সংজ্ঞায়িত করা উচিত CreateDataFile।

ইন্টারফেস বিচ্ছিন্নতার নীতি বলে যে, ক্লায়েন্ট এটা কি দরকার আর একটি ইন্টারফেস আরো উপর নির্ভর করে থাকা উচিত নয়। এই অন্য উত্তরটি থেকে বাক্যাংশটি ধার করা, এটি "পারা ক্লায়েন্টের প্রয়োজনীয়তার দ্বারা একটি ইন্টারফেস দ্বারা সংজ্ঞায়িত করা" হিসাবে রূপান্তর করা যেতে পারে।

এখন, এই ক্লায়েন্ট-নির্দিষ্ট ইন্টারফেসটি ব্যবহার করে IFileAccessএবং IMeasurerঅন্যান্য উত্তরগুলির পরামর্শ অনুসারে এটি তৈরি করা সম্ভব , তবে শেষ পর্যন্ত, এই ক্লায়েন্টটির এটির জন্য একটি ইন্টারফেস দরজি দ্বারা তৈরি করা উচিত।

Comments

@ ডাউনভোটার - এটি সম্পর্কে কী ভুল বা উন্নত করা যায়?

— এক্সট্রোস