অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং কি জটিলতার সমাধান? [বন্ধ]


18

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


15
কঠিন রচনা নিয়োগ? ; পি
গ্লেনাট্রন

1
জটিলতার কোনও সমাধান না হওয়ায় প্রশ্নটি বোঝা যায় না। জটিলতা মোকাবেলার জন্য কৌশল রয়েছে (বিশেষত, অভ্যন্তরীণ, অদম্য জটিলতা)। কিন্তু সমাধান, নেই। এটি একটি শারীরিক মাইল দূরত্ব শূন্যে আনার সমাধান সন্ধান করার মতো।
luis.espinal

1
অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং জটিলতা পরিচালনার জন্য একটি সরঞ্জাম।
রবার্ট হার্ভে

প্রশ্ন: আপনি ওওপি নিয়ে জটিল সমস্যা প্রোগ্রাম করতে পারেন? - উত্তর: অবশ্যই আপনি যদি ওওপি ব্যবহার করেন তবে এটি জটিল হবে।
mouviciel

"এটা বিতর্কিত হতে পারে" এটা এক আলোচনা আইটেম, বরং একটি প্রযুক্তিগত প্রশ্ন ... করে তোলে
jwenting

উত্তর:


24

জটিলতার কোনও সমাধান নেই।

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

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

অতএব, তিনি দাবি করেছিলেন যে কোনও রূপালী বুলেট থাকবে না, লেখার সফটওয়্যারটি কঠিন হতে থাকবে।

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

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


3
20 তম বার্ষিকী সংস্করণে "'নো সিলভার বুলেট' রিফায়ার্ড" রয়েছে, এতে তিনি ওওপিটিকে "ব্রাস বুলেট" হিসাবে উল্লেখ করেছেন এবং বলেছেন এটি: "... একটি খুব আশাব্যঞ্জক ধারণা"।
জেরি কফিন

18

আমি আশা করি আপনি শীঘ্রই আরও কিছু ভাল উত্তর পাবেন, তবে এখানে একটি সহজ উত্তর:

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

* কারণ কিছুই জটিলতা 'সমাধান' করতে পারে না


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

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

2
না, এটি ওওপি সম্পর্কে একটি সাধারণ ভুল ধারণা। আপনার বাস্তব জীবনের বস্তুর উপর ভিত্তি করে আপনার প্রোগ্রামটি মডেল করার কথা নয়। রিয়েল লাইফে বাফাররিডার বলে কিছু নেই।
হাসেন

1
@ হাসেন জে: হ্যাঁ, আমি যখন আমার মন্তব্যে স্পষ্ট করেছিলাম তখন এটাই বলেছিলাম।
ফিশটোস্টারে


15

আমি মনে করি ওওপি-র বর্তমান মূলধারার সংজ্ঞা জটিলতা পরিচালনার জন্য ভাল সমাধান নয়।

যদি আপনি এর শিকড়গুলিতে ফিরে যান তবে আমি বিশ্বাস করি অ্যালান কে "লিস্প" দ্বারা প্রচুর পরিমাণে প্রভাবিত হয়েছিল।

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

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

আমি মনে করি OOP মূলত বিমূর্ততাগুলির এই স্তরগুলি তৈরি করার প্রক্রিয়া হিসাবে তৈরি হয়েছিল।

দুর্ভাগ্যক্রমে আজকাল, ওওপি স্প্যাগেটি কোড / কাঠামো লিখতে ব্যবহৃত হয় (আব)।

আমি একটি উদাহরণ করব: একটি এফপিএস মাল্টি প্লেয়ার গেম।

সর্বোচ্চ স্তরে, খেলাটি মানচিত্রের চারপাশে দৌড়াদৌড়ি করে এবং অস্ত্র ব্যবহার করে একে অপরের দিকে গুলি চালিয়ে কাজ করে।

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

পরবর্তী নিম্ন স্তরে, আমরা কীভাবে বস্তুগুলি শারীরিকভাবে যোগাযোগ করে (চলন, সংঘর্ষ ইত্যাদি) সম্পর্কে কথা বলতে পারি।

এবং তাই এবং তাই ঘোষণা.

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

সুতরাং, ওওপি ব্যবহারের বুদ্ধিমান উপায় হ'ল বিমূর্ততার স্তর তৈরি করা, বিমূর্ততার প্রতিটি স্তরে, আপনি সরাসরি নীচের স্তর থেকে "অবজেক্ট" ব্যবহার করে সমস্যাটি সমাধান করবেন।

আমি এই বক্তৃতাটি থেকে কিছুটা উদ্ধৃত করেছিলাম: http://www.youtube.com/watch?v=CYtrfncMqHQ


5
অনেক সরঞ্জামের মতো, ওওপি অত্যন্ত কার্যকর যখন এটি বুদ্ধিমানের সাথে এবং বিবেচ্যভাবে ব্যবহৃত হয় এবং যখন এটি অপব্যবহার করা হয় তখন তেমন কার্যকর হয় না।
রবার্ট হার্ভে

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

