কোনও আপডেট পদ্ধতিতে রিটার্নের ধরণ যুক্ত করা কি "একক দায়িত্বের নীতিমালা" লঙ্ঘন করে?

Question

আমার একটি পদ্ধতি রয়েছে যা ডাটাবেসে কর্মীদের ডেটা আপডেট করে। Employeeতাই "আপডেট" বস্তু মানে আসলে একটি নতুন অবজেক্ট instantiate করার বর্গ, অপরিবর্তনীয় হয়।

আমি চাই যে Updateপদ্ধতিটি Employeeআপডেট হওয়া তথ্যের সাথে একটি নতুন উদাহরণ ফিরিয়ে আনুক , তবে এখন থেকে আমি বলতে পারি যে পদ্ধতির দায়িত্ব কর্মীর ডেটা আপডেট করা, এবং ডাটাবেস থেকে একটি নতুন Employeeঅবজেক্ট আনা , এটি কি একক দায়িত্বের নীতি লঙ্ঘন করে ?

ডিবি রেকর্ড নিজেই আপডেট করা হয়। তারপরে, একটি নতুন অবজেক্ট এই রেকর্ডটি উপস্থাপন করার জন্য তাত্ক্ষণিক হয়।

Comments

একটু ছদ্ম কোডটি এখানে অনেক দীর্ঘ যেতে পারে: আসলেই কি নতুন কোনও ডিবি রেকর্ড তৈরি হয়েছে, বা নিজেই ডিবি রেকর্ডটি আপডেট হয়েছে, তবে "ক্লায়েন্ট" কোডে একটি নতুন অবজেক্ট তৈরি করা হয়েছে কারণ শ্রেণিটি অপরিবর্তনীয় হিসাবে মডেল করা হয়েছে?

— মার্টিন বা

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

— থারসাল

@ থারসাল: যদি আপনার ডেটা সত্তাগুলি অপরিবর্তনীয় থাকে তবে আপডেট হওয়া ডেটা দিয়ে কোনও উদাহরণ ফিরিয়ে দেওয়া বেশ এসওপি, অন্যথায় আপনাকে নিজেই পরিবর্তিত ডেটা ইনস্ট্যান্টেশন করতে হবে।

— মাইকোয়াক

Compare-and-swapএবং test-and-setবহু-থ্রেড প্রোগ্রামিং তত্ত্বের মৌলিক ক্রিয়াকলাপ। তারা উভয়ই একটি রিটার্ন টাইপ সহ আপডেট পদ্ধতি এবং অন্যথায় কাজ করতে পারে না। কমান্ড-ক্যোয়ারী বিচ্ছেদ বা একক দায়িত্বের নীতিমালার মতো এই ধারণাগুলি কি ভাঙে? হ্যাঁ, এবং এটি পুরো বিষয়টি । এসআরপি সর্বজনীনভাবে ভাল জিনিস নয় এবং বাস্তবে এটি সক্রিয়ভাবে ক্ষতিকারক হতে পারে।

— ম্যাসাল্টারস

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

— সুপারক্যাট

Answer 1

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

একক-দায়িত্ব নিয়মের উদ্দেশ্য হ'ল প্রতিটি ফাংশনকে একটি করে স্ব-অন্তর্ভুক্ত, সুসংগত জিনিস করে প্রোগ্রামগুলি বুঝতে এবং বজায় রাখা সহজ করা।

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

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

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

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

অন্যদিকে, যদি অবজেক্টটি তৈরি করা ডাটাবেস রেকর্ড লেখার থেকে একদম স্বতন্ত্র কাজ থাকে এবং একজন কলার লিখতে ভাল করতে চান তবে অবজেক্টটি তৈরি করতে না পারে, তবে এটি ব্যর্থ হতে পারে। যদি কোনও কলার অবজেক্টটি চায় তবে রাইটটি না করে, তবে আপনাকে অবজেক্টটি পাওয়ার আরও একটি উপায় সরবরাহ করতে হবে, যার অর্থ রিডানড্যান্ট কোড লেখা could

তবে আমি মনে করি 1 দৃশ্যের সম্ভাবনা বেশি, তাই আমি বলব, সম্ভবত কোনও সমস্যা নেই।

Comments

সমস্ত উত্তরের জন্য ধন্যবাদ, কিন্তু এই সত্যিই আমাকে সবচেয়ে বেশি সাহায্য করেছে।

— সিপো

আপনি যদি পুনরায় ফর্ম্যাট না করে প্রেরণ করতে না চান এবং পরে ডেটা প্রেরণের পাশাপাশি পুনরায় ফর্ম্যাট করার কোনও সুবিধা নেই, তবে এগুলি দুটি নয় one

— জোকার_ভিডি

