অনুশীলনে ওওপি পদ্ধতিগত প্রোগ্রামিংয়ের কোন সমস্যাগুলি সমাধান করে?


17

আমি "C ++ Demysified" বইটি অধ্যয়ন করেছি । এখন আমি রবার্ট ল্যাফোনের "টার্বো সি ++ প্রথম সংস্করণ (1 ম সংস্করণ)" অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং পড়তে শুরু করেছি। আমার কাছে প্রোগ্রামিং সম্পর্কিত কোনও জ্ঞান নেই যা এই বইয়ের বাইরে। এই বইটি পুরানো হতে পারে কারণ এটি 20 বছরের পুরানো। আমার কাছে সর্বশেষতম সংস্করণ রয়েছে, আমি পুরানটি ব্যবহার করছি কারণ এটি আমার পছন্দ হয়েছে, প্রধানত আমি লাফোর বইয়ের প্রথম সংস্করণের মাধ্যমে সি ++ এ ব্যবহৃত ওওপির প্রাথমিক ধারণাগুলি অধ্যয়ন করছি।

লাফার বইটি জোর দেয় যে "ওওপি" কেবল বৃহত্তর এবং জটিল প্রোগ্রামগুলির জন্যই কার্যকর। এটি প্রতিটি ওওপি বইতে (ল্যাফোনের বইয়েও) বলা হয় যে পদ্ধতিগত দৃষ্টান্তটি ত্রুটিগুলির ঝুঁকিতে থাকে যেমন বিশ্বব্যাপী ডেটাগুলি ফাংশনগুলির দ্বারা সহজেই অরক্ষিত থাকে। বলা হয়ে থাকে যে প্রোগ্রামার পদ্ধতিগত ভাষাগুলিতে সৎ ত্রুটি তৈরি করতে পারে যেমন কোনও ফাংশন যা ঘটনাক্রমে ডেটাটিকে দূষিত করে cor

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

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

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

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

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

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

তো এই হলো আমার প্রশ্ন:

পদ্ধতিগত প্রোগ্রামিংয়ের কোন সীমাবদ্ধতা ওওপিকে সম্বোধন করে এবং কার্যকরভাবে এই সীমাবদ্ধতাগুলি কার্যকরভাবে কীভাবে সরিয়ে দেয়?

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

PS: ক্রস পোস্ট করেছেন: /programming//q/22510004/3429430


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

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

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

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

উত্তর:


9

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

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

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

টাইপ এক্স 1 টি টির একটি টি টাইপ, টি 1 টি টির একটি টাইপ

পদ্ধতিগত ভাষায় ডেটা এনপ্যাপুলেট করার একটি উপায় যা পদ্ধতিতে f এবং g এর সাথে টাইপ টি থাকে এবং একইভাবে একটি সাবক্লাস টি 1 থাকে:

t_f (t, x, y, z, ...), t_g (t, x, y, ...) t1_f (t1, x, y, z, ...)

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

টাইপ t {d: তথ্য f: ফাংশন g: ফাংশন}

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

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

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

একে অপরের কাছে বার্তা প্রেরণ প্রক্রিয়াকরণের (যা কেবল অপরিবর্তনীয় মানগুলি উল্লেখ করে) একাধিক-থ্রেড প্রসঙ্গে জাভা পদ্ধতি কলগুলির সাথে তুলনা করুন।

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

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


আপনি কি বলছেন যে ওও ভাষাগুলিতে, সংকলক নির্ধারিত ক্রমে পদ্ধতিগুলি ব্যবহার করছে কিনা, বা মডিউলগুলির ব্যবহারে অন্যান্য বিধিনিষেধ পরীক্ষা করতে পারে? কেন "ডেটা এনক্যাপসুলেশন [...] স্বীকৃতি যে পরিবর্তনীয় অবস্থা খারাপ"? আপনি যখন বহুপদী কথা বলছেন, তখন আপনি কি ধরে নিচ্ছেন যে আপনি কোনও ওও ভাষা ব্যবহার করছেন?
বাবু

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

8

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

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

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

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

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

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

উদাহরণ: পুনরুক্তি করা অবজেক্ট অরিয়েন্টেশন

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

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

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

ধরুন আমি ভেক্টর নামে একটি শ্রেণি তৈরি করতে চাই, যার মধ্যে 2-মাত্রিক ভেক্টরকে উপস্থাপন করা হচ্ছে, যার মধ্যে রয়েছে: ভেক্টর সংযোজন, ভেক্টরের আকার এবং সমান্তরালতা methods

