আমি কি আমার ক্লাসগুলি খুব দানাদার করে দিচ্ছি? একক দায়িত্বের নীতিমালা কীভাবে প্রয়োগ করা উচিত?

Question

আমি প্রচুর কোড লিখি যাতে তিনটি বুনিয়াদি পদক্ষেপ জড়িত।

1. কোথাও থেকে ডেটা পান।
2. তথ্যটি রূপান্তর করুন।
3. কোথাও এই তথ্য রাখুন।

আমি সাধারণত তিন ধরণের ক্লাস ব্যবহার করে শেষ করি - তাদের নিজ নিজ ডিজাইনের ধরণ দ্বারা অনুপ্রাণিত হয়ে।

1. কারখানাগুলি - কিছু সংস্থান থেকে একটি অবজেক্ট তৈরি করা।
2. মধ্যস্থতাকারী - কারখানাটি ব্যবহার করতে, রূপান্তরটি সম্পাদন করতে, তারপরে কমান্ডারটি ব্যবহার করুন।
3. কমান্ডার - সেই ডেটা অন্য কোথাও রাখার জন্য।

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

আমি যখন পরীক্ষার দিকে আসি তখন যেখানে লড়াই করি আমি সেখানে কঠোরভাবে পরীক্ষা করবো। উদাহরণ স্বরূপ;

• কারখানা - ডিস্ক থেকে ফাইল পড়ে reads
• কমান্ডার - ডিস্কে ফাইল লিখে।

আমি অন্যটি ছাড়া একটি পরীক্ষা করতে পারি না। আমি ডিস্ক রিড / লিখতে অতিরিক্ত 'টেস্ট' কোড লিখতে পারি, তবে তারপরে আমি নিজেকে পুনরাবৃত্তি করছি।

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

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

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

Comments

কোনও শ্রেণি একক দায়িত্বের নীতিটি পূরণ করে কিনা তা কীভাবে নির্ধারণ করা যায় তার

— gnat

Looking at .Net, the File class takes a different approach, it combines the responsibilities (of my) factory and commander together. It has functions for Create, Delete, Exists, and Read all in one place.- মনে রাখবেন যে আপনি "করণীয়" দিয়ে "দায়বদ্ধতা" কাটাচ্ছেন। একটি দায়িত্ব আরও একটি "উদ্বেগের ক্ষেত্রের মতো"। ফাইল শ্রেণীর দায়িত্ব ফাইল অপারেশন করছে।

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

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

— মার্টিন মাট

@ রবার্ট হার্ভে যেমন উল্লেখ করেছেন, এসআরপি-র একটি কৃপণ নাম রয়েছে কারণ এটি সত্যিকারের দায়িত্ব সম্পর্কে নয়। এটি "উদ্বেগের একক কৌশল / জটিল ক্ষেত্রটি encapsulating এবং বিমূর্তকরণ সম্পর্কে" যা পরিবর্তিত হতে পারে "। আমার ধারণা, STDACMC অনেক দীর্ঘ ছিল। :-) এটি বলেছিল, আমি মনে করি আপনার তিন ভাগে ভাগ করা যুক্তিসঙ্গত বলে মনে হচ্ছে।

— user949300

Fileসি # থেকে আপনার লাইব্রেরির একটি গুরুত্বপূর্ণ বিষয় হ'ল আমরা সকলেই জানি Fileক্লাসটি কেবল একটি ফ্যাসাদ হতে পারে, সমস্ত ফাইল ক্রিয়াকলাপকে এক জায়গায় - ক্লাসে রেখে দেয় তবে অভ্যন্তরীণভাবে আপনার অনুরূপ পাঠ / লেখার ক্লাস ব্যবহার করতে পারে যা আপনার পক্ষে হবে ফাইল হ্যান্ডলিংয়ের জন্য আরও জটিল যুক্তি রয়েছে। এই জাতীয় শ্রেণি (দ্য File) এখনও এসআরপি মেনে চলবে, কারণ ফাইলসিস্টেমের সাথে প্রকৃতপক্ষে কাজ করার প্রক্রিয়াটি অন্য স্তরের পিছনে বিমূর্ত হবে - সম্ভবত একত্রিত ইন্টারফেসের সাথে। বলছে না এটি কেস, তবে এটি হতে পারে। :)

— অ্যান্ডি

Answer 1

একক দায়িত্বের নীতি অনুসরণ করা হতে পারে যা আপনাকে এখানে পরিচালিত করেছিল তবে যেখানে আপনি রয়েছেন তার আলাদা নাম রয়েছে।

কমান্ড অনুসন্ধানের দায়িত্ব বিভাজন

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

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

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

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

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

আপনি যদি এটি ব্যবহার করেন তবে সতর্কতার এই শব্দটি মনোযোগ দিন:

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

মার্টিন ফ্লাওয়ার: সিকিউআরএস

Comments

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

— জেমস উড

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

