ওওপি কেন কঠিন? [বন্ধ]

Question

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

কেন ওওপি বুঝতে অসুবিধা হয়? বুঝতে কি অসুবিধা হয়?

Comments

আমি এর সাথে পাল্টাচ্ছি: এটি বোঝা কঠিন নয়, মাস্টার করা ঠিক। পুরোপুরি প্রোগ্রামিং এইভাবে।

— স্টিভেন ইভার্স

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

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

— কমোনাদ

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

— মিং_কোডস

কারণ এটির নামকরণ করা হয়নি। এটি সত্যিই সাবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং হওয়া উচিত, যাতে সাবজেক্টটি অ্যাকশন (ক্রিয়াপদ) সম্পাদন করে এবং অবজেক্টটি ক্রিয়া গ্রহণ করে - জন বল নিক্ষেপ করে। সুতরাং johnsBall.throw () আসলেই বোঝায় না।

— ক্রিস চুদমোর

Answer 1

আমি ব্যক্তিগতভাবে OOP এর যান্ত্রিকগুলি উপলব্ধি করতে মোটামুটি সহজ found আমার পক্ষে কঠিন অংশটি ছিল "কেন"। যখন আমি প্রথম এটির সংস্পর্শে এসেছি তখন মনে হয়েছিল কোনও সমস্যার সন্ধানে এটির সমাধান। আমি মনে করি কেন বেশিরভাগ লোকেরা এটি কঠিন বলে মনে করেন তার কয়েকটি কারণ এখানে রয়েছে:

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

2. আপনি OO কে সত্যই উপলব্ধি করার আগে আপনার ডেটা স্ট্রাকচার এবং দেরীতে বাইন্ডিং / উচ্চতর আদেশ ক্রিয়াকলাপগুলির বেসিকগুলি জানতে হবে। পলিমারফিজম (যা মূলত ডেটার দিকে নির্দেশক এবং ডেটাগুলিতে কাজ করে এমন একগুচ্ছ ফাংশনগুলির কাছাকাছি চলেছে) এটি শক্ত করা যদি আপনি এমনকি আদিম ব্যবহারের পরিবর্তে এবং উচ্চতর আদেশের ক্রিয়াকলাপগুলি ঘুরে দেখার পরিবর্তে ডেটা গঠনের ধারণাগুলি বুঝতে নাও পারেন / ফাংশন পয়েন্টার।

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

Comments

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

— ড্যান রোজনস্টার্ক

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

— কোডেক্সআরকানাম

"আমার পক্ষে কঠিন অংশটি এর" কেন "ছিল for সাধারণ সমাধানগুলির (নকশার নিদর্শন) দিকে ভাষার বুনিয়াদি (এনক্যাপসুলেশন) এবং নকশার নীতিগুলি এবং রিফ্যাক্টরিংয়ের পদ্ধতিগুলি বুঝতে এবং প্রয়োগ করতে কিছুটা সময় এবং প্রচেষ্টা প্রয়োজন।

— বেলুন

আমি # 1 এর সাথে সম্মত হয়েছি, আপনার শিখার সময় যে প্রক্রিয়াজাত পদ্ধতিতে প্রোগ্রামিং করা হয়েছিল তার চেয়ে আগে থেকেই জানেন যে লোকেদের কাছে OO বোঝানোর জন্য আরও ভাল কাজ করা উচিত cave না, Catউত্তরাধিকার সূত্রে প্রাপ্ত বর্গ সম্পর্কে কথা বলা কার্যকর বা তথ্যবহুল নয় Mammal, বাস্তব প্রোগ্রামের একটি বাস্তব উদাহরণ ব্যবহার করুন যা আমরা প্রক্রিয়াগতভাবে লিখে থাকতাম। একটি সাধারণ ডেটা স্ট্রাকচারের মতো।

— কারসন 63000

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

— সিজারগন

Answer 2

