'ইউটিলিটি ফাংশন' ক্লাসে টেম্পিং করা হচ্ছে

Question

আমাদের জাভা কোডবেসে আমি নিম্নলিখিত প্যাটার্নটি দেখছি:

/**
 This is a stateless utility class
 that groups useful foo-related operations, often with side effects.
*/
public class FooUtil {
  public int foo(...) {...}
  public void bar(...) {...}
}

/**
 This class does applied foo-related things.
*/
class FooSomething {
  int DoBusinessWithFoo(FooUtil fooUtil, ...) {
    if (fooUtil.foo(...)) fooUtil.bar(...);
  }
}

যা আমাকে বিরক্ত করে তা হ'ল আমাকে FooUtilসর্বত্র একটি উদাহরণ পাস করতে হবে কারণ পরীক্ষার কারণ।

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

আমি মনে করি যে আমার সেরা বেট ইনজেকশনটি ব্যবহার করা (এবং আমি করি) তবে এটির নিজস্ব ঝামেলা যুক্ত হয়েছে। এছাড়াও, বেশ কয়েকটি ব্যবহারের উদাহরণ পাস করা পদ্ধতি প্যারামিটার তালিকার আকারকে সঞ্চার করে।

এটিকে আরও ভালভাবে পরিচালনা করার উপায় আছে যা আমি দেখছি না?

আপডেট: যেহেতু ইউটিলিটি ক্লাসগুলি রাষ্ট্রহীন, আমি সম্ভবত পরীক্ষার জন্য ক্লাসের অন্তর্নিহিত স্ট্যাটিক ক্ষেত্রটি আপডেট করার ক্ষমতা বজায় রেখে একটি স্থিতিশীল সিঙ্গেলটন INSTANCEসদস্য বা একটি স্ট্যাটিক getInstance()পদ্ধতি যুক্ত করতে পারি। খুব পরিষ্কার-পরিচ্ছন্ন বলে মনে হচ্ছে না।

Comments

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

— তেলস্তিন

এই পদ্ধতিগুলি শ্রেণীর সদস্য নয় কেন যার ডেটা তারা ব্যবহার করে?

— জুলাই

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

— tgkprog

জুলস মন্তব্য করার জন্য +1। ইউটিলি ক্লাসগুলি একটি কোড গন্ধ। শব্দার্থবিজ্ঞানের উপর নির্ভর করে আরও ভাল সমাধান হওয়া উচিত। সম্ভবত FooUtilপদ্ধতিগুলি beোকানো উচিত FooSomething, সম্ভবত এর বৈশিষ্ট্যগুলি FooSomethingপরিবর্তন / প্রসারিত করা উচিত যাতে FooUtilপদ্ধতিগুলির আর প্রয়োজন হয় না। FooSomethingএই প্রশ্নগুলির একটি ভাল উত্তর প্রদান করতে আমাদের কী কী সহায়তা করতে হবে তার আরও দৃ concrete় উদাহরণ দিন ।

— ভ্যালেনটারি

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

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

Answer 1

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

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

যখন আপনি সংগ্রহ করছেন আপনি ঘুরছেন তখন অবশ্যই এমন কোড থাকতে হবে যা সেই সংগ্রহের একটি অংশ হতে চায় এবং এটি আপনার সিস্টেমে ছড়িয়ে ছিটিয়ে শেষ পর্যন্ত ইউটিলিটি ক্লাসে সংগ্রহ করা হয়।

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

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

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

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

Comments

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

— গ্রিনআসজেড

"কম্পিউটার বিজ্ঞানের সমস্ত সমস্যা ইন্ডিয়ারেশনের অন্য স্তরের দ্বারা সমাধান করা যেতে পারে ... ... অনেক বেশি স্তর পরিবর্তনের সমস্যা ব্যতীত।

— উত্সাহক

@ ডেডুপ্লিকেটর ৪০ বছরের প্রোগ্রামিংয়ে আমি খুব কমই (কখনই?) এমন ঘটনাটি দেখেছি যেখানে আমাকে অনেকগুলি ইন্ডিয়ারেশন দ্বারা অবরুদ্ধ করা হয়েছিল (ইন্টারফেসের পরিবর্তে বাস্তবায়নে ঝাঁপিয়ে পড়ার জন্য আমার আইডিইর সাথে মাঝে মাঝে লড়াই বাদ দিয়ে) তবে আমি ' স্পষ্টত প্রয়োজনীয় ক্লাস তৈরির পরিবর্তে লোকেরা ভয়ঙ্কর কোড লিখেছিল এমন ক্ষেত্রে প্রায়ই দেখা যায় (খুব বার বার) seen যদিও আমি বিশ্বাস করি যে খুব বেশি ইন্ডিरेশন কিছু লোককে দংশিত করতে পারে, তবে আমি যথাযথ ওও নীতিগুলির পক্ষে ত্রুটি করতাম যেমন প্রতিটি শ্রেণি একটি কাজ ভালভাবে করা, যথাযথ রক্ষণাবেক্ষণ ইত্যাদি

— বিল কে

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

— হস্তান্তরকারী

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

— বিল কে

Answer 2

আপনি সরবরাহকারী প্যাটার্নটি ব্যবহার করতে পারেন এবং FooSomethingকোনও FooUtilProviderঅবজেক্টের মাধ্যমে আপনার ইনজেকশন করতে পারেন (কোনও নির্মাণে থাকতে পারেন; কেবল একবার)।

FooUtilProviderশুধুমাত্র এক পদ্ধতি প্রয়োগ করা হবে: FooUtils get();। ক্লাস তারপরে যা যা FooUtilsউদাহরণ দেয় তা ব্যবহার করবে ।

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