অপরিবর্তনীয় বস্তু এবং ডিডিডি কি এক সাথে যায়?


18

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

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

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


উত্তর:


16

অপরিবর্তনীয় বস্তু (যেমন ফাংশনাল প্রোগ্রামিং) ব্যবহার করে গণনা অগত্যা উত্পন্ন প্রতিটি বস্তু স্থির করে রাখে না!


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

1
আমি ভাবছিলাম যে অপরিবর্তনীয় বস্তুগুলি মধ্যবর্তী গণনার জন্য কার্যকর হবে (সমান্তরাল থ্রেডগুলিতে)
স্টিভেন এ। লো

11

ডোমেনে কী পরিবর্তনযোগ্য তার অর্থ এটি ডাটাবেসে অপরিবর্তনীয় হতে হবে? উদাহরণস্বরূপ নিম্নলিখিত অনুমানকারী গ্রাহকের সর্বদা একটি ঠিকানা রয়েছে তা বিবেচনা করুন:

customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);

গ্রাহক আইডি 1 হ'ল বিবেচনা করে এখন নিম্নলিখিত স্ক্যুএল চালানো হচ্ছে:

INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');

ঠিকানায় এখন নিম্নলিখিত পরিবর্তনগুলি করা হয়েছে:

customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);

এবং অধ্যবসায় স্তরটি খুব চতুর হয়ে নিম্নলিখিত স্ক্যুএল চালায়:

UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;

এইভাবে আপনি পৃথক মুছে ফেলা এবং INSERT বিবৃতিটির ওভারহেড এড়াতে পারেন। এছাড়াও আমি মনে করি কিছু আরডিবিএমএসের ইনসার্ট রিপ্লেস বা কিছু আছে। মাইএসকিউএল-এর রিপ্লেস রয়েছে


+1 আমি আপনার সাথে সাধারণ নীতিতে একমত: আমি দেখতে পাচ্ছি না কেন অপরিবর্তনীয় ডোমেন অবজেক্টগুলি অপরিহার্যভাবে ডিবি সারি বোঝায়।
আন্দ্রেস এফ।

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

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

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

@ এবং "এটি 'অপরিবর্তনীয় মানের বস্তু' করার কেবল একটি উপায়, এটি ডাটাবেসে সত্যই পরিবর্তনযোগ্য নয়" " সত্যই এটি আমার দিনকে ধন্যবাদ জানিয়েছে
সুদর্শন

6

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


4

এটি নির্ভরযোগ্য অবজেক্টটি কীভাবে ডাটাবেসে ম্যাপ করা হয় তার উপর নির্ভর করে। এটি যদি ডেটটাইমের মতো (জোডা টাইম লাইব্রেরি থেকে) একটি উপাদান থাকে তবে মান পরিবর্তন করার ফলে সন্নিবেশের পরিবর্তে আপডেট হবে update তবে, যদি অপরিবর্তনীয় কোনও টেবিলে সারি লাগানোর জন্য আরও জটিল হয় তবে আপনার ব্লাটের সমস্যা হয়েছে got

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

সবকিছুরই অপরিবর্তনীয় ডোমেন অবজেক্ট (কেবলমাত্র তাদের উপাদানগুলির পরিবর্তে) অধ্যবসায়ের সাথে কিছুটা মিল নয়।


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

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

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

4

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

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

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

  • আপনার বাস্তবায়ন আপনার সমস্যা ডোমেনের একটি ডোমেন মডেল উপস্থাপন করে না। এই ক্ষেত্রে আপনার সমস্যা ডোমেনে সংশোধন করার মতো রাষ্ট্রের সত্তা রয়েছে। এবং এটি আপনি এটি কার্যকরভাবে করেননি।

  • আপনার সর্বব্যাপী ভাষা নেই। ডোমেন মডেলের ভাষা এবং ধারণাগুলি ডোমেন বিশেষজ্ঞরা কী ব্যবহার করছেন তা অনুসরণ করে না।

দ্রষ্টব্য: ডিডিডি অপরিবর্তনীয় অবজেক্টগুলিকে ব্যবহার করে যেখানে উপযুক্ত, সেগুলিকে কেবল মান বস্তু বলা হয়।

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


পিটার, দুর্দান্ত উত্তর। আপনি কি আমার প্রশ্নটি এখানে stackoverflow.com/questions/13783666/… একবার দেখে নিতে পারেন এবং আমার সমস্যাটি বের করতে আমাকে সহায়তা করতে পারেন? আমি মনে করি অপরিবর্তনীয় মান বস্তুগুলি এমন সফ্টওয়্যারগুলির জন্য দুর্দান্ত যা এন্টারপ্রাইজ সম্পর্কিত নয় for বেশিরভাগ এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলির বস্তুগুলি আমার মতে পরিবর্তনযোগ্য। একটি অপরিবর্তনীয় গভীর-নেস্টেড মান অবজেক্ট থাকার কল্পনা করুন ... কন্টাক্টইনফো-> ফিজিক্যাল লোকেশন-> ঠিকানা এবং আপনি জিপকোড আপডেট করতে চান ... পুরো অবজেক্টের গ্রাফ তৈরি করা আমার কাছে খ্রিস্টবিরোধী মনে হয়, কেবল একটি অ্যান্টিপ্যাটার্ন নয়। আপনি কি মনে করেন?
পেপিতো ফার্নান্দেজ

3

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


0

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


-1

অপরিবর্তনীয় বস্তু ব্যবহারের অন্য উপায় আছে ...

৫.০, .0.০, .0.০, .0.০ মানগুলি সংরক্ষণ এবং প্রতিবার পুরো রেকর্ডটি অনুলিপি না করে আপনি এর পরিবর্তে এই জাতীয় কিছু সংরক্ষণ করতে পারেন: 5.0, +1.0, +1.0, +1.0, এবং তারপর ক্রম 5.0 পুনর্নির্মাণের জন্য সঠিকভাবে নির্ভরতা তৈরি করতে পারেন , 6.0, 7.0, 8.0। এইভাবে ছোট পরিবর্তনগুলি কেবল অল্প পরিমাণে মেমরি নেয় ...

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.