ওওপি কি সহজ বা শক্ত হয়ে উঠছে? [বন্ধ]


36

বছর পূর্বে যখন প্রোগ্রামারদের কাছে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের ধারণাগুলি প্রবর্তিত হয়েছিল তখন এটি আকর্ষণীয় বলে মনে হয় এবং প্রোগ্রামিংটি পরিষ্কার ছিল। ওওপি এর মত ছিল

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

স্ব-বর্ণনামূলক নাম দিয়ে এটি বোঝা সহজ ছিল।

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

দ্রষ্টব্য: আমি সেরা অনুশীলনের বিরুদ্ধে নই যা সহযোগিতা, পরীক্ষা এবং একীকরণকে সহজ করে তোলে


23
একটি ভাল সফ্টওয়্যার আর্কিটেকচার তৈরি করা সর্বদা কঠোর এবং সম্ভবত (সম্ভবত) সর্বদা থাকবে।
জোহনেস

6
আমি এর addItemজন্য addএবং এর removeItemজন্য নাম পরিবর্তন করব remove। কারণ এটি পড়া সহজ। stock.add(item)বা stock.remove(item)। এবং আরও OOP ওরিয়েন্টেড।
রাজ্জেটিয়া

1
আসল OOP আপনার দেখানো মত প্রায় কিছুই লাগেনি। ওওপি সিনট্যাক্স সম্পর্কে নয় , এটি এক প্রকার বিমূর্ততা সম্পর্কে যা স্মলটালক জনপ্রিয়। এটি অগত্যা আপনার বক্তব্য ভুল প্রমাণ করে না, বা ত্রুটিযুক্ত ত্রুটিও নয়; বরং, আপনি বুঝতে চেয়ে এটি আরও সত্য।
কনরাড রুডলফ

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

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

উত্তর:


35

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

সুতরাং কেন আপনি আজ ওওপকে এটি ব্যবহার শুরু করার চেয়ে জটিল হিসাবে বুঝতে পেরেছেন?

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

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

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

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


সুতরাং নকশা নিদর্শন জটিলতা যুক্ত। অর্থ ডিজাইন নিদর্শনগুলি অগত্যা ওওপি নয় তবে ওওপি উন্নত করার জন্য যুক্ত করা হয়।
ফুনিপ ফিউপাইপ

@মুনমিফেসিপ: বেশ নয় Not নকশা নিদর্শনগুলি স্ট্যান্ডার্ড সমস্যার কেবল প্রমাণিত সমাধান; এগুলি ওওপিতে 'সংযোজন' নয়, তবে পরিণতি। জটিলতা ইতিমধ্যে ছিল; নকশা নিদর্শন কেবল এটি মোকাবেলার জন্য কুকবুক কৌশল সরবরাহ করে।
tmadmers

17

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

তবে ভাল কোড এই সম্পত্তিটি প্রদর্শন করে না। ভাল কোডে, আপনি এখনও বলতে পারেন

std::stack<int> s;
s.push(5);
s.pop();

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

12
ওভার ইঞ্জিনিয়ারিং সম্পর্কে কথা বলার জন্য, এই থ্রেডটি বাধ্যতামূলক: আলোচনা. joelonsoftware.com/default.asp?joel.3.219431
সিকিউর

3
@AndresF। MVVMVMMD নকশা প্যাটার্ন এ শুধু চেহারা: সত্য, কিন্তু আপনি সি ++ কোডে এত এটি পেতে, যেহেতু আপনি জাভা এবং .NET না বলে মনে হচ্ছে না msdn.microsoft.com/en-us/magazine/hh965661.aspx যেমন আপনি কীভাবে 'সাধারণ কোড' গ্রহণ করেন এবং এর নকশার প্যাটার্নটিকে এটি 'সহজ' দেখায় তাড়ানোর জন্য একটি উদাহরণ এবং তারপরে ডিজাইনের প্যাটার্নে অন্য নকশার প্যাটার্নটি চাপড়ান কারণ মূল প্যাটার্নটি বিজ্ঞাপনের মতো সহজ ছিল না। ওভার ইঞ্জিনিয়ারিং দিন দিন সাধারণ হয়ে উঠছে।
gbjbaanb

