সলিড বনাম স্থির পদ্ধতি

Question

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

(ক)

public class Product {
  ...
  public Collection<Review> getReviews() {...}
}

(বি)

public class Review {
  ...
  static public Collection<Review> forProduct( Product product ) {...}
}

কোডটি দেখে, আমি (এ) বেছে নেব: এটি অচল নয় এবং এর জন্য প্যারামিটারের দরকার নেই। তবে, আমি বুঝতে পারি যে (এ) একক দায়িত্বের নীতি (এসআরপি) এবং ওপেন-ক্লোজড নীতি (ওসিপি) লঙ্ঘন করেছে যেখানে (বি) তা করে না:

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

• (ওসিপি) এই বৈশিষ্ট্যটি দিয়ে প্রসারিত করতে আমাকে পণ্য শ্রেণি পরিবর্তন করতে হবে। আমি মনে করি এটি নীতিটির 'পরিবর্তনের জন্য বন্ধ' অংশটি লঙ্ঘন করে। পর্যালোচনাগুলি প্রয়োগের জন্য গ্রাহকের অনুরোধ পাওয়ার আগে, আমি পণ্যটিকে সমাপ্ত হিসাবে বিবেচনা করেছি এবং এটি "বন্ধ" করেছি।

আরও গুরুত্বপূর্ণ কী: সলিড নীতি অনুসরণ করে, বা একটি সহজ ইন্টারফেস আছে?

নাকি আমি এখানে পুরোপুরি কিছু ভুল করছি?

ফলাফল

বাহ, আপনার দুর্দান্ত উত্তরগুলির জন্য সমস্ত ধন্যবাদ! সরকারী উত্তর হিসাবে এটি চয়ন করা কঠিন।

আমি উত্তরগুলি থেকে মূল যুক্তিগুলি সংক্ষেপে বলি:

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

আমার কলেজগুলিতে কাজের অতিরিক্ত কয়েকটি জিনিস অবদান রেখেছিল:

• প্রো (বি): আমাদের ওআরএম কাঠামোটি স্বয়ংক্রিয়ভাবে (বি) এর জন্য কোড তৈরি করতে পারে।
• প্রো (এ): আমাদের ওআরএম কাঠামোর প্রযুক্তিগত কারণে, অনুসন্ধানকারী যেখান থেকে যায় সেখান থেকে কিছু ক্ষেত্রে স্বতন্ত্রভাবে "বদ্ধ" সত্তা পরিবর্তন করা প্রয়োজন। সুতরাং আমি সর্বদা যাইহোক, সলডকে আটকে রাখতে সক্ষম হব না।
• বিপরীতে (সি): থেকে অনেক কলহ ;-)

উপসংহার

আমি আমার বর্তমান প্রকল্পের জন্য প্রতিনিধিদের সাথে (এ) + (বি) উভয়ই ব্যবহার করছি। পরিষেবামুখী পরিবেশে তবে আমি (সি) সাথে যাব।

Comments

যতক্ষণ না এটি স্ট্যাটিক পরিবর্তনশীল না হয় সবকিছু দুর্দান্ত। স্থিতিশীল পদ্ধতিগুলি পরীক্ষার জন্য একটি সহজ এবং সন্ধানের জন্য সহজ।

— কোডার

কেন শুধু একটি পণ্য পর্যালোচনা শ্রেণি নেই? তারপরে পণ্য এবং পর্যালোচনা একই থাকে। অথবা আমি ভুল বুঝতে পারি।

— এলগ্রিঙ্গো গ্রান্দে

@ কোডার "স্ট্যাটিক পদ্ধতিগুলি পরীক্ষা করা সহজ", সত্যই? তাদের উপহাস করা যাবে না, আরও তথ্যের জন্য দেখুন: googletesting.blogspot.com/2008/12/…

— স্টুপারউজার

@ স্টুপার ইউজার: বিদ্রূপ করার মতো কিছুই নেই। Assert(5 = Math.Abs(-5));

— কোডার

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

— স্টুপারউজার

Answer 1