public function sendDataInClientFormat() { formatDataForClient(); sendDataToClient(); } private function formatDataForClient() {...} private function sendDataToClient() {...}

— সিজে ডেনিস

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

— জয়

Answer 2

এসআরপি-র ধারণাটি হল মডিউলগুলি পৃথক পৃথকভাবে করার সময় 2 টি ভাল কাজ করা ভাল রক্ষণাবেক্ষণ এবং সময়মতো কম স্প্যাগেটির জন্য করা বন্ধ করে দেওয়া। যেমন এসআরপি বলছে "পরিবর্তনের এক কারণ"।

আপনার ক্ষেত্রে, যদি আপনার একটি রুটিন থাকে যা "আপডেট হওয়া অবজেক্টটিকে আপডেট করে এবং ফিরিয়ে দেয়", আপনি এখনও অবজেক্টটি একবারে পরিবর্তন করছেন - এটি পরিবর্তনের 1 কারণ প্রদান করছেন। আপনি যে অবজেক্টটি ডানদিকে ফিরিয়েছেন তা এখানেও নেই বা সেখানেও নেই, আপনি এখনও সেই একক বস্তুটিতে অপারেট করছেন। কোডটিতে একটি এবং কেবল একটির জন্য জিনিস রয়েছে।

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

Comments

বিকল্পভাবে, এটি "সমস্ত ক্রিয়াকলাপকে একটি একক কলকে হ্রাস করার চেষ্টা করার বিষয়ে নয়", তবে প্রশ্নটিতে থাকা আইটেমটি ব্যবহার করার সময় আপনাকে কতগুলি ভিন্ন ক্ষেত্রে চিন্তা করতে হবে তা হ্রাস করার জন্য।

— jpmc26

Answer 3

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

বর্ণালীটির অন্য প্রান্তে এমন কোনও পদ্ধতি রয়েছে যা কোনও বস্তুর অবস্থার সম্পর্কে তথ্য দেয়। সাধারণটি isActiveএকক দায়িত্ব হিসাবে এই তথ্য দিচ্ছে giving সম্ভবত সবাই একমত যে এটি ঠিক আছে।

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

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

Comments

প্রথমটি সফল হয়েছে কিনা তা দেখার জন্য যদি আপনাকে দ্বিতীয় পদ্ধতিতে কল করতে হয়, তবে দ্বিতীয়টির ফলাফল পেতে আপনাকে তৃতীয় পদ্ধতিটি কল করতে হবে না? তারপরে যদি আপনি আসলে ফলাফলটি চান তবে ভাল ...

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

— এরিক আলাপ ää

Answer 4

এটি কি একক দায়িত্ব নীতি লঙ্ঘন করে?

অগত্যা। যদি কিছু হয় তবে এটি কমান্ড-কোয়েরি বিচ্ছেদের প্রধান লঙ্ঘন করে ।

দায়িত্ব হ'ল

কর্মচারী তথ্য আপডেট করুন

অন্তর্ভুক্ত বোঝার সাথে যে এই দায়িত্বে অপারেশনের স্থিতি রয়েছে; উদাহরণস্বরূপ, যদি অপারেশন ব্যর্থ হয়, একটি ব্যতিক্রম ছুঁড়ে দেওয়া হয়, যদি এটি সফল হয়, আপডেট কর্মচারী ফিরিয়ে আনা হবে ইত্যাদি etc.

আবার, এটি সবই ডিগ্রি এবং বিষয়গত বিচারের বিষয়।

---

সুতরাং কমান্ড-ক্যোয়ারী বিচ্ছেদ সম্পর্কে কি?

ঠিক আছে, সেই নীতিটি বিদ্যমান, তবে একটি আপডেটের ফলাফল ফিরিয়ে দেওয়া আসলে খুব সাধারণ।

(1) জাভার Set#add(E)উপাদান যুক্ত করে এবং সেটটিতে পূর্ববর্তী অন্তর্ভুক্তি ফিরিয়ে দেয়।

if (visited.add(nodeToVisit)) {
    // perform operation once
}

এটি সিকিউএস বিকল্পের চেয়ে আরও দক্ষ, যার জন্য দুটি লুকআপ করতে হতে পারে।

if (!visited.contains(nodeToVisit)) {
    visited.add(nodeToVisit);
    // perform operation once
}

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

Answer 5

একক দায়িত্ব হ'ল এমন এক শ্রেণীর সম্পর্কে যা একাধিক কারণে পরিবর্তনের প্রয়োজন হয় না।

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

এটি কীভাবে এটি ডাটাবেসে নিজেকে বাঁচায় তা জানার জন্য আমার কর্মচারী শ্রেণির প্রয়োজন হবে না, কারণ এটি তখন কর্মীদের পরিবর্তনের জন্য এবং কীভাবে ডেটা সংরক্ষণ করা হবে তার পরিবর্তনের জন্য পরিবর্তিত হবে।

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

