ক্লাস এবং ইন্টারফেস ফাইলগুলি কীভাবে সজ্জিত করা যায়?

17

ঠিক আছে .. সমস্ত আলোচনার পরেও আমি আমার প্রশ্নটি সামান্য পরিবর্তন করছি যার সাথে আমি কংক্রিটের উদাহরণটি প্রতিস্থাপন করছি যা আমি আচরণ করছি।

আমার দুটি ক্লাস রয়েছে ModelOneএবং ModelTwoএই ক্লাসগুলি একই ধরণের কার্যকারিতা সম্পাদন করে তবে একে অপরের সাথে সম্পর্কিত নয়। তবে আমি একটা তৃতীয় ক্লাস আছে CommonFuncযে কিছু পাবলিক কার্যকারিতা উভয় বাস্তবায়িত হয় রয়েছে ModelOneএবং ModelTwoপ্রতি হিসেবে উপাদান হয়েছে DRY। দুটি মডেলের মধ্যে তাত্ক্ষণিক হয়ModelMain ক্লাসের (যা নিজেই একটি উচ্চ স্তরের ইত্যাদিতে ইনস্ট্যান্ট হয় - তবে আমি এই স্তরে থামছি)।

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

সুতরাং কোড অনুসারে আমি ² দিয়ে শেষ করব :

public interface ICommonFunc 
{ 
}

public interface IModelOne 
{ 
   ICommonFunc Common { get; } 
   .. 
}

public interface IModelTwo
{ 
   ICommonFunc Common { get; } 
   .. 
}

public interface IModelMain 
{ 
  IModelOne One { get; } 
  IModelTwo Two { get; } 
  ..
}

public class CommonFunc : ICommonFunc { .. }

public class ModelOne : IModelOne { .. }

public class ModelTwo : IModelTwo { .. }

public class ModelMain : IModelMain { .. }

প্রশ্নটি আমার সমাধানটি কীভাবে সংগঠিত করা যায় তা নিয়ে। আমার কি ক্লাস এবং ইন্টারফেস একসাথে রাখা উচিত? বা আমার ক্লাস এবং ইন্টারফেস একসাথে রাখা উচিত? উদাহরণ:

বিকল্প 1 - শ্রেণি নাম দ্বারা সংগঠিত

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Common
          |   |
          |   |-CommonFunc.cs
          |   |-ICommonFunc.cs
          |
          |-Main
          |   |
          |   |-IModelMain.cs
          |   |-ModelMain.cs
          |
          |-One
          |   |
          |   |-IModelOne.cs
          |   |-ModelOne.cs
          |
          |-Two
              |
              |-IModelTwo.cs
              |-ModelTwo.cs
              |

বিকল্প 2 - কার্যকারিতা দ্বারা সংগঠিত (বেশিরভাগ)

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Common
          |   |
          |   |-CommonFunc.cs
          |   |-ICommonFunc.cs
          |
          |-IModelMain.cs
          |-IModelOne.cs
          |-IModelTwo.cs
          |-ModelMain.cs
          |-ModelOne.cs
          |-ModelTwo.cs
          |

বিকল্প 3 - ইন্টারফেস এবং বাস্তবায়ন পৃথকীকরণ

MySolution
  |
  |-MyProject
      |
      |-Interfaces
      |   |
      |   |-Models
      |   |   |
      |       |-Common
      |       |   |-ICommonFunc.cs
      |       |
      |       |-IModelMain.cs
      |       |-IModelOne.cs
      |       |-IModelTwo.cs
      |
      |-Classes
          | 
          |-Models
          |   |
              |-Common
              |   |-CommonFunc.cs
              |
              |-ModelMain.cs
              |-ModelOne.cs
              |-ModelTwo.cs
              |

বিকল্প 4 - কার্যকারিতা উদাহরণ আরও গ্রহণ করা

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Components
          |   |
          |   |-Common
          |   |   |
          |   |   |-CommonFunc.cs
          |   |   |-ICommonFunc.cs
          |   |   
          |   |-IModelOne.cs
          |   |-IModelTwo.cs
          |   |-ModelOne.cs
          |   |-ModelTwo.cs
          |
          |-IModelMain.cs
          |-ModelMain.cs
          |