আরও গুরুত্বপূর্ণ কী: সলিড নীতি অনুসরণ করে, বা একটি সহজ ইন্টারফেস আছে?

ইন্টারফেস ভিজ-এ-ভিজ সলিড

এগুলি পারস্পরিক একচেটিয়া নয়। ইন্টারফেসটি আপনার ব্যবসায়ের মডেলটির প্রকৃতিটি ব্যবসায়ের মডেলের ক্ষেত্রে প্রকাশ করতে হবে। সলাইড নীতিগুলি অবজেক্ট ওরিয়েন্টেড কোড রক্ষণাবেক্ষণযোগ্যতা (এবং আমি বিস্তৃত অর্থে "রক্ষণাবেক্ষণ" বলতে চাই) একটি কোয়ান izing প্রাক্তনটি আপনার ব্যবসায়িক মডেলটির ব্যবহার এবং হেরফেরকে সমর্থন করে এবং পরবর্তীকালে কোড রক্ষণাবেক্ষণকে অনুকূলিত করে।

খোলা / বন্ধ নীতি

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

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

এটি আপনার সেরা শট দিন, আমাদের পাশে দাঁড়ানো ডাক্তারদের একটি দল রয়েছে

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

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

Comments

ওসিপি হ'ল আরও ভাল মানের একটি সূচক, কোনও কোডের জন্য দ্রুত নিয়ম নয় not যদি আপনি দেখতে পান যে ওসিপিটি সঠিকভাবে অনুসরণ করা কঠিন বা অসম্ভব, তবে এটি এমন একটি চিহ্ন যা আরও বেশি নমনীয় পুনরায় ব্যবহারের অনুমতি দেওয়ার জন্য আপনার মডেলটিকে রিফ্যাক্টর করা দরকার।

— কোডেক্সআর্কানিয়াম 16'12

আমি প্রোডাক্ট এবং পর্যালোচনার উদাহরণটি বেছে নিয়েছিলাম যে পণ্যটি প্রকল্পের মূল সত্তা, তবে পর্যালোচনাটি কেবল অ্যাড-অন। সুতরাং পণ্য ইতিমধ্যে বিদ্যমান, সমাপ্ত এবং পর্যালোচনা পরে আসে এবং বিদ্যমান কোড (Incl। পণ্য) না খোলার ছাড়া প্রবর্তন করা উচিত।

— ওল্ফগ্যাং

Answer 2

সলাইড হ'ল গাইডলাইন, তাই সিদ্ধান্ত গ্রহণের পরিবর্তে এটির নির্দেশকে প্রভাবিত করুন।

স্থির পদ্ধতিগুলি ব্যবহার করার সময় একটি বিষয় সম্পর্কে সচেতন থাকতে হবে তা হ'ল টেস্টেবলির উপর তাদের প্রভাব ।

---

পরীক্ষা forProduct(Product product)কোন সমস্যা হবে না।

এটি নির্ভর করে এমন কোনও কিছুর পরীক্ষা করা হবে।

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

চলুন একটি CUT()কল যাকে কল বলা হয়forProduct()

যদি forProduct()হয় staticআপনি পরীক্ষা করতে পারবেন না CUT()একটি পারমাণবিক ইউনিট হিসাবে এবং আপনার পরীক্ষার যে সব পরীক্ষা ইউনিট যুক্তিবিজ্ঞান ইন্টিগ্রেশন পরীক্ষার হয়ে।

সিইউটি-র জন্য একটি পরীক্ষায় ব্যর্থতা, CUT()বা forProduct()(বা এর নির্ভরশীল কোডগুলির মধ্যে) এর মধ্যে বা কোনও সমস্যার কারণে ঘটতে পারে যা ইউনিট পরীক্ষাগুলির নির্ণয়ের সুবিধাগুলি সরিয়ে দেয়।

আরো বিস্তারিত তথ্যের জন্য এই দুর্দান্ত ব্লগ পোস্টটি দেখুন: http://googletesting.blogspot.com/2008/12/static-methods-are-death-to-testability.html

---