তবে যে আপডেট পদ্ধতিটি কেবল এটি আপডেট করেছে তা ভাল।

Answer 6

Wrt। নির্দিষ্ট ক্ষেত্রে:

Employee Update(Employee, name, password, etc) (আমার কাছে প্রচুর প্যারামিটার হওয়ায় আসলে একজন বিল্ডার ব্যবহার করছেন)।

দেখে মনে হচ্ছে এই Updateপদ্ধতিতে Employeeবিদ্যমান কর্মচারী সনাক্ত করতে (?) এবং এই কর্মচারীর পরিবর্তনের জন্য পরামিতিগুলির একটি সেট প্রথম প্যারামিটার হিসাবে গ্রহণ করে।

আমি কি এই মনে করতে পারে সম্পন্ন ক্লিনার হও। আমি দুটি কেস দেখতে পাচ্ছি:

(ক) Employee আসলে কোনও ডাটাবেস / অনন্য আইডি ধারণ করে যার দ্বারা এটি সর্বদা ডেটাবেসে সনাক্ত করা যায়। (যেমন, আপনি কি না পুরো রেকর্ড মান ডিবি এটা এটি সেট প্রয়োজন।

এই ক্ষেত্রে, আমি এমন একটি void Update(Employee obj)পদ্ধতি পছন্দ করব , যা কেবলমাত্র আইডি দ্বারা বিদ্যমান রেকর্ডটি সন্ধান করে এবং তারপরে পাস করা অবজেক্ট থেকে ক্ষেত্রগুলি আপডেট করে। অথবা হতে পারে একটিvoid Update(ID, EmployeeBuilder values)

এর যে ভিন্নতাটি আমি দরকারী পেয়েছি তা হ'ল কেবল এমন একটি void Put(Employee obj)পদ্ধতি রয়েছে যা সন্নিবেশ করায় বা আপডেট করে যা রেকর্ড (আইডি দ্বারা) বিদ্যমান কিনা তার উপর নির্ভর করে।

(খ) পূর্ণ বিদ্যমান রেকর্ড ডিবি লুকআপ কার্যকলাপের জন্য দরকারি, যে ক্ষেত্রে এটি এখনও আছে আরো জানার জন্য পারে: void Update(Employee existing, Employee newData)।

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

অন্যান্য উত্তরে উল্লিখিত একত্রে প্রয়োজনীয় প্রয়োজনীয়তা (পারমাণবিক সেট-এবং-পুনরুদ্ধার / তুলনা-সোয়াপ ইত্যাদি) আমি এখন পর্যন্ত যে ডিবি কোডটিতে কাজ করেছি তাতে কোনও সমস্যা হয়নি। কোনও ডিবির সাথে কথা বলার সময়, আমি মনে করি এটি সাধারণভাবে লেনদেন স্তরে পরিচালনা করা উচিত, পৃথক বিবরণী স্তরে নয়। (এটি এমনটি বলার অপেক্ষা রাখে না যে এমন কোনও নকশাগুলি নাও থাকতে পারে যেখানে "পারমাণবিক" Employee[existing data] Update(ID, Employee newData)অর্থ বোধ করতে পারে না, তবে ডিবি এটি ব্যবহার করে যা আমি সাধারণত দেখতে পাই না।)

Answer 7

এখন পর্যন্ত এখানে সবাই ক্লাস সম্পর্কে কথা বলছে। তবে ইন্টারফেসের দৃষ্টিকোণ থেকে এটি সম্পর্কে ভাবেন।

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

সুতরাং আপনি জিজ্ঞাসা করতে পারেন:

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

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

এই বিবেচনার ভিত্তিতে আপনি সিদ্ধান্ত নিতে পারেন।

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

Answer 8

আপনার পদ্ধতির ঠিক আছে। অপরিচ্ছন্নতা একটি দৃ strong় দৃ is়তা। আমি কেবলমাত্র এটিই জিজ্ঞাসা করব: আপনি অন্য কোনও জায়গা যেখানে আপনি অবজেক্টটি তৈরি করেন। যদি আপনার অবজেক্টটি পরিবর্তনযোগ্য না হয় তবে আপনাকে অতিরিক্ত প্রশ্নের উত্তর দিতে হবে কারণ "রাজ্য" চালু হয়েছে। এবং কোনও জিনিসের রাষ্ট্র পরিবর্তন বিভিন্ন কারণে ঘটতে পারে। তারপরে আপনার কেসগুলি আপনার জানা উচিত এবং সেগুলি নিষ্প্রয়োজন বা বিভক্ত হওয়া উচিত নয়।