পথটিতে শ্রেণিকামের কারণে আমি পছন্দ 1 অপছন্দ পছন্দ করি। তবে আমার আইওসি পছন্দ / ব্যবহারের কারণে আমি 1: 1 অনুপাতের দিকে ঝুঁকছি (এবং এটি বিতর্কযোগ্য হতে পারে) ফাইলগুলির মধ্যে সম্পর্ক দেখার ক্ষেত্রে এর সুবিধা রয়েছে।

বিকল্প 2 আমার কাছে আবেদন জানায় তবে এখন আমি ModelMainসাব এবং মডেলগুলির মধ্যে জলাবদ্ধতা ।

বিকল্প 3 বাস্তবায়ন থেকে ইন্টারফেস সংজ্ঞা পৃথক করতে কাজ করে, তবে এখন আমার কাছে পথের নামগুলিতে এই কৃত্রিম বিরতি রয়েছে।

বিকল্প 4। আমি বিকল্প 2 নিয়েছি এবং প্যারেন্ট মডেল থেকে উপাদানগুলি পৃথক করার জন্য এটি টুইট করেছি।

একে অপরের চেয়ে বেশি পছন্দ করার কোনও যুক্তি আছে কি? বা অন্য কোনও সম্ভাব্য বিন্যাস যা আমি মিস করেছি?

^{1. ফ্রাঙ্ক একটি মন্তব্য করেছে যে 1: 1 অনুপাত থাকা .h এবং .cpp ফাইলগুলির সি ++ দিন ফিরে আসে। আমি জানি সে কোথা থেকে আসছে। আমার Unক্যের বোঝাপড়া আমাকে এই কোণায় ফেলেছে বলে মনে হয় তবে আপনি কীভাবে এর থেকে বেরিয়ে আসবেন তা সম্পর্কেও আমি নিশ্চিত নই তবে আপনি যদি এই কথারও অনুসরণ করেন Program to an interface তবে অন্য এক দিনের জন্য আলোচনা চালিয়ে যান।}

^{২. আমি প্রতিটি অবজেক্ট কনস্ট্রাক্টরের বিশদ রেখে দিয়েছি। এটি যেখানে IoC ধারক প্রয়োজন হিসাবে বস্তু ইনজেক্ট করে।}

c# interfaces class code-organization

— পিটার এম
সূত্র

1

বিতৃষ্ণা। এটি গন্ধযুক্ত যে আপনার 1: 1 ইন্টারফেস / শ্রেণি অনুপাত রয়েছে। আপনি কোন আইওসি ধারক ব্যবহার করছেন? নিনজেক এমন মেকানিজম সরবরাহ করে যাগুলির জন্য 1: 1 অনুপাতের প্রয়োজন হয় না।

— রাবারডাক

1

@ রাবারডাক এফডাব্লুআইডাব্লু আমি ityক্য ব্যবহার করছি। আমি এতে বিশেষজ্ঞ হওয়ার দাবি করি না, তবে আমার ক্লাসগুলি যদি একক দায়িত্বের সাথে ভালভাবে ডিজাইন করা হয় তবে আমি কীভাবে প্রায় 1: 1 অনুপাতের সাথে শেষ করব না ?

— পিটার এম

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

— রাবারডাক

1

ঠিক আছে, যদি বেসটি বিমূর্ত হয় তবে তার interfaceজন্য এটির কোনও কারণ নেই । একটি interfaceসত্যই সমস্ত ভার্চুয়াল সদস্যের সাথে একটি বিমূর্ত শ্রেণি।

— রাবারডাক

1

রাবারডাক সঠিক। অতিমাত্রায় ইন্টারফেস কেবল বিরক্তিকর।

— ফ্রাঙ্ক হিলিমান

4

