অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং কি সত্যই মডেলটিকে রিয়েল ওয়ার্ল্ড করে? [বন্ধ]


52

আমি দেখেছি এটি প্রায়শই পুনরাবৃত্তি হয়েছে অবজেক্ট ভিত্তিক প্রোগ্রামিং বাস্তব বিশ্বের মডেলিংয়ের উপর ভিত্তি করে তবে এটি কি?

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

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

সুতরাং: অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংগুলি কি সত্যিকারের বিশ্বের মডেল করে?


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

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

1
@ দিপনমহেতা, যুক্তিটি হ'ল ওওকে বাস্তব বিশ্বের মডেলিং হিসাবে বর্ণনা করা অবজেক্ট অরিয়েন্টেড প্রোগ্রামিংয়ের হৃদয়কে বাদ দেয়। সমস্ত প্রোগ্রামিং কৌশলগুলি আসল বিশ্বের মডেল করে (এক ডিগ্রি বা অন্য এক দিকে), এটিই ওওকে অনন্য করে তোলে।
উইনস্টন ইওয়ার্ট

@ উইনস্টোনওয়ার্ট ওয়েল, সত্যিই ওকে আলাদা করে modeling the real worldনাও দিতে পারে । হতে পারে. তবে আমি অবশ্যই বিশ্বাস করি না যে আপনি এটি ও তেও ব্যর্থ হবেন। কোন দৃষ্টান্ত বা কৌশলটিকে আপনি ওওর চেয়ে ভাল বলে মনে করেন?
দিপান মেহতা

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

উত্তর:


50

না কোনভাবেই না.

তবে এটি এমন একটি পদ্ধতি যা ডেটা স্ট্রাকচারের সাথে কাজ করে এমন কিছু পদ্ধতির পাশাপাশি জটিল ডেটা স্ট্রাকচারগুলি ধরে রাখার জন্য একটি দুর্দান্ত বিমূর্ততা তৈরি করার অনুমতি দেয়।


দুর্দান্ত সংক্ষিপ্ত উত্তর। সংজ্ঞা অনুসারে আপনি মডেলটিতে কিছু বিবরণ হারাবেন।
ম্যাথঅ্যাটাক

দুঃখিত, আমি এই উত্তরটি পছন্দ করি না। ওওপি দিয়ে আপনি বাস্তব বিশ্বের মডেল করতে পারেন (কিছু দিক) great
ক্লাইমে

33

মডেলগুলি, যে কোনও ধরণের, পুরো বিশ্বের নয়, আসল বিশ্বের মডেল দেয় না।

তারা নির্বাচিত অংশগুলি মডেল করে , সেগুলি হাতের আবেদনের সাথে প্রাসঙ্গিক।

আপনি যে বিষয়ে কথা বলছেন (পর্যবেক্ষক, পরিচালক, কারখানা ইত্যাদি ...) সেগুলি অবকাঠামোগত অধিকার এবং জেদর মতো প্রয়োজনীয় ক্রিয়াকলাপকে সমর্থন করতে আপনাকে সহায়তা করতে পারে infrastructure


15
আমি যুক্তি দিয়ে বলব যে "মডেলিং" এর অর্থ ইতিমধ্যে কিছু দিক নকল করা (অন্যকে ছাড়ার সময়)। সেই অর্থে, ওও বাস্তব বিশ্বের মডেলিংয়ের অনুমতি দেয়।
ট্যামস্ সেজেলি

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

@MichaelShopsin - আপনি আপনার মন্তব্যে হতে চাওয়ার কথা বলছেন কি প্রশ্ন বদলে আমার উত্তর?
ওদেড

@ আমি আপনার উত্তরটি পছন্দ করি; আমার মন্তব্যটি "মডেল নির্বাচিত অংশগুলি" এর সম্প্রসারণ। ও ও নমুনাগুলি প্রচুর সমস্যার মডেল, এটি নিশ্চিত হওয়া উচিত যে তারা সমস্যাটি হাতে রয়েছে কিনা।
মাইকেল শপসিন

31

কোনও মডেল কী, যাইহোক:
একটি মডেল হ'ল একটি বাস্তব উপস্থাপনা যা বাস্তব বিশ্বের সিস্টেম বা ইভেন্টের কাজগুলি ব্যাখ্যা করার জন্য ব্যবহৃত হয়

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

অবশ্যই হ্যাঁ

বাস্তব বিশ্বের সাথে সঠিকভাবে মিলে যাওয়ার জন্য মডেলটি তৈরি করা প্রায় অসম্ভব।

