আমরা কখন অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং ব্যবহার করি? [বন্ধ]


35

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

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

কী করা উচিত সে সম্পর্কে আরও কিছু তথ্য:

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

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

সুতরাং, আমার প্রশ্নটি হবে: আপনি ছেলেরা, কখন কোনও অ্যাপ্লিকেশনটিতে ওওপি ব্যবহার করবেন তা জানেন / সিদ্ধান্ত নেবেন ?


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

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

@ রবার্টহারভে ঠিক আছে, বুঝেছি আমি পরের বার এটি করব।
গ্রেজডানু অ্যালেক্স।

উত্তর:


60

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

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

অন্যদিকে ওও পরিবর্তনীয় স্থিতিটি এনক্যাপসুলেটিং সম্পর্কে এবং তাই ইন্টারেক্টিভ অ্যাপ্লিকেশন, জিইউআই এবং এপিআইয়ের এক্সপোজার পরিবর্তনযোগ্য স্থিতির জন্য আরও উপযুক্ত। এটি কোনও কাকতালীয় ঘটনা নয় যে ওও প্রথম জিইউআইয়ের সমান্তরালে বিকাশ লাভ করেছিল।

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

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

নীচের লাইন: আমি সংস্থার মডিউলগুলিতে বিভক্ত ফাংশনগুলির একগুচ্ছ পরামর্শ দিচ্ছি, তবে কোনও বস্তু নেই।


8
অবশেষে একটি সুষম ভারসাম্য উত্তর যা কেবল
ওওপি

1
এটাই আমি প্রত্যাশা করেছিলাম answer আপনার উত্তর কিছুটা প্রসারিত করতে পারে? এখনও অবাক লাগছে।
গ্রেজডানু অ্যালেক্স।

3
@ ডেক্স'টার: আপনার চেয়ে বেশি। আপনি কী ধরনের অতিরিক্ত তথ্য সন্ধান করেন?
জ্যাকবিবি

3
আমি এটিতে যুক্ত করব যে ফাংশনাল প্রোগ্রামিং পড়ার একটি দৃষ্টান্ত হতে পারে।
অ্যান্ড্রু বলছেন

1
@ বার্গি: হ্যাঁ এটি বহু-দৃষ্টান্তের ভাষার সুবিধা। আপনি নিজের প্রোগ্রামটি ওও-স্টাইলে না লিখে ওও গ্রন্থাগারগুলি ব্যবহার করতে পারেন।
জ্যাকবিবি

15

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

জিওআইআই পরিচালনা করার জন্য ওওপি হ'ল একটি দুর্দান্ত সরঞ্জাম এবং অন্যান্য পরিস্থিতিতে যেখানে সিস্টেমের কিছু অংশের অস্থির অবস্থা রয়েছে।

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

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

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


6

অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং আপনার অস্ত্রাগারে চারটি নতুন সরঞ্জাম যুক্ত করেছে:

  1. encapsulation
  2. বিমূর্তন
  3. উত্তরাধিকার
  4. পলিমরফিজ্ম

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


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

4
@ ডেভিড আর্নো: আপনি মূলত বলছেন "কখনই ওওপি ব্যবহার করবেন না।"
রবার্ট হার্ভে

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

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

4
@ গ্রেডেনহেড আপনার অদ্ভুত বোধগম্যতা আপনার অবস্থানের জন্য কিছুই করছে না। 'আপনারা কেন সবচেয়ে বেশি চাকরিযোগ্য ভাষা প্রায়শই OO' শিরোনামে একটি প্রশ্ন ছড়িয়ে দিতে পারেন? আরও ভাল, Ctrl + F টাইপ করুন এবং 'GUI' টাইপ করুন।
গুড্ডর

1

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

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

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

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

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


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

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

0

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের সবচেয়ে বড় বিষয় হ'ল প্রোগ্রাম প্রবাহ সম্পর্কে যুক্তি না দিয়ে আপনি রাষ্ট্র সম্পর্কে যুক্তি শুরু করেন।

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

এবং একবার আপনি রাষ্ট্র সম্পর্কে যুক্তি দিয়ে ভাল ওওপি কোড তৈরি করা সহজ কারণ আপনার কোডটি খুব জটিল হয়ে যাওয়ার সাথে সাথে আপনি খেয়াল করেন যে আপনি আর নিজের রাষ্ট্র সম্পর্কে যুক্তি দিতে পারবেন না এবং জানেন যে আপনাকে রিফ্যাক্টর করতে হবে।

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

এবং সুন্দর জিনিসটি: আপনি এটির জন্য পরীক্ষা করতে পারেন।


3
ওয়েব থেকে কোনও ফাইল পড়ার বিপরীতে ডিস্ক থেকে কোনও ফাইল পড়ার সাথে আপনার উদাহরণও বিভিন্ন ফাংশন সহ প্রয়োগ করা যেতে পারে। এর জন্য আপনার ওও দরকার নেই।
জ্যাকবিবি

0

সাধারণ লোকের পদে:

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

এটি বলেছিল যে, আমলে নেওয়া অন্যান্য কারণও রয়েছে:

  • আপনার প্রোগ্রামাররা কি ওওপি / ওওডি-তে দক্ষ?
  • আপনার প্রোগ্রামাররা কি কোনও ওওপি ভাষায় দক্ষ?
  • আপনার কি মনে হয় সময়ের সাথে সাথে সফটওয়্যারটি জটিল আকার ধারণ করবে?
  • আপনি কি ভবিষ্যতে কোডটি স্কেল বা পুনঃব্যবহার করার পরিকল্পনা করছেন?
  • আপনি কি মনে করেন যে আপনার "নকশা" কোনও সম্পদে পরিণত হতে পারে? অর্থাত্ আপনি কি এটিকে বাড়ানোর জন্য বা ভবিষ্যতের প্রকল্পগুলির ভিত্তি হিসাবে উপার্জন করতে সক্ষম হবেন?