যেহেতু একটি ইন্টারফেসটি বেস ক্লাসের মতো বিমূর্তভাবে অনুরূপ, আপনি বেস ক্লাসের জন্য একই যুক্তি ব্যবহার করুন। একটি ইন্টারফেস বাস্তবায়নকারী ক্লাসগুলি ইন্টারফেসের সাথে ঘনিষ্ঠভাবে সম্পর্কিত।

আমি সন্দেহ করি আপনি "বেস ক্লাস" নামে একটি ডিরেক্টরি পছন্দ করবেন; বেশিরভাগ বিকাশকারী এটি চাইবেন না, বা "ইন্টারফেস" নামে পরিচিত কোনও ডিরেক্টরিও চাইবেন না। সি # তে ডিরেক্টরিগুলি ডিফল্টরূপে নেমস্পেসও হয়, এটি দ্বিগুণ বিভ্রান্ত করে তোলে।

সর্বোত্তম পন্থা হ'ল আপনি যদি কিছু আলাদা লাইব্রেরিতে স্থাপন করতে চান এবং ক্লাস / ইন্টারফেসগুলি কীভাবে ভেঙে ফেলবেন সে সম্পর্কে ভাবনা এবং একইভাবে নেমস্পেস / ডিরেক্টরি পরিচালনা করতে হবে organize । নেট ফ্রেমওয়ার্ক ডিজাইনের গাইডলাইনগুলিতে নেমস্পেসের পরামর্শ রয়েছে যা সহায়ক হতে পারে।

— ফ্র্যাঙ্ক হিলেম্যান
সূত্র

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

— পিটার এম

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

— ফ্রাঙ্ক হিলিমান

আমি ভিএস ব্যবহার করছি এবং হ্যাঁ আমি ব্যথা জানি। এটি ভিজ্যুয়াল সোর্স নিরাপদ ফাইলের বিন্যাসের স্মৃতি ফিরিয়ে আনে।

— পিটার এম

1

@ পিটারএম ক্লাস রেশিও 1: 1 ইন্টারফেস সম্পর্কিত। কিছু সরঞ্জামের জন্য এটি প্রয়োজন। আমি এটিকে সরঞ্জামটির একটি ত্রুটি হিসাবে দেখছি - .নেটের এ জাতীয় কোনও সরঞ্জামে এ জাতীয় বিধিনিষেধের প্রয়োজন নেই পর্যাপ্ত প্রতিফলন ক্ষমতা রয়েছে।

— ফ্র্যাঙ্ক হিলিমান

1

আমি অবশ্যই জটিল প্রকল্পগুলিতে আরও কয়েকটি ফোল্ডার / নেমস্পেস সহ দ্বিতীয় পন্থাটি গ্রহণ করি। এর অর্থ হ'ল আমি কংক্রিটের প্রয়োগগুলি থেকে ইন্টারফেসগুলি ডি-কাপল করব।

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

— বার্নহার্ড হিলার
সূত্র

আমি আমার কোড উদাহরণটি সংশোধন করেছি এবং আরও কিছু বিকল্প যুক্ত করেছি

— পিটার এম

1

যে কোনও ডিজাইনের প্রশ্নের সাথে সর্বদা, প্রথমে আপনার ব্যবহারকারীরা কে তা নির্ধারণ করা হবে। তারা কীভাবে আপনার সংগঠনটি ব্যবহার করবে?

তারা কি কোডার যারা আপনার ক্লাস ব্যবহার করবে? তারপরে কোড থেকে ইন্টারফেসগুলি আলাদা করা ভাল হতে পারে।

তারা কি আপনার কোড রক্ষণাবেক্ষণকারী? তারপরে ইন্টারফেস এবং ক্লাস একসাথে রাখুন সেরা হতে পারে।

বসে কিছু ব্যবহারের কেস তৈরি করুন। তারপরে সেরা সংস্থাটি আপনার সামনে উপস্থিত হতে পারে।

— shawnhcorey
সূত্র

-2

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

— লরিসা সাভছেকু
সূত্র