আমার কি সবসময় বাস্তব বিশ্বের ঠিক পরে সফ্টওয়্যারটি মডেল করতে হবে?

কোন

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

অবশ্যই এমন সত্ত্বা রয়েছে যা সত্যই বিদ্যমান নেই, তবে কেবলমাত্র মডেলিংয়ের মাধ্যমে আমরা বাস্তবে ভাল ধারণা দিতে পারি can


9
" একটি মডেল কি? " প্রাইভেটের একটি কৃপণ ছোট্ট গাদা। তবে যথেষ্ট কোড, আপনার কাছে আছে!
বেন ব্রোকা

আমি মনে করি আপনার শেষ পয়েন্টটি অদম্য সম্পর্কগুলি ক্যাপচার করে। কখনও কখনও বস্তুগুলি বাস্তব বিশ্বে বিদ্যমান থাকে, আমরা কেবল সেগুলি দেখি না।
ম্যাথঅ্যাটাক

19

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

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

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


+1 এরকম দুর্দান্ত এবং অতিরিক্ত-সাধারণ দৃষ্টিকোণ। এটি ভাগ করে নেওয়ার জন্য ধন্যবাদ! আমি ভাবছি আপনি কি এটি একটি বই তৈরি করেন বা না? আমি অবশ্যই বইটি পড়তে পছন্দ করব।
মাহদী

8

... অবজেক্ট-ওরিয়েন্টড সিনট্যাক্স দিয়ে প্রকাশ করা যায় তার চেয়ে বিশ্ব সমৃদ্ধ।

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

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

উদ্ধৃতি সূত্র: ভিক্টোরিয়া লিভস্টিজ, প্রোগ্রামিংয়ে দ্য নেক্সট মুভ


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

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

13
this.MoveTo(Environment.Find<Bathroom>().OrderBy(b=>b.Distance(this)).First()); this.SitOn(Environment.Find<Toilet>().Where(t=>!t.IsOccupied).OrderBy(t=>t.Distance(this)).First().Component<Seat>()); this.DiscardWaste(HumanWasteType.All);
অ্যাডাম রবিনসন

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

1
ওওর সিকোয়েন্সিং বা রাজ্যের কোনও ধারণা নেই । এমন একটা বাজে কথা ওওপিতে ক্রমবিন্যাস এবং রাজ্য সম্পর্কে কোনও ধারণা নেই? ও
ক্লাইমে

5

হ্যাঁ, ওও প্রায়শই বাস্তব বিশ্বের সত্ত্বাকে মডেল করতে ব্যবহার করা যেতে পারে।

এমনকি আমার ব্যবসায়িক স্তরে আমি পর্যবেক্ষক, পরিচালক, কারখানা ইত্যাদির মতো ক্লাস পেয়েছি যা বাস্তব বিশ্বের বিষয় নয়।

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

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

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

এর অর্থ এই নয় যে ওওকে বাস্তব বিশ্বের মডেল করতে হবে, বা এটি সর্বদা সর্বাধিক অনুকূল সমাধান নয় is সরলভাবে, এটি থাম্বের একটি নিয়ম হিসাবে "ওও প্রকৃত বিশ্বের মডেলিং" সঠিক ধারণা দেয় sense


5

আপনি কোন বাস্তব বিশ্বের কথা বলছেন তা নির্ভর করে depends

হোর্হে লুইস বোর্জেস "Tlön, Uqbar, Orbis Tertius" একটি গল্প লিখেছিলেন, যেখানে বাসিন্দা জনগণের মধ্যে একটি মনে হয় তাদের বাস্তব জগতটি বেশ আলাদাভাবে উপলব্ধি করেছে:

[...] কাল্পনিক ত্লান [...] বার্কেলিয়ান আদর্শবাদের চরম রূপ ধারণ করে, বিশ্বের বাস্তবতা অস্বীকার করে। তাদের পৃথিবী "মহাকাশে বস্তুর সংমিশ্রণ হিসাবে নয়, স্বতন্ত্র ক্রিয়াকলাপের একটি ভিন্নধর্মী সিরিজ হিসাবে" বোঝা যায়। টিলনের একটি কল্পনা করা ভাষায় বিশেষ্য নেই। এর কেন্দ্রীয় ইউনিটগুলি হ'ল "মনোসিলাবিক প্রত্যয় বা উপসর্গগুলির দ্বারা যোগ্য নৈর্ব্যক্তিক ক্রিয়া যা অ্যাডওয়্যারের জোর রয়েছে।" বোর্জেস "চাঁদ জলের উপরে উঠেছিল" এর একটি Tlönic সমতুল্য তালিকাবদ্ধ করে: hlör u fang axaxaxas mlö, যার অর্থ আক্ষরিক অর্থে "wardর্ধ্বমুখী প্রবাহিত এটি চাঁদের পিছনে"। [...] টিলনের আর একটি ভাষায়, "মৌলিক ইউনিট ক্রিয়া নয়, তবে মনোসিলাবিক বিশেষণ," যা দুটি বা ততোধিক সংমিশ্রণে বিশেষ্য গঠন করে: "চাঁদ" পরিণত হয় "বৃত্তাকার এয়ার-লাইট অন" অন্ধকার "বা"