1
আমি ধারণাটি পেয়েছি যে একটি তাত্ত্বিক ধারণা "মূলধারার গ্রহণ দ্বারা দূষিত না হওয়া" সত্যিকারের প্রকল্পে জটিলতা পরিচালনার ক্ষেত্রে এটি আরও উন্নত করে তুলবে ... উদ্ভট।
মাইকেল বর্গওয়ার্ট

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

@hasen J: OTOH এটা সঙ্গতিপূর্ণভাবেই এর আরো সম্ভবত যে "মূল ধারণা" যে দেখেছি মূলধারার গ্রহণ হাতির দাঁত টাওয়ার কাপড় যে বাস্তব জগতে কাজ করে না ছিল। জনপ্রিয়তার অভাব অবশ্যই কোনও কিছুর পক্ষে সুস্পষ্ট বিষয় নয়।
মাইকেল বর্গওয়ার্ট

10

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

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

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

আমি এই কাজটিকে ভাল বিজ্ঞান হিসাবে বিবেচনা করি কারণ মায়ার প্রদর্শনযোগ্যভাবে ভুল ছিল এবং তার কাজের গুণমানের কারণে ত্রুটিটি নির্দেশ করে এটি সমাধান করা সম্ভব হয়েছে।

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

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

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

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

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

এটি আশ্চর্যজনকভাবে উত্তরাধিকারসূত্রে C ++ স্ট্যান্ডার্ড টেম্পলেট লাইব্রেরিতে খুব কমই ব্যবহৃত হয়।

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


আপনাকে আরও কিছুটা উত্সাহিত করার জন্য অন্য অ্যাকাউন্ট তৈরি করার প্রলোভন দেখিয়েছে;)
মার্কো মারিয়ানী