function vectorrec () {  
  function createrec(x,y) { return [x,y] }  
  function xcoordrec(v) { return v[0] }  
  function ycoordrec(v) { return v[1] }  
  function plusrec (u,v) { return [u[0]+v[0], u[1]+v[1]] }  
  function sizerec(v) { return sqrt(v[0]*v[0]+v[1]*v[1]) }  
  function parallelrec(u,v) { return u[0]*v[1]==u[1]*v[0]] }  
  return [createrec, xcoordrec, ycoordrec, plusrec, sizerec, parallelrec]  
  }  

তারপরে আমি তৈরি করা ভেক্টরকে আসল ফাংশন নামের ব্যবহার করতে পারি assign

[ভেক্টর, এক্সকর্ড, ইকর্ড, ভিপ্লাস, ভার্সাইজ, ভিপ্যারালাল] = ভেক্টরক্লাস ()

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

আমরা পোলার স্থানাঙ্কিতে আরেকটি সংগ্রহ করতে পারি

function vectorpol () {  
  ...  
  function pluspol (u,v) { ... }  
  function sizepol (v) { return v[0] }  
  ...  
  return [createpol, xcoordpol, ycoordpol, pluspol, sizepol, parallelpol]  
  }  

তবে আমি উভয়ই উদাসীনতার সাথে ব্যবহার করতে চাই। এটি করার একটি উপায় হ'ল সমস্ত মানগুলিতে একটি প্রকারের উপাদান যুক্ত করা একই পরিবেশে উপরের সমস্ত ফাংশনকে সংজ্ঞায়িত করে: তবে আমি প্রত্যাবর্তিত প্রতিটি ফাংশনকে সংজ্ঞায়িত করতে পারি যাতে এটি প্রথমে স্থানাঙ্কের ধরণের পরীক্ষা করে তারপরে নির্দিষ্ট ফাংশনটি প্রয়োগ করে এর জন্য.

function vector () {  
    ...  
    function plusrec (u,v) { ... }  
    ...  
    function pluspol (u,v) { ... }  
    ...  
    function plus (u,v) { if u[2]='rec' and v[2]='rec'  
                            then return plusrec (u,v) ... }  

    return [ ..., plus, ...]  
    }

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

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

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

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

অবজেক্ট ওরিয়েন্টেড সুবিধার এই পুনর্নির্মাণে আমি এখানেই থামব।

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

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

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

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

আমি বিশ্বাস করি এগুলি বোঝার জন্য একটি ভাল বই হ'ল অ্যাবেলসন এবং সুসমান: কম্পিউটার প্রোগ্রামগুলির কাঠামো এবং ব্যাখ্যা


8

আমার মনে হয় ইতিহাসের একটি বিধান রয়েছে।

১৯60০ এর দশকের মাঝামাঝি থেকে 1970-এর দশকের মাঝামাঝি যুগটি আজ "সফ্টওয়্যার সংকট" হিসাবে পরিচিত known আমি 1972 সাল থেকে তার টিউরিং অ্যাওয়ার্ড লেকচারে ডিজকস্ট্রার চেয়ে ভাল এটি আর রাখতে পারি না:

সফ্টওয়্যার সঙ্কটের প্রধান কারণ হ'ল মেশিনগুলি বিভিন্ন আকারের আরও শক্তিশালী হয়ে উঠেছে! একে একে একে একে একে একে একে বলতে হবে না: যতক্ষণ না কোনও মেশিন ছিল ততক্ষণ প্রোগ্রামিং কোনও সমস্যা ছিল না; যখন আমাদের কয়েকটি দুর্বল কম্পিউটার ছিল, প্রোগ্রামিং একটি হালকা সমস্যা হয়ে দাঁড়িয়েছিল এবং এখন আমাদের কাছে বিশাল কম্পিউটার রয়েছে, প্রোগ্রামিং একটি সমানভাবে বিশাল সমস্যা হয়ে দাঁড়িয়েছে।

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

