কেন অ্যানিমিক ডোমেন মডেলকে সি # / ওওপিতে খারাপ বিবেচনা করা হয় তবে এফ # / এফপিতে খুব গুরুত্বপূর্ণ?


46

মজা এবং লাভের জন্য এফ # তে একটি ব্লগ পোস্টে এটি বলে:

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

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

প্রকৃতপক্ষে, ওওডিতে, ডেটা টাইপের চারপাশে পর্যাপ্ত আচরণ না করা খারাপ বিষয় হিসাবে বিবেচিত হয় এবং এর একটি নামও রয়েছে: " রক্তাল্পতাযুক্ত ডোমেন মডেল "।

সি # তে প্রদত্ত বলে মনে হচ্ছে যে আমরা এফ # এর কাছ থেকে ধার নিয়ে চলেছি, এবং আরও কার্যকরী-শৈলীর কোড লেখার চেষ্টা করছি; কীভাবে আমরা ডেটা / আচরণ আলাদা করার ধারণা ধার নিচ্ছি না, এবং এটি খারাপ বিবেচনা করব? এটি কি কেবলমাত্র সংজ্ঞাটি ওওপি-র সাথে হয় না, বা কোনও দৃ in় কারণ রয়েছে যে এটি সি # তে খারাপ যে কোনও কারণে এফ # তে প্রয়োগ হয় না (এবং বাস্তবে বিপরীত হয়)?