আমি মনে করি এমন কয়েকটি কারণ রয়েছে যা এখনও উল্লেখ করা হয়নি।

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

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

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

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

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

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

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

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

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

Comments

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

— কোডেক্সআরকানিয়াম

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

— rmac

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

— ওনেসিমাসউবাউন্ড 16

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

— জেরি কফিন

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

— ইভান প্লেস

Answer 3

OOP বিমূর্তভাবে চিন্তা করার ক্ষমতা প্রয়োজন; একটি উপহার / অভিশাপ যা খুব কম লোক এমনকি পেশাদার প্রোগ্রামাররাও পেয়ে থাকে।

Comments

সমস্ত প্রোগ্রামিং বিমূর্ত।

— JeffO

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

— জন ক্রাফ্ট

কাউকে 2 টি পেন্সিল হস্তান্তর করা এবং তারপরে তাদের 1 টি পেন্সিল হস্তান্তর করা এবং তাদের কাছে কতগুলি পেন্সিল রয়েছে তা জিজ্ঞাসা করা কংক্রিট। 2 + 1 = 3 বিমূর্ত।

— জেফও

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

— কনরাড রুডল্ফ

পছন্দ করুন "বিমূর্ততা ছাড়াই অন্য সবকিছু খুব জটিল হবে" এর জন্য +1 ।

— কার্তিক শ্রীনিবাসন 24'12

Answer 4

আমি মনে করি আপনি এইভাবে মূল অসুবিধাটির সংক্ষিপ্তসার করতে পারেন:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

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

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

Comments

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

— ডেরেনডাব্লু

+1, "সাবস্ট্রিট (তারিখ, 0,4)" লেখার কয়েক বছর পরে, "তারিখ.সাবস্ট্রিং (0,4)" লিখতে পারা কঠিন

— 23'11

কোড স্নিপেটের জন্য +1। এটি স্পষ্টভাবে একটি আসল চিন্তার প্রক্রিয়া চিত্রিত করে।

— কার্তিক শ্রীনিবাসন

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

— 55

ভাল অন্তঃসত্ত্বা, সুতরাং "এজেন্ট সিস্টেমস" মডেলিংয়ের জন্য মেই ওওপি আরও উপযুক্ত?

— কিউবিক

Answer 5

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

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

• গুরুত্বপূর্ণ ধারণাগুলি বিজোড় নামগুলির আড়ালে লুকানো রয়েছে (এফপি: একটি মোনাদ কী? ওওপি: তারা কেন তাদের মাঝে মাঝে ফাংশন এবং অন্য সময় পদ্ধতি বলে?)

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

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

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

সামান্য লাফ দেওয়ার পরে বোঝা সংশোধন করতে সহায়তা করা হয়, তবে এটি প্রাথমিক যে "একজনকে বোঝায় না, লোকেরা কেন এটি করে?" "ওওপি সেরা, লোকেরা কেন অন্য কিছু করে?"

Comments

আমি বিশেষত রূপককে ঘৃণা করি, প্রায়শই না, তারা বর্ণনার চেয়ে বিভ্রান্ত করে।

— মিথ্যা রায়ান

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

— জারেড আপডেটিকে

ধারণাগুলি ব্যাখ্যা করতে রূপক ব্যবহার করে আমার সমস্যাটি হ'ল শিক্ষক প্রায়শই রূপকটির উপরে থামেন, যেন এটি পুরো বিষয়টি ব্যাখ্যা করে। না এটি সম্পূর্ণ ব্যাখ্যা নয়; আসল ব্যাখ্যার চারপাশে আমাদের মাথা গুটিয়ে রাখতে সহায়তা করার জন্য এটি কেবল একটি চিত্র ।

— ঝাঁকুনি করা

দুর্দান্ত উত্তর! ফাউন্ডেশনটির ভাল বোঝার সাথে প্রাকৃতিক এক্সটেনশন হিসাবে পরে যা আসে তার চেয়ে ওওপি বোঝার প্রথম ধাপটি আরও তাত্পর্যপূর্ণ হবে তা বোঝানোর জন্য +1। : ডি

