আপনি কি সাধারণত কোনও জিনিস বা তাদের সদস্য ভেরিয়েবলগুলি ফাংশনে প্রেরণ করেন?

Question

এই দুটি ক্ষেত্রে সাধারণত কোনটি গ্রহণ করা হয়:

function insertIntoDatabase(Account account, Otherthing thing) {
    database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue());
}

অথবা

function insertIntoDatabase(long accountId, long thingId, double someValue) {
    database.insertMethod(accountId, thingId, someValue);
}

অন্য কথায় পুরো বিষয়গুলি বা কেবল আপনার প্রয়োজনীয় ক্ষেত্রগুলিকেই প্রায় পাস করা ভাল?

Comments

এটি পুরোপুরি নির্ভর করে ফাংশনটি কীসের জন্য এবং এটি কীভাবে প্রশ্নের মধ্যে থাকা বস্তুর সাথে সম্পর্কিত (বা সম্পর্কিত নয়)।

— মেটাফাইট

এটাই সমস্যা। আমি কখন একটি বা অন্যটি ব্যবহার করতে পারি তা বলতে পারি না। আমার মনে হয় যে আমি উভয় পদ্ধতির সমন্বয় করতে কোডটি সর্বদা পরিবর্তন করতে পারি।

— এজেজে

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

— এরিক tদ

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

— মার্টিন মাট 24'16

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

— tofro

Answer 1

উভয়ই অন্যজনের চেয়ে সাধারণত ভাল হয় না। এটি একটি রায় কল যা আপনাকে কেস-কেস-কেস ভিত্তিতে করতে হবে।

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

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

function addWidgetButtonClicked(clickEvent) {
    // get form data
    // get user's account
    insertIntoDatabase(account, data);
}
function insertIntoDatabase(Account account, Otherthing data) {
    // open database connection
    // check data doesn't already exist
    database.insertMethod(account.getId(), data.getId(), data.getSomeValue());
}

বনাম

function addWidgetButtonClicked(clickEvent) {
    // get form data
    // get user's account
    insertIntoDatabase(account.getId(), data.getId(), data.getSomeValue());
}
function insertIntoDatabase(long accountId, long dataId, double someValue) {
    // open database connection
    // check data doesn't already exist
    database.insertMethod(accountId, dataId, someValue);
}

প্রথম সংস্করণে, ইউআই কোডটি অন্ধভাবে dataবস্তুটি পাস করছে এবং এটি থেকে দরকারী ক্ষেত্রগুলি বের করার জন্য এটি ডাটাবেস কোডের উপর নির্ভর করবে। দ্বিতীয় সংস্করণে, ইউআই কোড dataবস্তুটিকে তার দরকারী ক্ষেত্রগুলিতে বিভক্ত করছে এবং কোথা থেকে এসেছে তা না জেনে ডেটাবেস কোড তাদের সরাসরি গ্রহণ করে। মূল বিষয়টি হ'ল, যদিdata কোনওভাবে অবজেক্টের কাঠামো পরিবর্তন হয় তবে প্রথম সংস্করণটির পরিবর্তনের জন্য কেবল ডাটাবেস কোডের প্রয়োজন হবে, যখন দ্বিতীয় সংস্করণে কেবল ইউআই কোডটি পরিবর্তন করতে হবে । এই দু'জনের মধ্যে কোনটি সঠিক তা মূলত নির্ভর করে যে কী ধরণের ডেটা dataরয়েছে তা নির্ভর করে তবে এটি সাধারণত খুব সুস্পষ্ট। উদাহরণস্বরূপ, যদিdata"20/05/1999" এর মতো একটি ব্যবহারকারী দ্বারা সরবরাহিত স্ট্রিং, এটি Dateপাস করার আগে এটিকে যথাযথ ধরণের রূপান্তর করা UI কোড অবধি হওয়া উচিত ।

Answer 2

এটি একটি বিস্তৃত তালিকা নয়, তবে কোনও বিষয়কে আর্গুমেন্ট হিসাবে কোনও পদ্ধতিতে স্থান দেওয়া উচিত কিনা তা সিদ্ধান্ত নেওয়ার সময় নিম্নলিখিত কয়েকটি কারণ বিবেচনা করুন:

বস্তু কি অপরিবর্তনীয়? ফাংশনটি কি 'খাঁটি'?

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

থাম্বের নিয়ম হিসাবে, যথাসম্ভব যথাসম্ভব যথাযথভাবে নিশ্চিত করার লক্ষ্য রাখুন যে কোনও পদ্ধতিতে আপনি যে কোনও বস্তু পাস করেন তা স্পষ্টভাবে অপরিবর্তনীয়।

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

ইতিমধ্যে পদ্ধতিটিতে কত যুক্তি রয়েছে?

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

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