5
আমি "হয়ে উঠতে" বিট সঙ্গে তর্ক করব। ওভার ইঞ্জিনিয়ারিং ইঞ্জিনিয়ারিংয়ের মতো পুরানো।
রোবট

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

10

আমি বলব যে "জটিলতা" আপনি যে সমস্যার উল্লেখ করেছেন তার ওওপি-র সাথে কোনও সম্পর্ক নেই। উদ্বেগ বিচ্ছিন্ন করার সাথে এর আরও সম্পর্ক রয়েছে।

বহু বছর আগে আমি এমন একটি সিস্টেমে কাজ করেছি যেখানে ডোমেন ক্লাসের নিজস্ব ডাটাবেস থেকে লোড করার দায় ছিল, যেমন

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

এটি খুব স্পষ্ট কোড। এটি বুঝতে কোনও সমস্যা নেই। সমস্যাটি কোডের পরীক্ষায় থাকবে unit যথা, Userডাটাবেস থেকে একটি লোড না করে আমি কীভাবে ইউনিট পরীক্ষা করব ? এবং ডাটাবেসে অ্যাক্সেস না করে আমি কীভাবে এই ওয়েব রিকোয়েস্ট হ্যান্ডলিং কোডটি পরীক্ষা করব? এটি সহজভাবে সম্ভব নয়।

এই কারণেই আমাদের কাছে একটি স্টোরের মতো একটি প্যাটার্ন রয়েছে, কোনও ব্যবহারকারীর থেকে ডোমেন লজিককে হ্যান্ডেল করার দায়িত্বটিকে একটি ডেটা স্টোরে লোড করা এবং সংরক্ষণের কার্যকারিতা থেকে আলাদা করার জন্য। আইওসি কাপলিং হ্রাস করতে, কোডকে আরও পরীক্ষামূলক করে তোলা, ইত্যাদি ক্ষেত্রে সহায়তা করে etc.

সুতরাং আমরা যদি আপনার লেখার উদাহরণটিতে ফিরে যাই তবে আপনি স্টকটি তৈরি করার পরে কী করবেন? এটি ডাটাবেসে সংরক্ষণ করুন

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

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

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


আপনার সংগ্রহস্থল স্থাপনের জন্য আপনাকে যে প্রচেষ্টা করতে হবে তা আপনি জানেন। এটি সেট আপ করার পরেও এটি পুনরায় ব্যবহারযোগ্য হয়ে ওঠে।
টিউনমাইজ ফাইপাইপ

সম্ভবত সমস্যাটি ইউনিট টেস্টিংয়ের সাথে, যদি ছোট ছোট টুকরাগুলির পরিবর্তে আমাদের কাছে পুরোটা পরীক্ষা করার জন্য আরও ভাল সরঞ্জাম থাকে (তবে আপনাকে যেমন করতে হবে) তবে আমাদের সিস্টেমে কম বাগ রয়েছে?
gbjbaanb

2
@ জিবিজেবায়ানব: আমাদের ইতিমধ্যে এটি রয়েছে, একে বলা হয় সংহতকরণ / কার্যকরী পরীক্ষা। ইউনিট টেস্টিং একটি ভিন্ন তবে সমানভাবে প্রয়োজনীয় উদ্দেশ্যে কাজ করে
কেভিন

@gbjbaanb - আমাদের কাছে সিস্টেম-ব্যাপী / গ্রহণযোগ্যতা পরীক্ষার জন্য দুর্দান্ত সরঞ্জাম রয়েছে, যেমন রেল প্ল্যাটফর্মে শসা। তবে যে দলগুলি সত্যই ভাল এবং খুব কম বাগ লিখেছে, তবে দ্রুত সরবরাহ করে, তারা অনেকগুলি ইউনিট পরীক্ষা এবং কেবল কয়েকটি সিস্টেম-ব্যাপী পরীক্ষাও লিখে দেয়। "পরীক্ষার ত্রিভুজ" সম্পর্কে দেখুন, যেমন এখানে jonkruger.com/blog/2010/02/08/theaaomaoma-- টেস্টিং-
পিট

