"ফাংশন এবং ডেটার মধ্যে শক্ত সংযোগ" কেন খারাপ?


38

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

[এ] অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের ডাউনসাইড হ'ল ফাংশন এবং ডেটার মধ্যকার আঁটসাঁটো মিলন।

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

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

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

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

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

পিএস এই উক্তিটি এমন একটি বইয়ের উল্লেখ করেছে যা আমি পড়িনি: লেদাতে মাল্টিপ্রেডিজম প্রোগ্রামিং: টিমোথি বুড, 1995


20
আমি বিশ্বাস করি যে লেখক কেবল ওওপি সঠিকভাবে বুঝতে পারেন নি এবং জাভা খারাপ এবং ক্লোজার ভাল বলে দেওয়ার জন্য আরও একটি কারণ প্রয়োজন। / রেন্ট
ইউফোরিক

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

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

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

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

উত্তর:


34

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

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

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

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


13

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

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

এটি ওও এর খারাপ দিক - এটি ক্লোরার্স স্ট্যান্ডার্ড ( প্রোগ্রামিংয়ের একটি ভাঙা উইন্ডো তত্ত্বের একধরণের) তৈরি করে এই ধরণের দুষ্টতা, ডেটা সংযুক্তকরণকে কাজ করার জন্য উত্সাহ দেয় ।

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


8
দিনের উদ্ধৃতি: "কিছু কাজ প্রায়শই কিছু করা প্রয়োজন"
গ্লেনপিটারসন

5
আপনি সত্যিই ব্যাখ্যা করেন নি কেন জিনিষ আপনি মন্দ কল মন্দ হয়; আপনি কেবল তাদের দুষ্ট বলছেন। তারা কেন খারাপ, ব্যাখ্যা করুন এবং ভদ্রলোকের প্রশ্নের উত্তর আপনার কাছে থাকতে পারে।
রবার্ট হার্ভে

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

যদি ওও এবং ক্লোজারগুলি সমার্থক হয়, তবে কেন এতগুলি ওও ভাষাগুলি তাদের জন্য সুস্পষ্ট সমর্থন সরবরাহ করতে ব্যর্থ হয়েছে? আপনি যে সি 2 উইকি পৃষ্ঠাটি উদ্ধৃত করেছেন সে সাইটের স্বাভাবিকের চেয়ে আরও বিতর্ক (এবং কম sensকমত্য) রয়েছে।
itbruce

1
@itsbruce এগুলিকে মূলত অপ্রয়োজনীয় করা হয়েছে। পরিবর্তে "বন্ধ হয়ে যাবে" ভেরিয়েবলগুলি বস্তুর মধ্যে শ্রেণি ভেরিয়েবলগুলি পাস হয়ে যাবে।
ইজকাটা

7

এটি টাইপ কাপলিং সম্পর্কে :

এই অবজেক্টটিতে কাজ করার জন্য কোনও অবজেক্টের মধ্যে নির্মিত একটি ফাংশন অন্য ধরণের অবজেক্টগুলিতে ব্যবহার করা যায় না।

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

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


3
ইন্টারফেসের পুরো পয়েন্টটি কি তাই নয়? টাইপ বি এবং টাইপ সিগুলিকে আপনার ফাংশনটির সাথে একই রকম দেখতে দেয় এমন জিনিসগুলি সরবরাহ করতে, যাতে এটি একাধিক প্রকারের উপর কাজ করতে পারে?
র্যান্ডম 832

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

আপনার এখনও ইন্টারফেস প্রয়োগ করতে হবে।
র্যান্ডম 832

2
@ র্যান্ডম 832 ইন্টারফেসগুলি ডেটা ধরণের; তাদের মধ্যে আবদ্ধ কোন ফাংশন প্রয়োজন। নিখরচায় ফাংশন সহ, সমস্ত ইন্টারফেসগুলি এক্সটোল করার দরকার যা হ'ল তারা কোন ডেটা বিপরীতে কাজ করার জন্য উপলব্ধ করে।
জিমি হোফা

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

4

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

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


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

1
@ জার্গডব্লিউমিত্যাগ আমি মনে করি আপনি বীজগণিতের ডেটাটাইপগুলি বোঝাতে চেয়েছিলেন। এবং কোডসইনচাউস, হাস্কেল আপনার পরামর্শটি খুব স্পষ্টভাবে নিরুৎসাহিত করে। একে এতিম উদাহরণ বলা হয় এবং জিএইচসি-তে সতর্কতা জারি করে।
jozefg

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

2
@ কোডসইনচোস তারপরে সম্ভবত এটি "স্ট্যাটিক ক্লাস ভিত্তিক ওও" হিসাবে ব্যাখ্যা করেছেন
jozefg

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

3

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

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

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

কোনও অবজেক্টের বাইরে থেকে, আপনার উচিত নয়, আপনি এর ডেটার উপস্থাপনাটি জানতে পারবেন না । এটা বিপরীত আঁট কাপলিং করুন।


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

আপনার উদাহরণস্বরূপ, একটি ক্লাসে অ্যাক্সেসর ফাংশনগুলির সাথে আপনার ডেটা আবদ্ধ করা (এবং এইভাবে সেই তথ্যগুলিতে সেই ফাংশনগুলি দৃ tight়ভাবে সংমিশ্রণ করা) আসলে আপনাকে আপনার প্রোগ্রামের বাকী অংশের সাথে সেই শ্রেণীর কয়েকটি .িলে .ালা উদাহরণ দেয়। আপনি উদ্ধৃতিটির কেন্দ্রীয় পয়েন্টটি খণ্ডন করছেন - খুব সুন্দর!
গ্লেনপিটারসন

2

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

আপনি চাইছেন যে ফাংশনটিতে কোনও পরিবর্তন প্রয়োজন হবে না সেই জন্য ফাংশনে উপস্থাপিত বিভিন্ন ডেটা এবং একইভাবে আপনি এই ফাংশন পরিবর্তনের সমর্থনে যে সমস্ত ডেটা অপারেটিং করছে তাতে কোনও পরিবর্তন প্রয়োজন না করে ফাংশনে পরিবর্তন করতে সক্ষম হতে চান।


1
হ্যাঁ, আমি এটি চাই তবে আমার অভিজ্ঞতাটি হ'ল যখন আপনি কোনও তুচ্ছ ফাংশনে ডেটা প্রেরণ করেন যা এটি স্পষ্টভাবে হ্যান্ডেল করার জন্য ডিজাইন করা হয়নি, তখন সেই ফাংশনটি ভেঙে যায়। আমি কেবল সুরক্ষা প্রকারের উল্লেখ করছি না, বরং কোনও ডাটা শর্ত যা ফাংশনের লেখক (গুলি) দ্বারা প্রত্যাশিত ছিল না। যদি ফাংশনটি পুরানো হয় এবং প্রায়শই ব্যবহৃত হয় তবে যে কোনও পরিবর্তন যা নতুন ডেটা এর মধ্য দিয়ে প্রবাহিত করতে দেয় তা সম্ভবত এটি কিছু পুরানো ফর্মের জন্য ভাঙতে পারে যা এখনও কাজ করা দরকার। ডেউউপলিং ফাংশন বনাম ডেটার জন্য আদর্শ হতে পারে তবে সেই ডিকোপলিংয়ের বাস্তবতা কঠিন এবং বিপজ্জনক হতে পারে।
গ্লেনপিটারসন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.