উত্তীর্ণ বস্তুটি কি আপনার অ্যাপ্লিকেশনটির মধ্যে কেবল "স্তর" এর সাথে সম্পর্কিত (উদাহরণস্বরূপ, একটি ভিউমোডেল, বা একটি ORM সত্তা?)

উদ্বেগের বিচ্ছিন্নতা (এসসি) সম্পর্কে চিন্তা করুন । কখনও কখনও নিজেকে জিজ্ঞাসা করা হয় যে আপনার পদ্ধতিটি একই স্তরের বা মডিউলটির সাথে "মালিকানাধীন" রয়েছে যেখানে আপনার পদ্ধতিটি বিদ্যমান (যেমন একটি হাত ঘূর্ণিত এপিআই র‌্যাপার লাইব্রেরি, বা আপনার মূল বিজনেস লজিক স্তর ইত্যাদি) object বস্তুটি সত্যই সেই স্থানে পৌঁছে দেওয়া উচিত কিনা তা জানাতে পারে পদ্ধতি।

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

'স্তরগুলি' এর মধ্যে ডেটা পাস করার ক্ষেত্রে, কোনও পদ্ধতিতে প্লেইন-ডেটা পরামিতিগুলি পাস করা সাধারণত 'ভুল' স্তর থেকে কোনও বস্তুতে যাওয়ার চেয়ে পছন্দসই। যদিও আপনি সম্ভবত এটির পরিবর্তে মানচিত্র করতে পারেন এমন 'ডান' স্তরে উপস্থিত আলাদা আলাদা মডেলগুলি পাওয়া ভাল ধারণা।

ফাংশনটি নিজেই কি খুব বড় এবং / বা জটিল?

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

ফাংশনটি একটি আদেশ / ক্যোয়ারী অবজেক্ট হওয়া উচিত?

কিছু ক্ষেত্রে ডেটা এবং ফাংশনের মধ্যে সম্পর্ক ঘনিষ্ঠ হতে পারে; এই ক্ষেত্রে কমান্ড অবজেক্ট বা কোয়েরি অবজেক্ট উপযুক্ত কিনা তা বিবেচনা করুন ।

কোনও পদ্ধতিতে কোনও অবজেক্ট প্যারামিটার যুক্ত করা কি অন্তর্ভুক্ত শ্রেণিকে নতুন নির্ভরতা অবলম্বন করতে বাধ্য করে?

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

আপনার কি সত্যিই কোনও সম্পূর্ণ অবজেক্টের চারপাশে যেতে হবে বা আপনার কেবলমাত্র সেই অবজেক্টের ইন্টারফেসের একটি ছোট্ট অংশ প্রয়োজন?

আপনার ক্রিয়াকলাপের ক্ষেত্রে ইন্টারফেস বিভাজন নীতিটি বিবেচনা করুন - যেমন কোনও বস্তুর মধ্যে যাওয়ার সময় এটি কেবলমাত্র যুক্তিটির ইন্টারফেসের অংশগুলির উপর নির্ভর করে যা এটি (ফাংশন) আসলে প্রয়োজন actually

Answer 3

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

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

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

Comments

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

— লাইভ

Answer 4

এটা নির্ভর করে.

বিশদভাবে বলতে গেলে, আপনার পদ্ধতিটি যে প্যারামিটারগুলি গ্রহণ করে সেগুলি আপনি যা করার চেষ্টা করছেন তা শব্দার্থভাবে মেলানো উচিত। EmailInviterএকটি inviteপদ্ধতির একটি এবং এই তিনটি সম্ভাব্য বাস্তবায়ন বিবেচনা করুন :

void invite(String emailAddressString) {
  invite(EmailAddress.parse(emailAddressString));
}
void invite(EmailAddress emailAddress) {
  ...
}
void invite(User user) {
  invite(user.getEmailAddress());
}

একটি পাসিং Stringযেখানে আপনি একটি মধ্যে পাস করা উচিত EmailAddressত্রুটিপূর্ণ কারণ সব স্ট্রিং ই-মেইল ঠিকানা আছে। EmailAddressশ্রেণী ভাল শব্দার্থগতভাবে পদ্ধতি আচরণ মেলে। তবে পাস করার Userবিষয়টিও ত্রুটিযুক্ত কারণ কেন পৃথিবীতে একটি EmailInviterআমন্ত্রণকারী ব্যবহারকারীদের মধ্যে সীমাবদ্ধ থাকতে হবে? ব্যবসা সম্পর্কে কি? আপনি যদি কোনও ফাইল বা কমান্ড লাইন থেকে ইমেল ঠিকানাগুলি পড়ছেন এবং তারা ব্যবহারকারীদের সাথে সম্পর্কিত না হন তবে কী করবেন? ডাক তালিকা? তালিকাটি এগিয়ে যায়।

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

Answer 5

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

insertIntoDatabase(new Account(id) , new Otherthing(id, "Value"));