আশ্চর্যজনকভাবে, প্রোগ্রামিং গবেষণায় এটি একটি উল্লেখযোগ্য উর্বর সময় ছিল। 1960 এর দশকের মাঝামাঝি আগে, আমাদের কাছে এলআইএসপি এবং এপি / এল ছিল, তবে "মূল" ভাষাগুলি মূলত প্রক্রিয়াজাত ছিল: ফরট্রান, অলগল, কোবল, পিএল / আই এবং আরও। ১৯60০ এর দশকের মাঝামাঝি থেকে 1970 এর দশকের মাঝামাঝি সময়ে আমরা লোগো, পাস্কাল, সি, ফোর্থ, স্মলটালক, প্রোলোগ, এমএল এবং মডিউল পেয়েছি এবং এটি এসকিউএল এবং এর পূর্বসূরীদের মতো ডিএসএল গণনা করছে না।

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

এটিই প্রসঙ্গটি যেখানে ওওপি এসেছিল। সুতরাং ১৯ 1970০-এর দশকের গোড়ার দিকে ওওপি অনুশীলনে কোন সমস্যাগুলি সমাধান করে আপনার প্রশ্নের উত্তর দেয়, প্রথম উত্তরটি হ'ল ইতিহাসের সেই সময়কালে প্রোগ্রামারগুলির মুখোমুখি হওয়া অনেকগুলি সমস্যা (সমসাময়িক এবং প্রত্যাশিত) উভয়ই সমাধান করতে দেখা গেছে। তবে এটি সেই সময় নয় যখন ওও মূলধারার হয়ে উঠল। আমরা তাড়াতাড়ি পর্যায়ে পৌঁছে যাব।

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

আপনি দেখতে পারেন যে এখানে কয়েকটি গুরুত্বপূর্ণ থিম রয়েছে: একটি সু-সংজ্ঞায়িত সিগন্যালিং প্রোটোকলের ধারণা (আধুনিক পরিভাষায়, একটি ইন্টারফেসে), বাইরে থেকে বাস্তবায়ন আড়াল করার ধারণা (আধুনিক পরিভাষা, গোপনীয়তায়), এবং ধারণা একই ধরণের একাধিক "জিনিস" একই সাথে ঘুরে বেড়ানো (আধুনিক পরিভাষায়, ইনস্ট্যান্টেশন) in

আপনি লক্ষ্য করতে পারেন যে একটি জিনিস অনুপস্থিত, এবং এটি উত্তরাধিকার, এবং এর একটি কারণ রয়েছে।

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

অন্যদিকে, উত্তরাধিকার হ'ল একটি কংক্রিট প্রোগ্রামিং ভাষার বৈশিষ্ট্য। উত্তরাধিকার OOP সিস্টেমগুলি প্রয়োগের জন্য কার্যকর হতে পারে। বা কমপক্ষে, 1990 এর দশক পর্যন্ত এটি ছিল।

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

এই প্রসঙ্গেই অবজেক্ট ওরিয়েন্টেড এনালাইসিস এবং ডিজাইন তৈরি হয়েছিল।

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

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

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

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

সুতরাং আধুনিক উত্তরটি হ'ল: এটি আধুনিক বিশ্বে ইন্টারফেসিংয়ের সমস্যা সমাধান করে। আধুনিক বিশ্ব ওওপি-তে একই কারণে নির্মিত হয়েছিল যে 1880 বিশ্বটি বাষ্পের উপর নির্মিত হয়েছিল: আমরা এটি বুঝতে পারি, আমরা এটি নিয়ন্ত্রণ করতে পারি, এবং এটি কাজটি যথেষ্টভাবে সম্পাদন করে।

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


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