4

আমরাও। আমাদের সমস্যাগুলি সত্যিই পরিবর্তিত হয়নি; গ্রহণযোগ্য কোডের জন্য বার উত্থাপিত হয়েছে।

উপরেরটি অর্জন করতে আপনাকে বেশ কয়েকটি ক্লাস তৈরি করতে হতে পারে (যেমন বিমূর্ত, কারখানা, ডিএও ইত্যাদি) এবং বেশ কয়েকটি ইন্টারফেস প্রয়োগ করতে হবে

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

তবে আপনাকে এও বুঝতে হবে যে ওওর সাথে প্রোগ্রামারগুলি প্রবর্তন করা (বা সেই বিষয়ে কোনও কিছু) ব্যতিক্রমী পরিস্থিতিতে চকচকে ঝোঁক ঝোঁক করবে। সুখী পথটি ব্যাখ্যা করা সহজ এবং নতুনদের একবারে নীচে নেমে গেলে বিশ্রামের বিষয়ে চিন্তা করা সহজ। সিলভার বুলেট নেই; তাই হ্যাঁ, আমি মনে করি যখন আইডিলিক বিভ্রমটি ভেঙে যায় তখন বিষয়গুলি সবসময় শক্ত মনে হয় ...


3

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


এছাড়াও লক্ষ্য করুন যে সময়ের সাথে ফ্রেমওয়ার্কগুলি তৈরি হয়। হ্যাঁ, প্রোগ্রামিংয়ের আরও জ্ঞানের প্রয়োজন নেই। এর অর্থ হ'ল কেউ কম সময়ে আরও বেশি কিছু করতে পারে।
জিনে বোয়ারস্কি

3

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

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

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


পরিষ্কার পয়েন্ট। আমি YAGNI জানি। কিআইএসএস কি?
ফুনিপে

2
@ ফটমিসিফাসিপ, কেআইএসএস হ'ল একটি নকশার নীতির একটি সংক্ষিপ্ত নাম। মূল শব্দগুলি হ'ল " কীপ ইট সিম্পল (বোকা)" (রেফ: এন.ইউইউইকিপিডিয়া.আর / উইকি / কেআইএসএস_প্রিন্টিকাল ) তবে আরও নম্র বাক্যাংশটি হতে পারে "এটি এত সহজ রাখুন"।
NoChance

3
@ ভাগ্যমাইফেসেপ - কেআইএসএস = এটিকে সহজ, বোকা রাখুন। নিজে একটা ফ্রেজ আমি আবার বলছি ধরে, এবং উপর, এবং উপর, এবং এটি এখনও সবসময় ডুবতে মনে হচ্ছে না।
মাইকেল Kohne

@ মিশেলকোহনে, আমরা সবাই! আমি অনুমান করি যে বিষয়গুলিকে সরল করতে সক্ষম হওয়া একটি শিল্প। ই = এম সি সি খুব সংক্ষিপ্ত আকারে পুরোটা বলে!
NoChance

3

সংক্ষিপ্ত উত্তর : হ্যাঁ, কারণ আপনি আরও কঠিন সমস্যার সাথে মোকাবিলা করছেন।

দীর্ঘ উত্তর (দৃ strongly়ভাবে পক্ষপাতদুষ্ট) : আমার জন্য নকশার ধরণগুলি সাধারণত ইঙ্গিত দেয় যে কয়েকটি দৃষ্টান্ত প্রদত্ত ক্ষেত্রে সমস্যা রয়েছে। ওওপি নিদর্শনগুলি ওওপির সমস্যাগুলি মোকাবেলা করে (নিম্ন স্তরে জাভা সম্পর্কিত সমস্যাগুলির সাথে জাভা প্যাটার্নগুলি ডিল করে), এফপি প্যাটার্নগুলি এফপির সমস্যাগুলির সাথে ডিল করে etc.