— ওয়ালফ্রাট

Answer 2

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

আপনাকে XML ফাইলে অ্যাপ্লিকেশন ডেটা সংরক্ষণ করার অনুমতি দেয়। পড়া বা লেখার সাথে সম্পর্কিত কোডগুলি কী কারণে আপনাকে পরিবর্তন করতে পারে? কিছু সম্ভাবনা:

• অ্যাপ্লিকেশনটিতে নতুন বৈশিষ্ট্য যুক্ত করা হলে অ্যাপ্লিকেশন ডেটা মডেলটি পরিবর্তিত হতে পারে।
• নতুন ধরণের ডেটা - যেমন চিত্রগুলি - মডেলটিতে যুক্ত হতে পারে
• স্টোরেজ ফর্ম্যাটটি অ্যাপ্লিকেশন লজিকের পরিবর্তে পৃথক হতে পারে: আন্তঃব্যবহারযোগ্যতা বা পারফরম্যান্স উদ্বেগের কারণে এক্সএমএল থেকে জেএসএন বা বাইনারি বিন্যাসে বলুন।

এই সমস্ত ক্ষেত্রে, আপনাকে পড়া এবং লেখার উভয় যুক্তিই পরিবর্তন করতে হবে । অন্য কথায়, তারা না পৃথক দায়িত্ব।

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

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

Answer 3

সাধারণত আপনার সঠিক ধারণা আছে।

কোথাও থেকে ডেটা পান। তথ্যটি রূপান্তর করুন। কোথাও এই তথ্য রাখুন।

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

interface Reader[T] {
    def read(): T
}

interface Transformer[T, U] {
    def transform(t: T): U
}

interface Writer[T] {
    def write(t: T): void
}

তারপরে একটি প্রোগ্রাম হিসাবে প্রকাশ করা যেতে পারে:

def program[T, U](reader: Reader[T], 
                  transformer: Transformer[T, U], 
                  writer: Writer[U]): void =
    writer.write(transformer.transform(reader.read()))

এটি ক্লাসগুলির বিস্তারকে বাড়ে

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

আমি যখন পরীক্ষার দিকে আসি তখন যেখানে লড়াই করি আমি সেখানে কঠোরভাবে পরীক্ষা করবো। আমি অন্যটি ছাড়া একটি পরীক্ষা করতে পারি না।

প্রতিটি টুকরা স্বতন্ত্রভাবে পরীক্ষাযোগ্য হতে হবে। উপরের মডেল করা, আপনি কোনও ফাইলকে পড়া / লেখার প্রতিনিধিত্ব করতে পারেন:

class FileReader(fileName: String) implements Reader[String] {
    override read(): String = // read file into string
}

class FileWriter(fileName: String) implements Writer[String] {
    override write(str: String) = // write str to file
}

এই ক্লাসগুলি পরীক্ষা করে তারা ফাইল সিস্টেমে পড়ে এবং সেগুলি পরীক্ষা করে তা পরীক্ষা করতে আপনি সংহতকরণ পরীক্ষা লিখতে পারেন। বাকি যুক্তি রূপান্তর হিসাবে লেখা যেতে পারে। উদাহরণস্বরূপ যদি ফাইলগুলি JSON ফর্ম্যাট হয় তবে আপনি গুলিটি রুপান্তর করতে পারেন String।

class JsonParser implements Transformer[String, Json] {
    override transform(str: String): Json = // parse as json
}

তারপরে আপনি সঠিক জিনিসগুলিতে রূপান্তর করতে পারেন:

class FooParser implements Transformer[Json, Foo] {
    override transform(json: Json): Foo = // ...
}

এগুলির প্রতিটি স্বতন্ত্রভাবে পরীক্ষামূলক। তোমরা হচ্ছ সেই ছাত্রশিবিরের পরীক্ষা এটিও করতে পারেন programউপহাস করে উপরের reader, transformerএবং, writer।

Comments

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

— জেমস উড

@ জামেসওড যা প্রায়শই ইন্টিগ্রেশন পরীক্ষার ক্ষেত্রে হয় case আপনি না আছে কিন্তু পরীক্ষা শ্রেণীর দম্পতি করতে। আপনি ব্যবহার না FileWriterকরে সরাসরি ফাইল সিস্টেম থেকে পড়ে পরীক্ষা করতে পারেন FileReader। আপনার লক্ষ্যগুলি পরীক্ষায় কী তা সত্যই এটি আপনার। আপনি ব্যবহার করেন তাহলে FileReader, পরীক্ষা যদি পারেন ভঙ্গ করবে FileReaderবা FileWriterনষ্ট হয়ে গেছে - যা ডিবাগ করার জন্য আরো সময় লাগতে পারে।

— স্যামুয়েল

এছাড়াও স্ট্যাকওভারফ্লো.com/ প্রশ্নগুলি ১০০/1087৩৩৩১/২ দেখুন, এটি আপনার পরীক্ষাগুলি আরও সুন্দর করতে সহায়তা করতে পারে