1
অপারেটিং সিস্টেমের অভ্যন্তরীণ সংস্থায় (ইউনিক্সে "ডিভাইস ক্লাস" ধারণাটি মূলত এমন একটি শ্রেণি যেখানে চালকরা উত্তরাধিকারসূত্রে আসে) ওওপি সিমুলা-67 ((সিমুলেশন) এ প্রথম দেখায় । Parnas ' "মানদণ্ড মডিউল মধ্যে decomposing সিস্টেমের মধ্যে ব্যবহার করা হবে অন" , CACM 15:12 (1972), পিপি। 1052-1058, Wirth এর Modula সাতের থেকে ভাষা, "বিমূর্ত ধরনের তথ্য" একটি উপায় বা সমস্ত প্রিকার্সর হয় অন্যান্য।
ভনব্র্যান্ড

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

6

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

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

বলুন আমি পাইথনে একটি কার্ড গেম লিখতে চাই। আমি কীভাবে কার্ডগুলি উপস্থাপন করব?

আমি যদি ওওপি সম্পর্কে না জানতাম তবে আমি সম্ভবত এটি এটি করতে পারি:

cards=["1S","2S","3S","4S","5S","6S","7S","8S","9S","10S","JS","QS","KS","1H","2H",...,"10C","JC","QC","KC"]

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

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

এখন যদি আমি কোন কার্ডটি খেলোয়াড়ের কাছে প্রদর্শন করার উদ্দেশ্যে নিয়ে কাজ করছি তা যদি জানতে চাই তবে আমার এই জাতীয় ক্রিয়াকলাপটি প্রয়োজন:

def card_code_to_name(code):
    suit=code[1]

    if suit=="S":
        suit="Spades"
    elif suit=="H"
        suit="Hearts"
    elif suit=="D"
        suit="Diamonds"
    elif suit=="C"
        suit="Clubs"

    value=code[0]

    if value=="J":
        value="Jack"
    elif value="Q":
        value="Queen"
    elif value="K"
        value="King"

    return value+" of "+suit

কিছুটা বড়, দীর্ঘ এবং অদক্ষ, তবে এটি কাজ করে (এবং খুব অযৌক্তিক, তবে এটি এখানে বিন্দুর পাশে)।

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

cardpositions=( (1,1), (2,1), (3,1) ...)

তারপরে আমি আমার কোডটি লিখি যাতে তালিকায় প্রতিটি কার্ডের অবস্থানের সূচকটি ডেকের মধ্যে কার্ডের সূচকের সমান হয়।

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

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

এখন এটি ওওপি পদ্ধতিতে চেষ্টা করা যাক।

কোডগুলির তালিকার পরিবর্তে, আসুন একটি কার্ড শ্রেণি সংজ্ঞায়িত করুন এবং এটি থেকে কার্ড অবজেক্টের একটি তালিকা তৈরি করুন।

class Card:

    def __init__(self,value,suit,pos,sprite,flipped=False):
        self.value=value
        self.suit=suit
        self.pos=pos
        self.sprite=sprite
        self.flipped=flipped

    def __str__(self):
        return self.value+" of "+self.suit

    def flip(self):
        if self.flipped:
            self.flipped=False
            self.sprite=load_card_sprite(value, suit)
        else:
            self.flipped=True
            self.sprite=load_card_back_sprite()

deck=[]
for suit in ("Spades","Hearts","Diamonds","Clubs"):
    for value in ("1","2","3","4","5","6","7","8","9","10","Jack","Queen","King"):
        sprite=load_card_sprite(value, suit)
        thecard=Card(value,suit,(0,0),sprite)
        deck.append(thecard)

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

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

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


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

অবশ্যই, তবে এটি এক-বাক্য সংস্করণ। এবং আমি শব্দটি বরং একটি মানহীন উপায়ে ব্যবহার করেছি। সম্ভবত "মেমরি পরিচালনা" এর চেয়ে "হ্যান্ডলিং তথ্য" বলা ভাল d
শিলকোট

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

3

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

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

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

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

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

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


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

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

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

2
আপনার উত্তর এবং +1 জন্য ধন্যবাদ। অন্য অভিজ্ঞ প্রোগ্রামার আগে একটি দীর্ঘ সময় কিভাবে গলি তার প্রকল্প অধিক নির্ভরযোগ্য তৈরি ভাগ forums.devshed.com/programming-42/... আমি অনুমান গলি কিছু পেশাদার যারা পদ্ধতিগত পদ্ধতির মধ্যে কিছু সমস্যা সম্মুখীন পারে দ্বারা খুব বুদ্ধিমত্তার পরিকল্পনা করা হয়েছিল।
ব্যবহারকারী31782

2

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

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

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

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

  • কম্পিউটারের সাথে ইন্টারঅ্যাক্টিং নবাগত প্রোগ্রামাররা অবজেক্ট-ওরিয়েন্টড এবং পদ্ধতিগত প্রোগ্রামগুলির বোধগম্যের তুলনা । সুসান উইডেনবেক, ভেনিলা রামালিংম, সুসিলা সরস্ম্মা, সিন্থিয়া এল করিটোর (১৯৯৯)

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

আরো দেখুন:


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

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

1

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

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


0

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


পদ্ধতিগত প্রোগ্রামিংয়ে ডেটা সুরক্ষা সম্পর্কিত সমস্যাগুলি কী কী?
ব্যবহারকারী31782

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

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

যদি আপনি বিশ্বব্যাপী এটি ঘোষণা না করেন তবে এটি কোনও বৈশ্বিক পরিবর্তনশীল নয়।
মানু

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