আমাকে ভুল করবেন না: আপনি ওওপি ব্যবহার না করে সেগুলি অর্জন করতে পারেন তবে ওওপি দিয়ে এটি আরও সহজ হবে।

কিন্তু ...

যদি আপনার দলটি ওওপি / ওওডিতে দক্ষ না হয় এবং সে ক্ষেত্রে কোনও দক্ষতা না থাকে তবে আপনার যে সংস্থান রয়েছে সেগুলি নিয়ে যান।


-2

সুতরাং, আমার প্রশ্নটি হবে: আপনি ছেলেরা, কখন কোনও অ্যাপ্লিকেশনটিতে ওওপি ব্যবহার করবেন তা জানেন / সিদ্ধান্ত নেবেন?

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

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

  • লগিং, উদাহরণস্বরূপ, কারণ এটি একটি ভিন্ন লগারের বিকল্পকে সহজ করে তোলে

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

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


6
আমি ডাউনভিট করি নি (যদিও আমি এর নিকটবর্তী ছিলাম), তবে আমি মনে করি যে আপনি যে ডাউনভোটগুলি পেয়েছেন তার কারণ: "সর্বদা এটি ব্যবহার করুন, কারণ এটি দুর্দান্ত" খুব কমই একটি ভাল পরামর্শ। সর্বদা ব্যতিক্রম আছে। ডাউনসাইড ছাড়া কোনও সরঞ্জাম আসে না এবং ওওপিও এর ব্যতিক্রম নয়। লোকেদের বলুন যে এটি ভাল, লোকেরা এটির পক্ষে কী ভাল, তা কেন ভাল তা লোকেদের বলুন, লোকেরা যদি পারেন তবে বিকল্পগুলি এড়াতে বলুন, তবে কখনও বিকল্পগুলি সম্পর্কে ভাবেন না বলে লোকেদের বলুন না।
26:56 16:56

@ মাস্টার, আমি ঠিক আছি যদি লোকেরা কম ভোট দেয় তবে এটি তাদের পছন্দ, এবং আমি এটিও করেছি done বিষয়টির বিষয়ে, আমি এখনও মনে করি যে ব্যক্তি প্রশ্ন জিজ্ঞাসা করছে তার পক্ষে এটি সঠিক উত্তর; আইএমএইচও, ওপিকে ওওপিকে সমস্ত পথে ঝাঁপিয়ে পড়ে ওওপি ব্যবহার করতে হবে, কখন ওওপি ব্যবহার করবেন এবং সিদ্ধান্ত নেওয়ার চেষ্টা করার পরিবর্তে মাঝে মাঝে কোনও শ্রেণি তৈরি করা বাছাই করা উচিত নয়, তবে পদ্ধতিগত কোড লিখতে হবে।
এরিক tদ

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

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

1
এটিকে "আরও একটি বুদ্ধিহীন ওওপি জিলিওট" হিসাবে তরান্বিত করার পক্ষে যতটা সহজ, আমি মনে করি এটি সত্যই অভ্যন্তরীণ এবং শোষণের জন্য আসলে 100% কিছুতে যাওয়ার জন্য কিছু বলা যেতে পারে। তাই না আপনি এটি সারা জীবনের জন্য প্রতিদিন ব্যবহার করতে পারেন, তবে তাই আপনি আসলে শক্তি এবং দুর্বলতাগুলি শিখেন এবং কেবল সেগুলি সম্পর্কে পড়েন না। আমি কারও কাছে সুপারিশ করতাম যে কয়েক মাস ধরেই ওওপি এবং কয়েক মাসের হার্ড এফপি (has লা হাস্কেল) এবং কয়েক মাস প্রক্রিয়াজাতীয় সি ইত্যাদি কাটাতে হবে। কেবল সেখানে andুকুন এবং নীচে নামুন এবং এটি দিয়ে নোংরা।
সারা

-2

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

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

কী করবেন - এই অংশটি যেখানে ব্লকগুলি প্রকৃত কাজ নিজেই করে। এখানে ক্লাসটি "কীভাবে বিভাগে" তৈরি করা বেস ক্লাসগুলি থেকে উত্পন্ন হয়।

ওওপিএসের মাধ্যমে কেউ উপকৃত হতে পারে

  1. আপনি যদি কোনও বিদ্যমান কাঠামো পুনরায় ব্যবহার করতে পারেন এবং কেবল "কী করবেন" বিভাগে সুনির্দিষ্ট বিবরণ প্রয়োগ করতে হয়।
  2. বর্তমান প্রকল্পের জন্য যে কার্যকারিতা বাস্তবায়ন করা হচ্ছে তা সাধারণ / সাধারণভাবে ব্যবহৃত একটি এবং অন্যান্য প্রকল্প / ভবিষ্যতের প্রকল্পগুলি বর্তমান প্রকল্পের বিকাশের সময় তৈরি হওয়া কাঠামো থেকে উপকার পেতে পারে।
  3. একটি বিশাল সমস্যা সমাধানের জন্য প্রচুর প্রকল্পগুলি সাধারণভাবে নিদর্শনগুলিতে ভাঙ্গা।
  4. এমনকি ছোট প্রকল্পের অভ্যাস পেতে ওওপিএস ব্যবহার করুন এবং 1 - 3 ধরণের সমস্যা যখন আসে তখন প্রস্তুত হন be

সুতরাং আপনি মূলত বলছেন যে আপনি যে সমস্যার সমাধান করতে চান তা নির্বিশেষে আপনার সর্বদা ওওপি ব্যবহার করা উচিত ?
জ্যাকবিবি

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