এটি ব্যর্থ পরীক্ষার সাথে হতাশার দিকে পরিচালিত করতে পারে এবং তাদের চারপাশে থাকা ভাল অভ্যাস এবং বেনিফিটগুলি ত্যাগ করে।

Comments

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

— ওল্ফগ্যাং

+1, পরীক্ষার জন্য লাল পতাকা সেট করার জন্য ধন্যবাদ! আমি @ ওল্ফগ্যাংয়ের সাথে একমত, সাধারণত আমি খুব কঠোর নই তবে যখন আমার এই ধরণের পরীক্ষাগুলির প্রয়োজন হয় তখন আমি স্থির পদ্ধতিগুলি সত্যই ঘৃণা করি। সাধারণত যদি কোনও স্ট্যাটিক পদ্ধতি তার পরামিতিগুলির সাথে খুব বেশি ইন্টারঅ্যাক্ট করে বা অন্য কোনও স্থির পদ্ধতির সাথে ইন্টারেক্ট করে তবে আমি এটিকে একটি উদাহরণ পদ্ধতি তৈরি করতে পছন্দ করি।

— অ্যাড্রিয়ানো রেপিটি

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

— ইজকাটা

@ স্টুপারউসার If forProduct() is static you can't test CUT() as an atomic unit and all of your tests become integration tests that test unit logic.- আমি বিশ্বাস করি জাভাস্ক্রিপ্ট এবং পাইথন উভয়ই স্থির পদ্ধতিগুলিকে ওভাররাইড / উপহাস করার অনুমতি দেয়। যদিও আমি ১০০% নিশ্চিত নই।

— ইজকাটা

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

— স্টুপারউজার

Answer 3

আপনি যদি মনে করেন যে পণ্যটি পণ্যটির পর্যালোচনাগুলি সন্ধানের জন্য সঠিক জায়গা, তবে আপনি পণ্যটিকে সর্বদা এটির জন্য কাজ করতে একটি সহায়ক শ্রেণি দিতে পারেন। (আপনি বলতে পারেন কারণ আপনার ব্যবসায় কোনও পণ্যের শর্ত বাদে কোনও পর্যালোচনা নিয়ে কথা বলতে পারে না)।

উদাহরণস্বরূপ, আমি এমন কিছু ইনজেক্ট করতে প্রলুব্ধ হব যা পর্যালোচনা পুনরুদ্ধারের ভূমিকা পালন করেছিল। আমি সম্ভবত এটি ইন্টারফেস দিতে হবে IRetrieveReviews। আপনি এটি পণ্যটির নির্মাত্রে রাখতে পারেন (নির্ভরতা ইনজেকশন)। আপনি যদি পর্যালোচনাগুলি পুনরুদ্ধার করে কীভাবে পরিবর্তন করতে চান আপনি অন্য TwitterReviewRetrieverকোনও সহযোগী - একটি বা একটি AmazonReviewRetrieverবা MultipleSourceReviewRetrieverআপনার যা যা প্রয়োজন, ইনজেকশন দিয়ে সহজেই এটি করতে পারেন ।

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

Comments

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

— ওল্ফগ্যাং

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

— লুনিভোর

হ্যাঁ, সুতরাং এটি কৌশল প্যাটার্নের একটি বাস্তবায়ন হবে। যা তৃতীয় শ্রেণির পক্ষে যুক্তি হবে। (ক) এবং (খ) এটি সমর্থন করবে না। অনুসন্ধানকারী অবশ্যই একটি ওআরএম ব্যবহার করবে, সুতরাং অ্যালগরিদম প্রতিস্থাপনের কোনও কারণ নেই। দুঃখিত যদি আমি আমার প্রশ্নে এটি সম্পর্কে পরিষ্কার না থাকি।

— ওল্ফগ্যাং

Answer 4

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

এটি সঠিক নয়।

আপনি স্থিতিশীল পদ্ধতিটি পর্যালোচনা শ্রেণিতে রাখছেন কারণ ... কেন? আপনি কি এর সাথে লড়াই করছেন তা নয়? পুরো সমস্যা কি তাই না?

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

Comments