প্রোগ্রামিংয়ের সময় আপনার বিভিন্ন অগ্রাধিকার থাকতে পারে। আপনি সঠিক প্রোগ্রাম রাখতে চাইতে পারেন, আপনি সময়-প্রতি-বাজারে সংক্ষিপ্ততর, দ্রুততম প্রোগ্রাম সম্ভব, দীর্ঘমেয়াদী রক্ষণাবেক্ষণ বা নতুন ভাড়া দ্বারা তাত্ক্ষণিক রক্ষণাবেক্ষণ করতে চাইতে পারেন। ঝোপঝাড়ের উপর নির্ভর করে আপনি যে পরিমাণে রয়েছেন তা সম্পূর্ণরূপে আলাদা হবে - আপনি যদি বিদ্যুৎ কেন্দ্রের প্রোগ্রামিং কন্ট্রোলার হয়ে থাকেন তবে আপনি এখনই ঠিক প্রথমবার এটি করতে চান এবং প্রতিবার বাগফিক্স না করে ("আপনি যখন প্রতিবার চাপছেন ততক্ষণে মেল্টডাউন হয় Ctrl+Alt+Del?")। আপনি যদি এইচপিসিতে থাকেন তবে যুক্তিটি আপেক্ষিকভাবে সহজ হতে পারে তবে আপনি যত তাড়াতাড়ি সম্ভব এটি সম্পাদন করতে চান ইত্যাদি Additionally আরও কিছু উপমা কিছু সমস্যা আরও ভাল ফিট করে (এআই এবং লজিক প্রোগ্রামিং, ডেটা এবং সম্পর্কিত ডেটাবেসগুলি বলুন)।

ওওপি সাধারণ ক্ষেত্রে কিছুটা 'খুব ভাল' প্রসারিত করার এবং এটি "বাস্তবের লাইভ মডেলিং" গল্প। গলি আমি প্রথম বই উদাহরণ পঠিত জন্য সেখানে ক্লাস ছিল Person, Employeeএবং Managerসঙ্গে is-aসম্পর্ক। এতদূর ভাল তবে কর্মচারীকে ম্যানেজার পদে পদোন্নতি দেওয়া হলে কী হবে?

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

গীত। হ্যাঁ - উত্তরটি ওওপির বিরুদ্ধে পক্ষপাতদুষ্ট এবং আমি স্বীকার করি যে এটি কিছুটা প্রসারিত হয়ে ওওপির 'প্রতিক্রিয়াতে' রয়েছে। ওওপি এর ব্যবহারগুলি রয়েছে তবে এটি আমার মতে একমাত্র, চূড়ান্ত সমাধান নয়।

PPS। হ্যাঁ - নকশার নিদর্শনগুলি ব্যবহার করুন - তারা ওওপি প্রোগ্রামিংকে চূড়ান্তভাবে সহজ করে তোলে।

PPPS। আমি ওওপিটিকে ওওপি ব্যবহার্য প্রোগ্রামিংয়ের প্রতিশব্দ হিসাবে ব্যবহার করেছি।


2

আমি মনে করি এটি নথি এবং উদাহরণগুলি আরও বাস্তববাদী হয়ে ওঠে।

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

ধন্যবাদ, ও ও বইগুলি এখন বাস্তব জীবনের জটিলতাগুলি স্বীকার করে, এবং কীভাবে সেগুলি মোকাবেলা করতে পারে তার দরকারী উদাহরণ সরবরাহ করে।

আপনি যদি দেখতে চান তবে কীভাবে কেবলমাত্র 15 টি লাইনের কোড ফাংশনাল প্রোগ্রামিংয়ে কোনও ব্যাংক অ্যাকাউন্ট চালানো যায় তা আপনার লোক

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