আপনি অনেকগুলি জোর দিয়েছিলেন। সম্ভবত আপনি আপনার দাবিগুলি ব্যাক আপ বা যুক্তিগুলির রেফারেন্স সরবরাহ করতে পারেন। এটির মতো, যা আপনার বিভিন্ন থিসগুলিকে পুরোপুরি সমর্থন করে না (এটির অর্থ এই বলে যে " ওওর
ফ্র্যাঙ্ক শেয়ারার

3
"Foo সর্বাধিক কুফল এবং খারাপ জিনিস ..." বলা সক্রিয়ভাবে যে কোনও যুক্তি, আপনি যেভাবে চেষ্টা করার চেষ্টা করতে পারেন তার পক্ষে সক্রিয়ভাবে ক্ষয়কারী।
ফ্রাঙ্ক শিয়ার

6

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

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

http://en.wikipedia.org/wiki/Object-oriented_programming

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


2

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

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

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

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


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

2

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং প্রয়োজনীয় এবং andচ্ছিক জটিলতা পরিচালনা করে তবে তা হ্রাস করে না।

আমি আর্ট অফ ইউনিক্স প্রোগ্রামিং- এ এরিক স্টিভেন রেমন্ডের প্রদত্ত সংজ্ঞাটি পছন্দ করি , কারণ এটি প্রয়োজনীয়, alচ্ছিক এবং দুর্ঘটনাজনিত জটিলতার মধ্যে চিত্রিত করে। http://www.faqs.org/docs/artu/ch13s01.html#id2964646

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


2

জটিল সমস্যাগুলি প্রযুক্তির মাধ্যমে সহজতর রেন্ডার করা যায় না, কেবলমাত্র প্রযুক্তির মাধ্যমে সেগুলি পরিচালনা করা যায়।

ওওপি হ'ল প্রযুক্তি, একটি ধারণা এবং সমস্যার কাছে যাওয়ার উপায়।

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

মনে রাখবেন যে আরও অনেক দিক রয়েছে যা আপনার প্রকল্পটি কতটা সফল হবে তা নির্দেশ করবে (যেমন প্রকল্প পরিচালনার স্টাইল, সমস্যার সংজ্ঞা, পরিবর্তন পরিচালন ইত্যাদি ...)। আপনি যে প্রযুক্তি ব্যবহার করেন এটি কেবল প্রাসঙ্গিক যে এটি আপনাকে সমস্যা পরিচালনা করতে কতটা সহায়তা করবে help

শেষ অবধি , অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং জটিলতার সমাধান হতে পারে না ; এটি পরিচালনা করার জন্য এটি কেবল একটি সরঞ্জাম। (যদি সঠিকভাবে ব্যবহার করা হয়)


+1 শেষ অবধি, অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং জটিলতার সমাধান হতে পারে না; এটি পরিচালনা করার জন্য এটি কেবল একটি সরঞ্জাম। (যদি সঠিকভাবে ব্যবহার করা হয়)
কার্তিক শ্রীনিবাসন

2

অবজেক্ট ওরিয়েন্টেশন (প্রচলিত ব্যবহৃত হিসাবে) অনেক পরিস্থিতিতে একটি দরকারী সরঞ্জাম, তবে এটি জটিলতার যথেষ্ট সমাধান নয়।

বিশেষত, এটি প্রায়শই প্রচুর পরিমাণে " ঘটনামূলক জটিলতা " যুক্ত করে। উদাহরণগুলি হ'ল বাস্তবায়ন উত্তরাধিকারের চারপাশের জটিলতা, সমান () এবং হ্যাশকোড () ইত্যাদি হিসাবে প্রচুর "স্ট্যান্ডার্ড কার্যকারিতা" সুচ সরবরাহের প্রয়োজন this এই বিষয়ে স্টুয়ার্ট হ্যালোয়ের একটি চমৎকার উপস্থাপনা: " সরলতা সহজ নয় "

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


1

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

সি ++ সম্পর্কে যেমন বলা হয়েছে, ওওপি আপনাকে নিজেকে ফাঁসানোর জন্য যথেষ্ট দড়ি দেয়।


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

@ মিশেল, অন্যদের চেয়ে কিছু বেশি। তবে মূলত, হ্যাঁ কোনও রূপালী বুলেট নেই, আপনি যে কোনও ভাষা বা দৃষ্টান্ত ব্যবহার করছেন তা সর্বদা পিছনে থাকে।
ডোমিনিক ম্যাকডোনেল

1

আমি মনে করি হ্যাঁ , শুধু কারণ এটি ছোট স্ব-ধারণকারী "বিল্ডিং ব্লক" যে বিবরণ লুকান মধ্যে ছে জটিলতা আপনি করতে পারবেন, এবং তারপর লেয়ার দ্বারা কার্যকারিতা আপনার যা দরকার, ধাপে ধাপে, স্তর তৈরি করতে তাদেরকে ব্যবহার করো।

ভাগ এবং বিজয়।


1

ওওপি একটি সমাধানের চেষ্টা।

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

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

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

শেষ ফলাফলটি হ'ল আপনার প্রয়োজনের চেয়ে অনেক জটিলতা নিয়ে।

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

যতক্ষণ না আপনি অন্য কারো দ্বারা লিখিত কিছু বজায় রাখতে হয়।

হ্যাঁ, এটি জেনে রাখা ভাল যে সমস্ত ডেটা অ্যাক্সেস ফাংশন এখানে অবস্থিত। তবে এগুলি কী বলে?

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

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

এর জন্য একটি শব্দ রয়েছে: স্প্যাগেটি কোড।

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

এই জটিলতা পরিচালনা করছেন?

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

সংক্ষেপে: ওওপি জটিলতা পরিচালনা করতে সহায়তাকারী সরঞ্জামের মতো দেখতে দেয়। বাস্তবতাটি হ'ল ফলস্বরূপ কোডটি মারাত্মকভাবে ফুলে যায় (কারণ আপনি linked লিঙ্কযুক্ত সমস্ত লাইব্রেরি থেকে আপনার প্রয়োজনীয় টুকরোগুলিই বের করতে পারবেন না) এবং কোডটি নেভিগেট করার জন্য আপনার অত্যাধুনিক সরঞ্জামের প্রয়োজন। এটি দ্রুত একটি রক্ষণাবেক্ষণ দুঃস্বপ্ন হয়ে ওঠে।

আইএমএইচও, এটি নেট ক্ষতি; এটি এটি নির্বিঘ্ন করার চেয়ে আরও জটিলতা যুক্ত করে। এটি আপনাকে এমন জিনিসগুলি করার অনুমতি দেয় যা এগুলি ব্যতীত অত্যন্ত কঠিন, সম্ভবত এমনকি অসম্ভব। তবে যে কোনও বৃহত প্রকল্প দ্রুত অবিস্মরণীয় জগাখিচায় পরিণত হয়।

এটি কীভাবে কাজ করে তা আপনি ইতিমধ্যে যদি জানেন এবং আপনি এটি মনে রাখতে পারেন তবে এটি বজায় রাখার জন্য আপনি একটি সুযোগে দাঁড়াতে পারেন।

Agগলসন আইন প্রয়োগ করতে ভুলবেন না: আপনার নিজস্ব কোড, যা আপনি ছয় মাসে দেখেন নি, সেগুলিও অন্য কেউ লিখে থাকতে পারে।


0

কিছু মাত্রায়...

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


0

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

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

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


1
মন্তব্য সরানো; তাদের নাগরিক রাখার চেষ্টা করুন
ফিশটোস্টারে

0

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

হ্যাঁ, আপনার কোডটি প্রাকৃতিক উপায়ে আপনার "কোড" দেখার জন্য একটি মডেল সরবরাহ করে জটিলতার সমাধানও হ'ল বৈশিষ্ট্য এবং সম্ভাব্য ক্রিয়া রয়েছে এমন বস্তু হিসাবে

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