— স্যামুয়েল

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

— এরমারসন কার্ডোসো

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

— জেমস উড

Answer 4

আমি শেষ পর্যন্ত শক্তভাবে কাপল পরীক্ষা করব। উদাহরণ স্বরূপ;

• কারখানা - ডিস্ক থেকে ফাইল পড়ে reads
• কমান্ডার - ডিস্কে ফাইল লিখে।

সুতরাং এখানে ফোকাস কি একসাথে তাদের সংমিশ্রণ করা হয় । আপনি কি উভয়ের মধ্যে কোনও বস্তু পাস করেন (যেমন একটি File?) তারপরে এটি সেই ফাইলের সাথে মিলিত হয়, একে অপরের নয়।

আপনি যা বলেছেন তা থেকে আপনি আপনার ক্লাসগুলি আলাদা করেছেন। ফাঁদটি হ'ল আপনি সেগুলি একত্রে পরীক্ষা করছেন কারণ এটি সহজ বা 'বোধগম্য' ।

Commanderডিস্ক থেকে আসতে আপনাকে কেন ইনপুটটির প্রয়োজন ? এটি যা কিছু যত্ন করে সেগুলি নির্দিষ্ট ইনপুট ব্যবহার করে লিখতে হয়, তারপরে আপনি পরীক্ষায় যা আছে তা ব্যবহার করে এটি ফাইলটি সঠিকভাবে লিখেছিল তা যাচাই করতে পারবেন ।

আপনি যে প্রকৃত অংশটির জন্য পরীক্ষা করছেন Factoryসেটি হ'ল 'এটি কি এই ফাইলটি সঠিকভাবে পড়বে এবং সঠিক জিনিসটি আউটপুট দেবে'? সুতরাং পরীক্ষায় পড়ার আগে ফাইলটি মক করুন ।

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

Comments

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

— জেমস উড

Answer 5

কোথাও থেকে ডেটা পান। তথ্যটি রূপান্তর করুন। কোথাও এই তথ্য রাখুন।

এটি একটি সাধারণ পদ্ধতিগত পদ্ধতি, যা ১৯ David২ সালে ডেভিড পার্নাস লিখেছিলেন things আপনি কীভাবে চলছেন সেদিকে মনোনিবেশ করেন । আপনি আপনার সমস্যার দৃ concrete় সমাধানকে একটি উচ্চ-স্তরের প্যাটার্ন হিসাবে গ্রহণ করেন, যা সর্বদা ভুল।

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

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

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

class FinanceTransaction
{
    private $id;
    private $storage;

    public function __construct(UUID $id, DataStorage $storage)
    {
        $this->id = $id;
        $this->storage = $storage;
    }

    public function perform(
        Order $order,
        Customer $customer,
        Merchant $merchant
    )
    {
        if ($order->isExpired()) {
            throw new Exception('Order expired');
        }

        if ($customer->canNotPurchase($order)) {
            throw new Exception('It is not legal to purchase this kind of stuff by this customer');
        }

        $this->storage->save($this->id, $order, $customer, $merchant);
    }
}

(new FinanceTransaction())
    ->perform(
        new Order(
            new Product(
                $_POST['product_id']
            ),
            new Card(
                new CardNumber(
                    $_POST['card_number'],
                    $_POST['cvv'],
                    $_POST['expires_at']
                )
            )
        ),
        new Customer(
            new Name(
                $_POST['customer_name']
            ),
            new Age(
                $_POST['age']
            )
        ),
        new Merchant(
            new MerchantId($_POST['merchant_id'])
        )
    )
;

ফলস্বরূপ বেশ কয়েকটি সমন্বিত শ্রেণি রয়েছে যা কিছু কার্যকারিতা উপস্থাপন করে। নোট করুন যে বৈধতা সাধারণত মান-অবজেক্টে যায় - কমপক্ষে ডিডিডি পদ্ধতির ক্ষেত্রে।

Answer 6

আমি যখন পরীক্ষার দিকে আসি তখন যেখানে লড়াই করি আমি সেখানে কঠোরভাবে পরীক্ষা করবো। উদাহরণ স্বরূপ;

• কারখানা - ডিস্ক থেকে ফাইল পড়ে reads
• কমান্ডার - ডিস্কে ফাইল লিখে।

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

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

Comments

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

— জেমস উড

Answer 7

আমার মতে এটি মনে হচ্ছে আপনি সঠিক পথে যাত্রা শুরু করেছেন তবে আপনি এটিকে এতদূর নেননি। আমি মনে করি কার্যকারিতাটি বিভিন্ন শ্রেণিতে বিভক্ত করা যা একটি কাজ করে এবং এটি ভালভাবে করে তা সঠিক।

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

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

Comments

YAGNI এমন একটি জিনিস যা আপনার সম্পর্কে ভাবা উচিত।

— হোসনেম