( বইটি সম্পর্কে উইকিপিডিয়া শিল্পকলার কপি করা )

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

সুতরাং, আপনার প্রশ্নের আমার উত্তরটি: আপনি কোন আসল বিশ্বের কথা বলছেন? এবং কিভাবে?


"বাস্তবের কাঠামোর যে অনুভূতিটি আমরা নিজেই যে ভাষায় কথা বলি তার উপর নির্ভর করে, এটি প্রাকৃতিক বা প্রোগ্রামিং ভাষা হোক"। এটাই সত্য!
ক্লাইমে

4

আমি তৈরি কিছু কিছু বস্তু বাস্তব জগতের সামগ্রীর মডেলিংয়ের সময়, প্রাক-ওওপি কোডটি কি একই রকম করবে না?

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


আমি মনে করি আপনার মানে প্রক্রিয়াগত কার্যক্ষম নয়।
উইনস্টন ইওয়ার্ট

হ্যাঁ, সঠিক আমি এটি পরিবর্তন করব
Wheresrhys

3

আমি এটি প্রত্যক্ষরূপে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং বাস্তব বিশ্বের মডেলিংয়ের উপর ভিত্তি করে দেখেছি, তবে তা কি?

হ্যাঁ. এখানে জোর উপর ভিত্তি করে । ওওপি বাস্তব জগতকে মডেল করে না (যদি তা ঘটে তবে ঘটনাক্রমে) এবং এমনটি হওয়ার কথা নয়। ওওপি যা করে তা হ'ল আমাদের বাস্তব জগতকে মডেল করার জন্য প্রোগ্রামিং সমস্যাগুলিকে মডেল করার অনুমতি দেওয়া: সত্তার একটি সিস্টেম হিসাবে যা তাদের আচরণের বিমূর্ততার মাধ্যমে সংজ্ঞায়িত হয়।


3
হ্যাঁ - তাই এটি বাস্তব বিশ্বের মডেলিংয়ের উপর ভিত্তি করে না, তাই না ?
বাম

3

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


3

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


2

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

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

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

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


2

আমি এটি প্রত্যক্ষরূপে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং বাস্তব বিশ্বের মডেলিংয়ের উপর ভিত্তি করে দেখেছি, তবে তা কি?

আমার কাছে মনে হয় এটি ব্যবসায়ের স্তরটির বাইরের কোনও কিছুর ক্ষেত্রে সত্য নয়।

না As

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

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

অতএব, মডেলগুলির "রিয়েল ওয়ার্ল্ড" কে পুরোপুরি উপস্থাপন করার চেষ্টা করা (বা ভান করা) উচিত নয়।

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

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

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

ওওপি এবং অ-ওওপি-র মধ্যে সবচেয়ে বড় পার্থক্য হ'ল ওওপি কোডের সাথে ডেটা বেঁধে দেয়। সুতরাং কোড কোডিং এর চেয়ে বরং:

verb(noun);

পরিবর্তে আমরা এটি করি:

noun->verb();

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


2

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

না সম্পূর্ণরূপে.

বাস্তব বিশ্বের ভাল, আমরা বাস্তব সমস্যার মুখোমুখি। আমরা এই দৃষ্টান্তটি ব্যবহার করে এই সমস্যাটি সমাধান করতে চাই যা আমরা যে মডেলটি তৈরি করতে চাই তার প্রতিরূপ তৈরি করে।