আমি সম্মত নই যে পর্যালোচনা পদ্ধতিটি এসআরপি লঙ্ঘন করবে। পণ্যটিতে, এটি কিন্তু পর্যালোচনাতে নয়। আমার সমস্যা ছিল যে এটি অচল। আমি যদি পদ্ধতিটিকে তৃতীয় শ্রেণিতে স্থানান্তরিত করি তবে এটি স্থির থাকবে এবং পণ্যটির প্যারামিটার থাকবে।

— ওল্ফগ্যাং

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

— এলগ্রিংগো গ্র্যান্ডে

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

— ওল্ফগ্যাং

Answer 5

আমি 'প্রোডাক্টের জন্য পর্যালোচনাগুলি পান' কার্যকারিতাটি Productক্লাস বা ক্লাসের মধ্যে রাখি না Review...

আপনার এমন একটি জায়গা আছে যেখানে আপনি পণ্যগুলি পুনরুদ্ধার করেন, তাই না? কিছু GetProductById(int productId)এবং সম্ভবত GetProductsByCategory(int categoryId)এবং তাই কিছু ।

তেমনি, আপনার পর্যালোচনাগুলি পুনরুদ্ধার করার জন্য একটি জায়গা থাকা উচিত GetReviewbyId(int reviewId)এবং এর সাথে সম্ভবত একটি GetReviewsForProduct(int productId)।

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

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

Comments

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

— কোডেক্সআর্কানিয়াম 16'12

@ কোডেক্সআরকানাম ভাল, আপনি একা নন :-)

— এরিক কিং

Answer 6

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

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

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

Comments

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

— ওল্ফগ্যাং

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

— অ্যাড্রিয়ানো রিপেটি

Answer 7

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

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

Comments

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

— ওল্ফগ্যাং

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

— pfries

আপনি যে ডিপেন্ডেন্সি ইনভার্সন প্রিন্সিপাল (ডিআইপি) বর্ণনা করছেন তা কি নয়?

— ওল্ফগ্যাং

তারা সম্পর্কিত নীতি। আপনার প্রতিস্থাপনের পয়েন্টটি ডিআইপি দ্বারা অর্জন করা হয়েছে।

— pfries

Answer 8

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

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

interface IProductRepository
{
    void SaveNewProduct(IProduct product);
    IProduct GetProductById(ProductId productId);
    bool TryGetProductByName(string name, out IProduct product);
}

interface IProduct
{
    ProductId Id { get; }
    string Name { get; }
}

class ExistingProduct : IProduct
{
    public ProductId Id { get; private set; }
    public string Name { get; private set; }
}

তারপরে আপনার আসলটি পদ্ধতি ইত্যাদির জন্য ProductRepositoryএকটি ফিরিয়ে দেয় etc.ExistingProductGetProductByProductId

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

আপনি যদি আপনার ডাটাবেস স্কিমা পরিবর্তন করেন তবে আপনি আপনার ডিটিও ইত্যাদি পরিবর্তন না করে আপনার সংগ্রহস্থল প্রয়োগ করতে পারেন

সুতরাং, সংক্ষেপে, আমার ধারণা আমি আপনার বিকল্পগুলির মধ্যে কোনওটিই বেছে নেব না। :)

Answer 9

স্থিতিশীল পদ্ধতিগুলি পরীক্ষা করা আরও কঠিন হতে পারে, তবে এর অর্থ এই নয় যে আপনি এগুলি ব্যবহার করতে পারবেন না - আপনাকে কেবল তাদের সেট আপ করতে হবে যাতে আপনার পরীক্ষা করার প্রয়োজন হয় না।

উভয় পণ্য.গেটরভিউ এবং পর্যালোচনা করুন .এর জন্য এমন একটি লাইন পদ্ধতি উত্পাদন করুন

new ReviewService().GetReviews(productID);

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

আপনার যদি অবশ্যই 100% কভারেজ থাকে তবে আপনার সংহতকরণ পরীক্ষাগুলিতে পণ্য / পর্যালোচনা শ্রেণীর পদ্ধতিগুলি কল করুন।

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