ওওপি প্রযুক্তির মৃত্যু [বন্ধ]


9

আমি দিকনির্দেশক প্রোগ্রামিং সম্পর্কে অনেকবার শুনেছি, বেশিরভাগ ক্ষেত্রে এটি প্রোগ্রামিংয়ের "পরবর্তী প্রজন্ম" প্রযুক্তি এবং এটি 'কিল' ওওপি-তে চলছে।

এটা কি ঠিক? ওওপি মারা যাচ্ছে নাকি এর কারণ কী হতে পারে?

উত্তর:


40

যে কোনও সময় যখন কেউ আপনাকে বলে যে একটি সফ্টওয়্যার প্রযুক্তি অন্য একজনকে হত্যা করবে বা পুরো বাজার / ব্যবহার / দর্শকদের উপর প্রভাব ফেলবে, এটি মনে রাখবেন:

একটি বুদ্ধিমান (গতিশীল তবে স্থিতিশীল) বাস্তুতন্ত্র বিভিন্ন ধরণের বিভিন্ন প্রজাতির তৈরি।

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

হাইপ কার্ভ

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

তবে এর ইতিমধ্যে এটির জায়গা রয়েছে যেমন ওওপোগ্র্যামিংয়ের মতো জেনেরিক প্রোগ্রামিংয়ের মতো, কার্যকরী প্রোগ্রামিংয়ের মতো, পদ্ধতিগত প্রোগ্রামিং ইত্যাদি etc.

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


1
'খাঁটি নয়' এর জন্য +1। খাঁটি ওওপি ভাষাগুলি বিশেষভাবে মারা গেছে, খুব কুলুঙ্গি ব্যবহার / শিক্ষাবিদ ছাড়া।
jv42

আমরা একটি খাঁটি ওও ভাষা কী বিবেচনা করব? স্বল্প কথা?
heেহাও মাও

20

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


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

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

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

6
টেকের প্রথম উদাহরণগুলি আমি খুঁজে পেতে পারি, এটি কীভাবে ওও নয়? টিউটোরিয়াল থেকে: "উইজেটগুলি হ'ল অবজেক্টস, ক্লাসগুলির উদাহরণ যা বোতাম, ফ্রেম ইত্যাদি উপস্থাপন করে।" tkdocs.com / টিউটোরিয়াল / কনসেপ্টস html আরও বেশি, ডিএসএলগুলি ওও প্রোগ্রামিংয়ের উপর খুব নির্ভরশীল। সুতরাং আমি সত্যিই বুঝতে পারছি না আপনি কী বলতে চাইছেন?
ইনকা

3
@ এসসি-লজিক, @ এ্যাম্মিউকিউ, @ রায়নস, @ জোককিং, আমি এটিকে এর নিজস্ব একটি প্রশ্নে প্রচার করেছি: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জাওয়েজ / সেকশনস / ৮৮৮৮৫/২ এই বিষয়ে আরও ব্যাখ্যা করতে আমি খুব আগ্রহী হব, আমি খুব শিখতে আগ্রহী।
ইনকা

12

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


6
সত্যই উজ্জ্বল বাক্যাংশের জন্য +1: "দৃষ্টান্তগুলি আসে এবং যায় তবে লিগ্যাসি কোড চিরতরে থাকে"
NoChance

8

সংক্ষিপ্ত উত্তর: না, আমি এটি মনে করি না।

দীর্ঘ উত্তর: আমি এওপি-র যা বুঝতে পেরেছি তা থেকে এটি নিজের মধ্যে প্রোগ্রামিং দৃষ্টান্ত নয় (যেমন এটি ওওপি প্রতিস্থাপন করে না), তবে আরও একটি সংযোজন, এমন একটি টুলকিট যা আপনাকে ছোট পদ্ধতিগুলি, সহজ, একক-দায়বদ্ধ ক্লাস লিখতে সহায়তা করে , ইত্যাদি। তবে এটি ওওপি প্রতিস্থাপন করে না।

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


কার্যক্ষম <-> অপরিহার্য লাইন is ওওপি এর সমান্তরাল। আমি মনে করি OOP এর অন্য প্রান্তে প্রক্রিয়াগত রয়েছে তবে আমি নিশ্চিত নই। অবশ্যই এটি মজাদার যে ফাংশনাল দৃষ্টান্তটি
ওওপি-র

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

6

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

http://imgur.com/9VmKC


5

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


1

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

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

ব্যবহারকারী-সংজ্ঞায়িত ফিল্টারগুলিকে কল করার জন্য ট্রাম্পোলিন পদ্ধতিতে রুট করতে স্থির পদ্ধতি কলগুলি পুনরায় লেখার তুলনায় এটি রক্তাক্ত শক্ত।

সুতরাং সাধারণ প্রয়োগের দৃষ্টিকোণ থেকে, এওপি-র জন্য ওওপি প্রয়োজন।


0

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

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

http://martinfowler.com/bliki/AnemicDomainModel.html

(আমি জানি উপরের নিবন্ধটি পুরানো, তবে আশ্চর্যের সাথে প্রাসঙ্গিক)

মূল কথাটি হ'ল এওপি সিস্টেমগুলি এখানে থাকার জন্য রয়েছে তবে এগুলি যথাযথ থেকেও দূরে। কোন সিস্টেম নিখুঁত।

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