ফাংশনাল প্রোগ্রামিংয়ের প্রসঙ্গে রক্তাল্পতা মডেল সম্পর্কে কথা বলা কি এখনও বৈধ?

Question

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

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

আপডেট : সাম্প্রতিক বিষয় প্রকাশিত বই এবং ভিডিও ।

Comments

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

— রবার্ট হার্ভে

দৃ related়ভাবে সম্পর্কিত, যদি একেবারে ডুপ্লিকেট না হয়: কেন রক্তাল্পতার ডোমেন মডেলটিকে ওওপিতে খারাপ বিবেচনা করা হয় তবে এফপিতে খুব গুরুত্বপূর্ণ?

— রবার্ট হার্ভে

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

— প্ল্লেক্স

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

— জার্গ ডব্লু মিট্টাগ

@ জার্গডব্লিউমিত্যাগ: আপনি কি সাধারণ সংজ্ঞা ব্যতীত অন্যটি বোঝাতে চান? উদাহরণস্বরূপ প্রচুর প্ল্যাটফর্ম রয়েছে, হাস্কেল সর্বাধিক সুস্পষ্ট একটি।

— রবার্ট হার্ভে

Answer 1

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

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

এই সমস্যাটি সমাধান করা সাধারণত কয়েকটি পর্যায়ে ঘটে। একটি সাধারণ প্রথম কাটাটি বলতে হয় "আচ্ছা, UserIDএটিকে একটি স্ট্রিংয়ের সমতুল্য উপস্থাপন করা হয় তবে সেগুলি বিভিন্ন ধরণের এবং আপনি যেখানে অন্যটির প্রত্যাশা করেন সেখানে একটি ব্যবহার করতে পারবেন না।" হাস্কেল (এবং কিছু অন্যান্য টাইপযুক্ত কার্যকরী ভাষা) এর মাধ্যমে এই বৈশিষ্ট্যটি সরবরাহ করে newtype:

newtype UserID = UserID String

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

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

এমনকি আরও পদক্ষেপগুলি UserIDডেটা প্রকারটিকে এমনভাবে সংজ্ঞায়িত করে যে কেবলমাত্র সংজ্ঞা দ্বারা খণ্ডিত বা "অনুপযুক্ত" একটি তৈরি করা অসম্ভব । উদাহরণস্বরূপ, UserIDসংখ্যার তালিকা হিসাবে একটি সংজ্ঞা দেওয়া :

data Digit = Zero | One | Two | Three | Four | Five | Six | Seven | Eight | Nine
data UserID = UserID [Digit]

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

Comments

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

— পাভেল ভোরোনিন

সুন্দর বক্তৃতা, তবে ওপি প্রশ্নের কোনও উত্তর নেই।

— সার্জ

Answer 2

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

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

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

Comments

"বড় পরিমাণে অপরিবর্তনীয়তা ওওপি অ্যাডভোকেট হিসাবে আপনার ডেটাগুলির সাথে আপনার ফাংশনগুলি দৃ couple়ভাবে সংযোজন করা অপ্রয়োজনীয় করে তোলে data": সংযুক্ত ডেটা এবং পদ্ধতিগুলির আরেকটি কারণ হ'ল গতিশীল প্রেরণ যদিও পলিমারফিজম বাস্তবায়ন করে।

— জর্জিও

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

— পাভেল ভোরোনিন

Answer 3

ওওপি-তে ডিডিডি ব্যবহার করার সময়, ডোমেন অবজেক্টগুলিতে ব্যবসায়িক যুক্তি যুক্ত করার একটি প্রধান কারণ হ'ল ব্যবসায়ের যুক্তি সাধারণত বস্তুর অবস্থার পরিবর্তনের মাধ্যমে প্রয়োগ করা হয়। এটি এনক্যাপসুলেশন সম্পর্কিত: Employee.RaiseSalaryসম্ভবত উদাহরণের salaryক্ষেত্রটিকে পরিবর্তিত করে Employee, যা সর্বজনীনভাবে স্থিরযোগ্য হওয়া উচিত নয়।

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

এই ক্ষেত্রে, আচরণটি থেকে ডেটা পৃথক করা স্বাভাবিক হয়ে যায়: একটি কাঠামো Employeeডেটা হিসাবে সম্পূর্ণ প্রতিনিধিত্ব করে (সম্পূর্ণ রক্তাল্পতা), যখন একটি (বা বেশ কয়েকটি) মডিউলগুলিতে এমন ফাংশন থাকে যা সেই ডেটাতে চালিত হয় (অপরিবর্তনযোগ্যতা সংরক্ষণ করে)।

লক্ষ্য করুন যে আপনি যখন ডিডিডি হিসাবে দু'জন ডেটা এবং আচরণ করেন তখন আপনি সাধারণত একক দায়িত্বের নীতি (এসআরপি) লঙ্ঘন করেন: Employeeবেতন পরিবর্তনের নিয়মগুলি পরিবর্তিত হলে পরিবর্তনের প্রয়োজন হতে পারে; তবে EOY বোনাস পরিবর্তনের গণনা করার নিয়মগুলিও পরিবর্তনের প্রয়োজন হতে পারে। ডিকোপলড পদ্ধতির সাথে এটি ক্ষেত্রে হয় না, যেহেতু আপনার একাধিক মডিউল থাকতে পারে, যার প্রতিটিই একটি দায়িত্ব।

সুতরাং, যথারীতি এফপি পদ্ধতির অধিকতর পরিমিততা / সামঞ্জস্যতা সরবরাহ করে।

Answer 4

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

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

Comments

হ্যাঁ, ওপি তাঁর প্রশ্নে মূলত এটিই বলেছেন। আপনারা উভয়ই এমন বিন্দুটি হারিয়েছেন বলে মনে হয় যে আপনার এখনও কার্যকরী রচনা

— রবার্ট হার্ভে

Answer 5

আমি জানতে চাই ডিডিডি কীভাবে এফপি দৃষ্টান্তের সাথে ফিট করে

আমি মনে করি এটি হয় তবে মূলত অপরিবর্তনীয় মান বস্তুগুলির মধ্যে রূপান্তরিত করার কৌশল হিসাবে বা সত্তায় সত্তা পদ্ধতিতে ট্রিগার করার উপায় হিসাবে । (যেখানে এখনও বেশিরভাগ যুক্তি সত্তায় থাকে))

এবং সেই ক্ষেত্রে 'রক্তাল্প মডেল' শব্দটি এখনও বিদ্যমান কিনা।

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

মনে করুন তারা এক সাথে শৃঙ্খলাবদ্ধ প্রক্রিয়া এবং ফাংশন সম্পর্কে কথা বলে, তবে মনে হয় মূলত আপনার ডোমেন-অবজেক্টগুলি ফাংশনগুলি (বা কমপক্ষে "ডু-এআর" অবজেক্ট) হয় !

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

Comments

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

— রবার্ট হার্ভে

অতএব "ফাংশনগুলি" এর চারপাশে উদ্ধৃতিগুলি চিহ্নিত করে, যখন তারা অ্যানিমিক হয় তখন লেবেলটি কতটা অনুচিত হয় তার উপর জোর দেওয়া।

— দরিয়েন

আপনি যদি বিদ্রূপাত্মক হন তবে এটি কিছুটা সূক্ষ্ম।

— রবার্ট হার্ভে