এর চেয়ে বেশি পঠনযোগ্য কল

insertIntoDatabase(myAccount.getId(), myOtherthing.getId(), myOtherthing.getValue() );

Comments

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

— জ্বলন্ত

Answer 6

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

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

আপনি যখন কেবল কোনও অবজেক্টে কোনও গ্রহণযোগ্য ক্ষেত্র লিখতে চান তখন অবজেক্টটি পুনরুদ্ধার করার জন্য কোনও পদ্ধতি লিখতে হয়:

public User getUser(String primaryKey) {
  return ...;
}

সেই কল করার সময়ে, কলিং কোডটির এখনও অবজেক্টটির কোনও রেফারেন্স পাওয়া যায়নি কারণ সেই পদ্ধতিটি কল করার বিন্দুটি অবজেক্টটি পাওয়ার জন্য।

Comments

"আপনি যদি ক্ষেত্রগুলি পরিবর্তন করেন তবে কি হবে Otherthing?" (1) এটি উন্মুক্ত / বদ্ধ নীতি লঙ্ঘন হবে। (২) এমনকি আপনি যদি পুরো অবজেক্টে পাস করেন তবে তার মধ্যে কোডটি সেই বস্তুর সদস্যদের অ্যাক্সেস করে (এবং যদি তা না হয় তবে কেন বস্তুটি পাস করবে?) এখনও ভেঙে যাবে ...

— ডেভিড আরনো

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

Answer 7

রক্ষণাবেক্ষণের দৃষ্টিকোণ থেকে, সংকলক পর্যায়ে যুক্তিগুলি একে অপরের থেকে পরিষ্কারভাবে পৃথক হওয়া উচিত should

// this has exactly one way to call it
insertIntoDatabase(Account ..., Otherthing ...)

// the parameter order can be confused in practice
insertIntoDatabase(long ..., long ...)

প্রথম নকশাটি বাগগুলির প্রাথমিক সনাক্তকরণের দিকে পরিচালিত করে। দ্বিতীয় নকশা সূক্ষ্ম রানটাইম সমস্যাগুলির দিকে নিয়ে যেতে পারে যা পরীক্ষায় প্রদর্শিত হয় না। সুতরাং প্রথম নকশা পছন্দ করা হয়।

Answer 8

দুজনের মধ্যে আমার পছন্দটি প্রথম পদ্ধতি:

function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); }

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

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

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

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

কোডটি এখন যেমন দাঁড়িয়েছে, প্রশ্নটি উঠছে "এই ফাংশনটি কোথায় হবে বা হওয়া উচিত?" এটি কি অ্যাকাউন্টের অংশ, না অন্যদিকের? কোথায় যায়?

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

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

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

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

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

Answer 9

উভয় পদ্ধতির নিজস্ব মতামত রয়েছে cons একটি দৃশ্যে যা ভাল তা হ'ল ব্যবহারের ক্ষেত্রে অনেকটা নির্ভর করে।

---

প্রো একাধিক প্যারাম, কনজ অবজেক্ট রেফারেন্স:

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

---

প্রো অবজেক্ট রেফারেন্স:

• ইন্টারফেসিং সাফ করুন যে পদ্ধতিটি অবজেক্ট রেফারেন্স প্রকারের সাথে আবদ্ধ, যাতে দুর্ঘটনাক্রমে সম্পর্কযুক্ত / অবৈধ মানগুলি পাস করা কঠিন হয়ে পড়ে
• একটি ক্ষেত্র / গেটর নামকরণের জন্য পদ্ধতির সমস্ত অনুরোধে পরিবর্তনগুলি প্রয়োজন এবং কেবল এটির প্রয়োগে নয়
• যদি কোনও নতুন সম্পত্তি যুক্ত করা হয় এবং পাস করার প্রয়োজন হয় তবে পদ্ধতি স্বাক্ষরে কোনও পরিবর্তন প্রয়োজন
• পদ্ধতি অবজেক্টের স্থিতি পরিবর্তন করতে পারে
• অনুরূপ আদিম ধরণের অনেকগুলি ভেরিয়েবল পাস করা অর্ডার সম্পর্কিত কলারকে বিভ্রান্ত করে তোলে (বিল্ডার প্যাটার্ন সমস্যা)

---

সুতরাং, কী ব্যবহার করা দরকার এবং কখন ব্যবহারের ক্ষেত্রে অনেক কিছু নির্ভর করে

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

Answer 10

একদিকে আপনার একাউন্ট এবং অন্য কিছু জিনিস রয়েছে। অন্যদিকে, কোনও অ্যাকাউন্টের আইডি এবং অন্য কোনও কিছুর আইডি দিয়ে আপনার কাছে একটি ডাটাবেসগুলিতে একটি মান সন্নিবেশ করার ক্ষমতা রয়েছে। এই দুটি দেওয়া জিনিস।

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

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

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

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