পদ্ধতি প্যারামিটার হিসাবে সনাক্তকারী বনাম ডোমেন অবজেক্ট

Question

পদ্ধতি / ফাংশন প্যারামিটার হিসাবে অনন্য আইডি বনাম অবজেক্ট ব্যবহার করার পক্ষে বা বিপক্ষে কোনও উদ্দেশ্যমূলক যুক্তি রয়েছে কি? (এবং অন্যান্য বস্তুর সদস্য?) বিশেষত স্ট্যাটিকালি টাইপ করা ভাষার প্রেক্ষাপটে (সি # / জাভা / স্কালা)

বস্তু নিজেই পেশাদার:

• আরও টাইপসেফ কল। আইডি সহ আর্গুমেন্টের ভুল অর্ডার দেওয়ার ঝুঁকি থাকে। এটি কেবলমাত্র সেই শ্রেণীর আইডি সঞ্চয় করে এমন প্রতিটি শ্রেণীর জন্য একটি 'মিনি' শ্রেণি রেখে যদিও এটি প্রশমিত করা যায়।
• অধ্যবসায় থেকে একবার পান, আবার পাওয়ার দরকার নেই
• আইডির সাহায্যে আইডি টাইপ পরিবর্তন হলে, আন্তঃ -> দীর্ঘ বলুন, তারপরে ভুল হওয়ার সম্ভাবনা সহ বোর্ড জুড়ে পরিবর্তন প্রয়োজন .. (কোর্টসি: https://softwareengineering.stackexchange.com/a/284734/145808 )

আইডি ব্যবহারের পেশাদার:

• বেশিরভাগ সময় সত্যিকারের অবজেক্টের প্রয়োজন হয় না, কেবল অনন্যই করা হয়, তাই আইডি থাকার ফলে অধ্যবসায় থেকে এটি সময় বাঁচায়।

---

এই কৌশলগুলির একটি মিশ্রণ, যতদূর আমি দেখতে পাচ্ছি, কেবলমাত্র উভয়েরই পক্ষে এবং উভয়ের পক্ষে ভাল হবে।

প্রদত্ত যে এটি একটি নিবিড়ভাবে সংজ্ঞায়িত সমস্যা, আমি আশা করি এর উদ্দেশ্যমূলক উত্তর রয়েছে এবং "আমার মনে হয়" বা "আমার পছন্দ" প্রকার নয় ... :-)।

সম্পাদনা: একজন মন্তব্যকারীর পরামর্শের প্রসঙ্গে- একমাত্র সীমাবদ্ধতা হ'ল স্থায়ীভাবে টাইপ করা ভাষা। অ্যাপ্লিকেশনটি একটি সাধারণ উদ্দেশ্য অ্যাপ্লিকেশন, যদিও নির্দিষ্ট ব্যবহারের পরিস্থিতিগুলির উপর ভিত্তি করে উত্তর পেতে পেরে খুশি।

সম্পাদনা: আরও কিছু প্রসঙ্গ। বলুন আমার কাছে একটি বই পরিচালনার ব্যবস্থা আছে। আমার মডেলটি হ'ল:

Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member }
Member: {id: Int, name: String}

Table- wishlist: { isbn: String, memberId: Int}
Table- borrows:  { id: Int, memberId: Int}  

Method: 
isInWishList( book: Book, member: Member ) vs isInWishList( bookId: Int,  memberId: Int)

handleBorrowRequest( memberId: Int, book: Book ){ 
   //the login system doesn't actually get the entire member structure, only the member id. I don't need the full member yet. can run a query to verify that the memberId has less than max allowed books for borrowing. 
}

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

অবশ্যই, এগুলি কেবল আমার পয়েন্ট। আমি নিশ্চিত যে আমি জিনিসগুলি মিস করছি তাই পক্ষে / বিপক্ষে পয়েন্টগুলি কী তা জানতে চেয়েছি।

Comments

আপনি কি আরও কিছু প্রসঙ্গে আপনার প্রশ্ন সম্পাদনা করতে পারেন? অন্য পরিস্থিতি কী তা পরিষ্কার নয়। আমি অনুমান করতে যাচ্ছি যে আপনি এমন একটি বস্তু সম্পর্কে কথা বলছেন যা একটি ওআরএম সিস্টেম দ্বারা পরিচালিত হয় (যেমন হাইবারনেট) এবং এটি "মিনি-ক্লাস" দ্বারা আপনি বোঝাচ্ছেন একটি অলস-লোডিং প্রক্সি-অবজেক্ট।

— ড্যারেন

সম্ভবত সম্পর্কিত? প্রোগ্রামার্স.স্ট্যাক্কেচেঞ্জঞ্জ

— প্রশ্নগুলি

এখানে মন্তব্য হিসাবে যুক্ত করা (যতক্ষণ না আমি একটি পূর্ণ বৈশিষ্ট্যযুক্ত উত্তরের প্রসারিত করার পর্যাপ্ত প্রসঙ্গটি পেতে পারি): আপনি যদি নিজের কোডটিতে আইডির মানগুলি হার্ড-কোডিং না করেন (একটি বড় সংখ্যা নেই), আপনাকে এখনও আপনার আইডি মানগুলি লোড করতে হবে কোথাও থেকে? "বেশিরভাগ সময়" এছাড়াও বেশ অস্পষ্ট

— IMHO

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

— 0fnt

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

— রওয়ং

Answer 1

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

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

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

আমরা যখন ডাটাবেসে যাওয়ার প্রয়োজনীয়তা এবং ব্যয় হ্রাস করি, আমরা অস্তিত্বটিকে পরামিতি হিসাবে ব্যবহার করার পক্ষে পেশাদারর বেশিরভাগ অংশ রেখেছি:

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

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

Comments

অ্যাপ্লিকেশন চলমান একাধিক দৃষ্টান্ত দিয়ে ক্যাচিং ভাল স্কেল করবে না। আমার নিজের জায়গায় ক্যাচিং আছে। পয়েন্টগুলি যদিও দুর্দান্ত।

— 0fnt

আমি আইডির বিপরীতে আরও একটি বিষয় অনুমান করি যে আইডি ব্যবহার করা মানে বৈধতা ছাড়াও কলিং অধ্যবসাকে বোঝায়, আসলে বস্তুটি খুব বেশি পাওয়া যায়।

— 0fnt

Answer 2

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

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

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

কোনও নতুন প্রোগ্রামার, বা আপনার ভবিষ্যত স্ব বোঝার জন্য সবচেয়ে সহজ সমাধানটি সন্ধান করুন, যা ভিতরে Bookএবং Memberঅবজেক্টগুলিকে পাস করবে Only কেবল আসল সন্ধানের পরেই পারফরম্যান্স সমস্যা আপনি কেবল আইডি পাস করার সাথে নিজেকে চিন্তিত করতে পারেন।

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

public boolean isInWishList(int bookId, int memberId) {
    // ...
}

public boolean isInWishList(Book book, Member member) {
    return isInWishList(book.getId(), member.getId());
}

এই প্রশ্নের আসল উত্তর হ'ল উভয় পদ্ধতি লেখা, দৃ the়ভাবে টাইপ করা সংস্করণ থেকে পূর্ণসংখ্যার কেবল সংস্করণটি কল করা এবং বব আপনার মামা।