(দ্রষ্টব্য: আমি সি # / এফ # এর পার্থক্যে বিশেষত আগ্রহী যেগুলি ভাল / খারাপের মতামতকে বদলে দিতে পারে, বরং এমন ব্যক্তিদের তুলনায় যা ব্লগ পোস্টে মতামতের সাথে একমত হতে পারে না)।


1
হাই ড্যান! আপনার অভ্যাস অনুপ্রেরণামূলক। .NET (এবং হ্যাশেল) প্ল্যাটফর্মের পাশাপাশি আমি আপনাকে স্কালার দিকে নজর দিতে উত্সাহিত করি। দেবাশীষ ঘোষ লিখেছেন কার্মিক সরঞ্জামগুলির সাথে ডোমেইন মডেলিং ব্লগ দুয়েক, এটা আপনার জন্য আমার জন্য অন্তর্দৃষ্টিপূর্ণ ছিল খুব আশা করছি, এখানে আপনি যান: debasishg.blogspot.com/2012/01/...
AndreasScheinert

2
আমাকে আজ একটি সহকর্মী দ্বারা একটি আকর্ষণীয় ব্লগ পোস্ট প্রেরণ করা হয়েছিল: blog.inf.ed.ac.uk/sapm/2014/02/04/… দেখে মনে হয় যে রক্তাল্পতা ডোমেন মডেলগুলি সম্পূর্ণ খারাপ যে ধারণাটি মানুষ চ্যালেঞ্জ করতে শুরু করেছে; যা আমি মনে করি একটি ভাল জিনিস হতে পারে!
ড্যানি টুপেনি

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

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

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

উত্তর:


37

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

সি # ওওপিতে দায়িত্বের প্রতিনিধিদের ধারণা রয়েছে যেখানে আপনি কোনও বস্তুর পরিচালনা এটিতে অর্পণ করেন এবং তাই আপনি এটির নিজস্ব অভ্যন্তর পরিবর্তন করতে চান।

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

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

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

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


মতামতগুলিতে ইশারা করা হিসাবে , টাইপ অনুমিতি হ'ল ফায়ারগুলির মধ্যে অন্যতম একটি এই জাতীয় উল্লেখযোগ্য পলিমারফিজমকে নির্ভর করে এবং বিশেষত আপনি এটি আলগোরিদম ডাব্লু টাইপের অনুক্রমের সাহায্যে হিন্দি মিলনার টাইপ সিস্টেমে খুঁজে পেতে পারেন; সি # OOP টাইপ সিস্টেমে এ জাতীয় প্রকারের অনুমান এড়ানো হয়েছিল কারণ সংকীর্ণ-ভিত্তিক অনুমিত যোগ করার সময় সংকলন সময় প্রয়োজনীয় তাত্পর্যপূর্ণ অনুসন্ধানের কারণে অত্যন্ত দীর্ঘ হয়ে যায়, বিশদগুলি এখানে: https://stackoverflow.com/questions/3968834/generics- কেন -cant-কম্পাইলার-আভাসিত করা--টাইপ-আর্গুমেন্ট-ইন-এই-কেস


এফ # তে কোন বৈশিষ্ট্য (গুলি) পুনরায় ব্যবহারযোগ্য কোডটি এই ধরণের লেখা সহজ করে? সি # তে কোড কেন পুনরায় ব্যবহারযোগ্য হতে পারে না? (আমি মনে করি যে পদ্ধতিগুলি ইন্টারফেসের প্রয়োজন ছাড়াই নির্দিষ্ট বৈশিষ্ট্যগুলির সাথে যুক্তি গ্রহণের ক্ষমতা দেখেছি; যা আমি অনুমান করি যে এটি কী হবে?)
ড্যানি টুপেনি

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

@ ম্যাটফেনউইক আমি এতে সি # তে স্পষ্টভাবে উল্লেখ করছি কারণ পোস্টারটি সেটাই জিজ্ঞাসা করছিল। আমি আমার উত্তর জুড়ে যেখানে ওওপি উল্লেখ করি আমি এখানে সি # ওওপি বোঝাচ্ছি, আমি পরিষ্কার করতে সম্পাদনা করব।
জিমি হোফা

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

4
@ কিথস হাস্কেলের মান ভিত্তিক ওভারলোডিং দ্বারা আমার মনে হয় আপনি প্যাটার্ন ম্যাচিংয়ের অর্থ। হ্যাশেলের বিভিন্ন প্যাটার্ন দেশুসার সাথে একই নামের একাধিক শীর্ষ স্তরের ক্রিয়াকলাপ তত্ক্ষণাত 1 টপলেভেল ফাংশন + একটি প্যাটার্ন ম্যাচ করার ক্ষমতা।
jozefg

6

কেন অ্যানিমিক ডোমেন মডেলকে সি # / ওওপিতে খারাপ বিবেচনা করা হয় তবে এফ # / এফপিতে খুব গুরুত্বপূর্ণ?

আপনার প্রশ্নের একটি বড় সমস্যা রয়েছে যা আপনি পেয়েছেন এমন উত্তরগুলির ইউটিলিটি সীমাবদ্ধ করবে: আপনি বোঝাচ্ছেন / ধরে নিচ্ছেন যে এফ # এবং এফপি একই রকম। এফপি প্রতীকী শব্দ পুনর্লিখন, গতিশীল এবং স্ট্যাটিক সহ ভাষার একটি বিশাল পরিবার। এমনকি স্ট্যাটিক্যালি টাইপযুক্ত এফপি ভাষার মধ্যেও ওসিএএমএল এবং এসএমএলে উচ্চ-অর্ডার মডিউলগুলির মতো ডোমেন মডেলগুলি প্রকাশ করার জন্য বিভিন্ন প্রযুক্তি রয়েছে (যা এফ # তে নেই) don't এফ # হ'ল এই কার্যকরী ভাষাগুলির মধ্যে একটি তবে এটি বিশেষত পাতলা হওয়ার জন্য বিশেষভাবে উল্লেখযোগ্য এবং বিশেষত উচ্চতর অর্ডার মডিউল বা উচ্চতর ধরনের নয় provide

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

কীভাবে আমরা ডেটা / আচরণ আলাদা করার ধারণা ধার নিচ্ছি না, এবং এটি খারাপ বিবেচনা করব?

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

এটি কি কেবল এই যে সংজ্ঞাটি ওওপির সাথে খাপ খায় না,

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

পরীক্ষা করে দেখুন উদাহরণ আমি এখানে দিলাম

বা কোনও দৃ concrete় কারণ রয়েছে যে এটি সি # তে খারাপ যে কোনও কারণে এফ # তে প্রয়োগ হয় না (এবং বাস্তবে বিপরীত)?

ওওপি থেকে সি # এ ঝাঁপ দেওয়ার বিষয়ে সতর্ক থাকুন। সি # অন্যান্য ভাষার মতো ওওপি সম্পর্কে পবিত্রতার কাছাকাছি আর নেই। .NET ফ্রেমওয়ার্ক এখন জেনেরিকস, স্ট্যাটিক পদ্ধতি এবং এমনকি ল্যাম্বডাসে পূর্ণ।

(দ্রষ্টব্য: আমি সি # / এফ # এর পার্থক্যে বিশেষত আগ্রহী যেগুলি ভাল / খারাপের মতামতকে বদলে দিতে পারে, বরং এমন ব্যক্তিদের তুলনায় যা ব্লগ পোস্টে মতামতের সাথে একমত হতে পারে না)।

সি # তে ইউনিয়নের ধরণ এবং প্যাটার্নের মিলের অভাব এটি করা প্রায় অসম্ভব করে তোলে। আপনার সমস্ত কিছু যখন হাতুড়ি হয়ে যায়, তখন সমস্ত কিছুই পেরেকের মতো লাগে ...


2
... আপনার সমস্ত কিছু যখন হাতুড়ি হয়ে যায়, OOP লোকেরা হাতুড়ি কারখানা তৈরি করে; ডাব্লুটি এবং আচরণকে অন্যের থেকে পুরোপুরি বিমূ allow় হতে দেয়ায় সি # এর অনুপস্থিতিকে সত্যিকার অর্থে পিন করার জন্য পি + 1: ইউনিয়নের ধরণ এবং প্যাটার্নের মিল।
জিমি হোফা

-4

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


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