উদাহরণস্বরূপ, যদি কোনও শপিং কার্ট অ্যাপ্লিকেশনটিতে সমস্যা ছিল তবে আমাদের মতো বিভিন্ন সত্ত্বা রয়েছে

  1. পণ্য যা একটি বিমূর্ত পদ যার একাধিক সদস্যের মতো বই, গ্যাজেটস, গাড়ি যা আবার বিভক্ত হতে পারে।

  2. (বিক্রয় বিক্রয়) ট্যাক্সের মানদণ্ডটি সফ্টওয়্যারটি নীতিমালার ভিত্তিতে পরিবর্তনের শিকার হওয়ার কারণে সফ্টওয়্যারটি কোথায় প্রয়োগ করা হবে তার উপর নির্ভর করবে।

  3. করের মানদণ্ডের সাথে সাথে পণ্যটি আমদানি করা হয়েছিল কিনা তার ভিত্তিতে কর বিবেচনা করা হয়।

  4. ব্যবহারকারীর একটি শপিং কার্ট থাকতে পারে যার পণ্যগুলির তালিকা ইত্যাদি রয়েছে has

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


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

2

আমি মনে করি আপনি খুব প্রসেসিক, historicalতিহাসিক, বিবৃতি হওয়ার উদ্দেশ্যে যা লক্ষ্য করেছেন তাতে আপনি খুব বেশি পড়ছেন। ওও প্রোগ্রামিং, ক্লাস, পলিমার্পিজম, ভার্চুয়াল ফাংশন ইত্যাদির অনেকগুলি ধারণা ১৯ Sim০ এর দশকে (http://en.wikedia.org/wiki/Simula) সিমুলা ভাষায় চালু হয়েছিল। নামটি থেকে বোঝা যায়, সিমুলা সিমুলেশন লেখার জন্য একটি ভাষা হিসাবে ডিজাইন করা হয়েছিল। Historতিহাসিকভাবে, হ্যাঁ, ওও ধারণাগুলি "বাস্তব বিশ্বের" মডেল করার প্রয়াসে প্রবর্তিত হয়েছিল। তারা অন্য শৈলীর চেয়ে বেশি সাফল্য পাবে কিনা তা বিতর্কের বিষয়।


2

আমি তৈরি কিছু কিছু বস্তু বাস্তব জগতের সামগ্রীর মডেলিংয়ের সময়, প্রাক-ওওপি কোডটি কি একই রকম করবে না?

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

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

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

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

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

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

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


1

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

বিষয়টি নিয়ে উইকিপিডিয়ায় নিবন্ধটি ভালভাবে জবাব দেয়:

রিয়েল-ওয়ার্ল্ড মডেলিং এবং সম্পর্ক
ওওপি ডিজিটাল অংশগুলির সাথে বাস্তব-বিশ্বের বস্তু এবং প্রক্রিয়াগুলিকে সংযুক্ত করতে ব্যবহার করা যেতে পারে। তবে সকলেই একমত নন যে ওওপি সরাসরি বাস্তব-বিশ্বের ম্যাপিংকে সহায়তা করে (নেতিবাচক সমালোচনা বিভাগটি দেখুন) বা সেই বাস্তব-বিশ্বের ম্যাপিং এমনকি উপযুক্ত লক্ষ্য; বার্ট্রান্ড মেয়ার অবজেক্ট-ওরিয়েন্টেড সফটওয়্যার কনস্ট্রাকশনে [২১] যুক্তি দেখিয়েছেন যে একটি প্রোগ্রাম বিশ্বের মডেল নয় বরং বিশ্বের কিছু অংশের একটি মডেল; "বাস্তবতা দুইবার অপসারণ করা হয় কাজিন"।

জিনিসটি হ'ল যদি না আপনার প্রোগ্রামটি মহাবিশ্বের সিমুলেশন হয় তবে আপনি কেবল আসল বিশ্বের অংশগুলিই যত্নবান হন - তাই "মডেল"। মডেলগুলির জন্য এটিই, তারা আপনাকে কাঠামো এবং কার্যকারিতা দেয় যা আপনার প্রদর্শন করা দরকার।

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

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


1

এর যথাযথ প্রসঙ্গে অবজেক্ট-ওরিয়েন্টেশন সম্পর্কে চিন্তা করার জন্য, আসুন বিমূর্তির একটি স্তর বাড়ানো যাক এবং সাধারণভাবে প্রোগ্রামিং সম্পর্কে কথা বলি, ঠিক আছে?

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

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

এখনও অবধি, এর কোনটিই ওও সম্পর্কে কথা বলেনি, আছে কি? এখন এটি করা যাক।

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

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

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

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

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


1

ওওপি প্রোগ্রামিং দৃষ্টিকোণ থেকে একটি দুর্দান্ত মডেল তৈরি করে, এটি বাস্তব বিশ্বের প্রতিফলিত করে না।

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

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

আর একটি উদাহরণ হ'ল ঘেরকিন ভাষার উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে ব্যবহারকারী গ্রহণযোগ্যতা পরীক্ষার কাঠামো ।

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

0

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

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