কিভাবে বৃহত্তর, শক্তভাবে সংযুক্ত ক্লাস বিভক্ত করা যায়?

Question

আমার কাছে কোডের (এবং বর্ধমান) 2 কে লাইনেরও বেশি কিছু বিশাল ক্লাস রয়েছে যা আমি যদি সম্ভব হয় তবে রিফ্যাক্টর করতে চাই, আরও কিছু হালকা এবং পরিষ্কার নকশা তৈরি করতে চাই।

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

আমি খুব দৃ concrete় উদাহরণ দেব: আমার কাছে একটি ক্লাস রয়েছে যা Serverআগত বার্তাগুলি পরিচালনা করে। মনে হচ্ছে পদ্ধতি আছে joinChatroom, searchUsers, sendPrivateMessage, ইত্যাদি এই পদ্ধতি সকল নিপূণভাবে মানচিত্র যেমন users, chatrooms, servers, ...

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

আমার একটি ক্লাস চ্যাটরুম তৈরি করা দরকার, তবে অন্যান্য সামগ্রীর প্রতিটি একটি রেফারেন্স সহ। অন্যান্য শ্রেণীর সমস্ত বিষয়গুলির একটি রেফারেন্স সহ আবার একটি শ্রেণির ব্যবহারকারী

আমার মনে হচ্ছে আমি কিছু ভুল করছি।

Comments

আপনি যদি ব্যবহারকারী এবং চ্যাটরুমের মতো ক্লাস তৈরি করেন তবে এই ক্লাসগুলির কেবলমাত্র সাধারণ ডেটা কাঠামোর রেফারেন্সের প্রয়োজন হবে বা তারা একে অপরকে রেফারেন্স করবে?

এখানে বেশ কয়েকটি সন্তোষজনক উত্তর রয়েছে, আপনার একটি বেছে নেওয়া উচিত।

— jeremyjjbrown

@ জেরেমিজজব্রাউন প্রশ্নটি সরানো হয়েছে এবং আমি এটি হারিয়ে ফেলেছি। একটি উত্তর বাছাই, thx।

— ম্যাথু

Answer 1

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

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

উদাহরণ স্বরূপ:

public class User {
  private String name;
  ...

  public void sendMessage(String message) {
    ...
  }
}

public class Chatroom {
  // users in this chatroom
  private Collection<User> users;

  public void add(User user) {
    users.add(user);
  }

  public void sendMessage(String msg) {
    for (User user : users)
      user.sendMessage(msg);
  }
}

public class Server {
  // all users on the server
  private Collection<User> users;

  // all chatrooms on the server
  private Collection<Chatroom> chatrooms;

  /* methods to handle incoming messages */
}

বার্তাগুলি পরিচালনা করতে কয়েকটি নির্দিষ্ট পদ্ধতিতে কল করা এখন সহজ:

চ্যাটরুমে যোগ দিতে চান?

chatroom.add(user);

একটি ব্যক্তিগত বার্তা পাঠাতে চান?

user.sendMessage(msg);

একটি সর্বজনীন বার্তা পাঠাতে চান?

chatroom.sendMessage(msg);

Answer 2

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

Answer 3

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

আপনি ক্লাস ডিজাইনে খুশি না হওয়া পর্যন্ত আপনি প্রক্রিয়াটি পুনরাবৃত্তি করতে পারেন।

মার্টিন ফওলারের বইটি সত্যিই ভাল পঠিত তাই আমি এটিও সুপারিশ করবো কারণ আপনি এই স্থির কৌশলটি ব্যবহার করতে পারবেন না এমন সময় রয়েছে।

Comments

এই মার্টিন জালিয়া এর বই martinfowler.com/books/refactoring.html

— Arul

Answer 4

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

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

Answer 5

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

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

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

উভয় ক্ষেত্রেই, নমনীয়তার জন্য কংক্রিট ক্লাস নয়, ইন্টারফেসের দিকে কোড দেওয়ার বিষয়ে নিশ্চিত হন।

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

সুতরাং, সংক্ষেপে:

1. যেমন ক্যাসাব্ল্যাঙ্কা লিখেছেন: পৃথক এবং চ্যাপ্টারের আড্ডা, ব্যবহারকারী ইত্যাদি etc.
2. সাধারণ কার্যকারিতা পৃথক করুন
3. ডেটা বা উপাত্তের সামগ্রিক উদাহরণগুলির জন্য আরও জটিল কার্যকারিতা থেকে তথ্য-উপস্থাপনে (পাশাপাশি অ্যাক্সেস এবং মিউটেশন) পৃথক কার্যকারিতা পৃথক করার বিষয়টি বিবেচনা করুন (উদাহরণস্বরূপ, searchUsersসংগ্রহশ্রেণীতে বা কোনও সংগ্রহশালা / পরিচয়-মানচিত্রের মতো কিছু) )

Answer 6

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

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

এটি একই তথ্য নয়, এমনকি যদি ডেটার ধরণগুলি অভিন্ন হয়।
একটি ভাল ডিজাইনের অনেকগুলি সুবিধা রয়েছে।

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

Answer 7

মানচিত্র অ্যাক্সেস করার প্রয়োজন মেগা-বর্গ সমর্থন করে না। আপনাকে বেশ কয়েকটি ক্লাসে যুক্তি আলাদা করতে হবে এবং প্রতিটি শ্রেণিতে একটি getMap পদ্ধতি থাকতে হবে যাতে অন্যান্য ক্লাসগুলি মানচিত্র অ্যাক্সেস করতে পারে।

Answer 8

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

Answer 9

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