— কার্তিক শ্রীনিবাসন

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

— রডারবব

Answer 6

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

নকশার নিদর্শনগুলি থেকে শিক্ষা দেওয়া ওওপি বর্ণনা করার একটি আরও ভাল উপায়, কারণ এটি প্রোগ্রামারদের দেখায় যে কীভাবে প্রকৃত মডেলিংয়ের সমস্যাগুলি অ্যাবস্ট্র্যাক্টে বর্ণনা না করে এটি কী কীভাবে কার্যকরভাবে আক্রমণ করা যেতে পারে objects

Answer 7

আমি বেশিরভাগ ক্ষেত্রেই সিমচা উত্তরের সাথে একমত নই:

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

2. ভাল ওও প্রোগ্রামগুলিতে পৃথক পদ্ধতিগুলি সকলের দিকে প্রক্রিয়াকরণের হতে থাকে না। এটি ওও ভাষাগুলির বিবর্তনের সাথে আরও সত্য হয়ে উঠছে (সি # পড়ুন কারণ সি ++ ছাড়া এটি আমার জানা অন্যান্য ওও ভাষাগুলি) এবং তাদের বাক্য গঠন যা দিনে দিনে আরও জটিল হয়ে উঠছে (ল্যাম্বডাস, অবজেক্ট টু লিনকড ইত্যাদি)। পদ্ধতিগত ভাষাগুলিতে ওও পদ্ধতি এবং পদ্ধতিগুলির মধ্যে একমাত্র মিল হ'ল প্রতিটির রৈখিক প্রকৃতি, যা আমার সন্দেহ যে শীঘ্রই যে কোনও সময় পরিবর্তিত হবে।

3. আপনি ডেটা স্ট্রাকচার বুঝতে না পারলে একটি পদ্ধতিগত ভাষায় আয়ত্ত করতে পারবেন না। পয়েন্টার ধারণাটি ওও ভাষাগুলির মতো পদ্ধতিগত ভাষার জন্যও গুরুত্বপূর্ণ। রেফারেন্স দ্বারা প্যারামিটারগুলি পাস করার জন্য, উদাহরণস্বরূপ, যা পদ্ধতিগত ভাষাগুলিতে বেশ সাধারণ, আপনার যে কোনও ওও ভাষা শেখার জন্য প্রয়োজনীয় পয়েন্টারগুলি বোঝার প্রয়োজন understand

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

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

Comments

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

— গ্যারি উইলফোবি

+1 - দুর্দান্ত উত্তর। আপনি যে চতুর্থ বক্তব্য বলেছেন তা আমি পছন্দ করি। এটি খুব সত্য যে ডিজাইন প্যাটারগুলি আসলে কী তা জেনেও একজন ভাল ওও প্রোগ্রামার হতে পারে!

— কার্তিক শ্রীনিবাসন

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

— ইভান প্লেস

Answer 8

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

Answer 9

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

Answer 10

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং নিজেই শক্ত নয়।

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

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

Comments

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

— জারেড আপডেটিকে

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

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

— বিরক্তিকর_স্কুইড

Answer 11

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

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

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

আমার জন্য ওও একটি দুর্দান্ত উপকার ছিল তবে আপনি যদি একইভাবে কল্পনা না করেন বা উচ্চ-স্তরের স্থাপত্য না করেন তবে এটি সম্ভবত অর্থহীন এবং বিরক্তিকর।

Comments

+1 আমিও একইভাবে অনুভব করি তবে রুবি মিক্সিন সহ বিপরীত দিকে প্রচুর ধাক্কা লেগেছে ... যা আপনাকে উপলব্ধি করতে পারে যে কঠোর হে ও সবার জন্য নয়।

— ড্যান রোজনস্টার্ক

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

— বিল কে

আমি মনে করি এটি আরও প্রাকৃতিক নামকরণের সম্মেলনগুলিকে উত্সাহিত করতে সহায়তা করে। আপনি আর ফাংশনের নাম মধ্যে একটি ফাংশন ধরণ সঙ্কেতাক্ষরে লিখা (যেমন প্রয়োজন INSTR(যেমন কারণ নাম টাইপ করা সংযুক্ত করা হয় -) string::find)

— কেন ব্লুম

@ যদিও আমি সম্মত, আমি মনে করি এটি ওওর চেয়ে বেশি শক্ত টাইপিংয়ের বিষয় - রুবীর কাছে ওও রয়েছে তবে আপনি হাঁসের টাইপিংয়ের কারণে প্রচুর পরিমাণে তথ্য হারাবেন - রুবি কেবল "প্রেরণ (এটি)" বলবেন এবং আশা করবেন আপনাকে জানতে হবে কাজ করার জন্য কোন ম্যাজিক পদ্ধতি "এটি" প্রয়োগ করতে হবে।

— বিল কে

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

— কেন ব্লুম

Answer 12

আমি জিডাব্লু-বেসিক এবং টার্বো পাস্কাল প্রোগ্রামিং ওয়ের সাথে পরিচয় করানোর আগে বেশ কিছুটা করেছি, তাই প্রাথমিকভাবে এটি আমার মাথা .ুকেছিল ।

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

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

Comments

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

— ড্যারেনডাব্লু

Answer 13

আমি এটি বুঝতে অসুবিধা করি না বলে মনে করি তবে এটি হতে পারে যে প্রচুর প্রোগ্রামারদের জিজ্ঞাসাবাদকারী প্রক্রিয়াগত ভাষা থেকে আসা ধারণাটিতে নতুন।

আমি প্রচুর লোককে যা দেখেছি / পড়েছি তা থেকে (ফোরামে অন্তত) ওওপি থেকে 'ফলাফল' সন্ধান করে। আপনি যদি কোনও প্রক্রিয়াভিত্তিক প্রোগ্রামার হন যিনি পিছনে যান না এবং তাদের কোডটি প্রসারিত করেন না তবে সম্ভবত সুবিধাগুলি বুঝতে অসুবিধা হতে পারে।

এছাড়াও, সেখানে প্রচুর খারাপ ওওপি আছে, লোকেরা যদি এটি পড়ছে / দেখছে তবে তাদের কেন এটি কঠিন হতে পারে তা সহজেই দেখা যায়।

IMO আপনার 'ক্লিক' হওয়া অবধি অপেক্ষা করা বা সত্যিকারের জ্ঞান সহকারীর দ্বারা শেখানো দরকার, আপনি ছুটে যেতে পারবেন বলে আমি মনে করি না।

Comments

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

— কোডেক্সআরকানিয়াম

Answer 14

আমি মনে করি OOP অনেকের পক্ষে কঠিন কারণ কারণ সরঞ্জামগুলি আসলে এটি সহজ করে না।

কম্পিউটার ভাষা আজ কম্পিউটারে যা চলছে তার বিমূর্ততা।

OOP বিমূর্ততা উপস্থাপন করার একটি বিমূর্ত উপায় st

সুতরাং আমরা একটি বিমূর্ততা দিয়ে বিমূর্ততা তৈরি করতে একটি বিমূর্তি ব্যবহার করছি। এটিকে যুক্ত করুন যে আমরা যা বিমূর্ত করছি তা সাধারণত খুব জটিল শারীরিক / সামাজিক মিথস্ক্রিয়া হয় এবং আশ্চর্যের কিছু নেই।

Answer 15

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

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

Comments

সম্মত হন - ওওর সাথে লোকেদের যে অনেক অসুবিধা রয়েছে তা হ'ল তারা 'পদ্ধতিগতভাবে' ভাবতে প্রশিক্ষণ দিয়েছিলেন। ওও সম্পর্কে অন্তর্নিহিতভাবে কঠিন কিছু নেই তবে আপনি যদি পদ্ধতিগত কৌশলগুলি 'জান' তবে জিনিসগুলির কাঠামোগত করার অন্য উপায়টি দেখে অবাক হওয়ার কিছু থাকবে না।

— কर्क ব্রডহર્স্ট

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

— বিরক্তিকর_স্কুইড

Answer 16

প্রেরণা। কেন আপনি যখন দেখেন না এবং যখন আপনি কী করেছেন তা তাকাতে না পারলে এবং আপনি এটি সঠিকভাবে করেছেন কি না তা নির্ধারণ করতে না পারলে কিছু শেখা শক্ত।

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

Comments

লোকেরা সর্বদা সিঙ্গেলটন সম্পর্কে কথা বলতে পারে না, তবে তারপরে তিনি সর্বদা পার্টিতে আমন্ত্রিত হন। তবে এটি সত্য, তিনি নন-ওও ওও ডিপি।

— ড্যান রোজনস্টার্ক

Answer 17

আমি মনে করি এটি বয়স (অভিজ্ঞতার প্রক্সি হিসাবে বয়স) এবং আরও গুরুত্বপূর্ণভাবে আগ্রহের উপর নির্ভর করে। আপনি যদি "তরুণ" (যেমন, সবুজ, সম্ভবত) হন এবং আপনি অন্য কোনও উপায়ে কখনও ভাবেননি, এটি বেশ সোজা মনে হয়। অন্যদিকে, আপনি যদি ভাবেন এটি সবচেয়ে দুর্দান্ত জিনিসটি আপনি কখনও দেখেছেন - আমার সাথে 28 বছর বয়সে বা কিছু ঘটেছে - এটি আঁকানো সহজ।

অন্যদিকে, আপনি যদি ভাবেন যে, আমার অনেক জাভা শিক্ষার্থী যেমন করেছে, "আমরা কেন এটি শিখছি, এটি কেবল একটি অভ্যাস", এটি শেখা কার্যত অসম্ভব। বেশিরভাগ প্রযুক্তির ক্ষেত্রে এটি সত্য।

Comments

ওফ ফ্যাড? আপনার ছাত্ররা কত বছর বয়সী - আমার সন্দেহ হয় যে এই "ফ্যাড" তারা তাদের থেকেও বেশি বয়স্ক (প্রথম ওও আমি করলাম - আমি জানতাম যে আমি করেছি - প্রায় 1983/4 সালে সিমুলা ছিলেন এবং সিমুলা সেই সময়ে নতুন ছিলেন না)

— মার্ফ

@ মুরফ এটি ২০০৪-২০০৫ সালের দিকে ছিল এবং শিক্ষার্থীরা অবশ্যই ৪৫-৫০ এর বেশি ছিলেন (আইবারিয়ার পেশাদার প্রোগ্রামার)।

— ড্যান রোজনস্টার্ক

ঠিক আছে, আমি কীভাবে দেখতে পারি তারা কীভাবে ওও জিনিসটির শুরুটি মিস করেছে। তবে 2004/5 এর মধ্যে আমরা নেট নেট হয়ে গিয়েছিলাম যা প্রাচীর প্রাচীরের ওয়াল প্রাচীর (-: বিকাশের এমন কিছু রয়েছে যা ফ্যাড হিসাবে বর্ণনা করতে পারে তবে যেগুলি ঝাঁকুনি দেয় না তারা দ্রুত ভাল জিনিসগুলিতে বিকশিত হয়

— মারফ

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

— ফুটিয়ে উঠবে

Answer 18

কম্পিউটার প্রোগ্রাম লেখার জন্য আপনি কোন দৃষ্টান্ত (ওওপি, ফাংশনাল ইত্যাদি) বেছে নিচ্ছেন তা নির্ধারণ না করে আপনার প্রোগ্রামটি কী পদক্ষেপ করবে তা জানতে হবে।

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

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

এবং এ কারণেই ওওপি কঠিন। যেহেতু সবকিছুই একটি বস্তু, তাই তারা যা কিছু করে অন্য বস্তুকে কিছু করতে বলছে, এবং এই অন্যান্য বস্তুগুলি মূলত কিছু করে। সুতরাং একটি ওওপি প্রোগ্রামের নিয়ন্ত্রণগুলি বস্তুর মাঝে বুনোভাবে পিছনে পিছনে লাফিয়ে উঠতে পারে।

Answer 19

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

অবশ্যই, আমি বুঝতে পেরেছি যে সমস্যাটি সম্ভবত নেটিভ-ওওপি ভাষার সাথে আমার অভিজ্ঞতার অভাব, এবং সময়ের সাথে সাথে আমি অবজেক্টগুলিকে ব্যবহারের জন্য এমন নতুন উপায়গুলি সন্ধান করব যা আমি যেভাবে নতুন প্রোগ্রামারের কাছে অস্পষ্ট হয়ে উঠব will বর্তমানে অভিজ্ঞতা। জেরি কফিন কয়েকবার এটি স্পর্শ করেছেন, বিশেষত তাঁর মন্তব্যে:

এটি বিশেষত সমস্যার মুখোমুখি হয় যখন আপনাকে বলা হয় যে ওওপির একটি বড় সুবিধা বাস্তবতাকে আরও নিবিড়ভাবে মডেলিং করে তবে আপনি একেবারে মৌলিক এবং স্পষ্ট অংশগুলির এলএসডি-অনুপ্রাণিত দৃষ্টিভঙ্গির মতো ভয়াবহ কিছু দেখায় তা শুরু করেন start বাস্তবতা।

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

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

Comments

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

— গাংনাস

আমি যেমন বলেছিলাম, দূরত্ব একটি দুর্বল উদাহরণ ছিল। সব কিছু থেকে কোনও অবজেক্ট তৈরি করার জন্য, আমি বিশেষভাবে আমি যা ঘটতে দেখেছি তা উল্লেখ করছি, যা আমি আসলে করেছি তা নয় - যা এখনও কিছুই নয়।

— ডিজিমার

এটি ভাষার উপর নির্ভর করে - ছোট্ট টালিতে দূরত্ব (এবং সমস্ত কিছু) একটি বস্তু। তবে সি # তে আপনি উল্লেখ করেছেন এটি খারাপ হবে।

— গাংনাস

Answer 20

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং (পিওওপি) এর নীতিগুলি শিখার সময় টার্মিনোলজগুলি আমার রাস্তায় ছিল ump এটি যখন আপনি মৌলিক বিষয়গুলি বুঝতে পারেন যে টুকরাগুলি জায়গায় পড়তে শুরু করে। ঠিক তেমন নতুন ধারণা শেখার সমস্ত জিনিস যেমন কিছুটা শক্ত hard

সম্মত হয়েছেন যে নকশার নিদর্শনগুলি কমপক্ষে ওওপির সমান্তরালে চেষ্টা করা উচিত।

Answer 21

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

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

Comments

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

Answer 22

প্রণালী

ভাল ওওপি বোঝাপড়া = গুড মেন্টর বা ভাল বই বা উভয়ই + ব্যক্তিগত আগ্রহ + অনুশীলন।

ব্যক্তিগত স্বার্থ

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

অনুশীলন, অনুশীলন এবং অনুশীলন

ওওপি সম্পর্কে আরও ভাল বোঝার জন্য আমার সেরা বন্ধু অনুশীলন ছাড়া কিছুই নয় ।এটি অবশ্যই আপনার ওওপি সক্ষমতাকে বাড়িয়ে তুলবে।

কথা যায় যেমন রয়েছে "কঠোর পরিশ্রমের বিকল্প নেই এবং সাফল্যের কোনও শর্টকাট নেই।"

শুভকামনা!