অবজেক্ট ওরিয়েন্টেড ল্যাঙ্গুয়েজে অ-অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং [বন্ধ]

Question

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

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

পিএস: আমি এখানে প্রক্রিয়াজাতীয় প্রোগ্রামিংয়ের উপরে আমাকে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের যোগ্যতা বলতে বলছি না।

Comments

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

— কেওসপ্যান্ডিয়ন

আমি এটা কখনও সমস্যা ছিল না। দলটি এবং / অথবা অন্যান্য স্থাপত্যের ভিত্তিতে ভাষাটি প্রায়শই একটি নির্ধারিত সরঞ্জাম ছিল।

সম্ভাব্য সদৃশ কি পদ্ধতিগত প্রোগ্রামিং উপর অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং এর সুবিধা কি?

— ডক ব্রাউন

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

— ডক ব্রাউন

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

— जे

Answer 1

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

আপনার অংশীদারিটি জটিল আকারের আকারে পৌঁছায় যখন জটিল অংশটি সেই সময়ে বিন্দুটি হারাবেন না। অন্যথায় আপনি স্প্যাগেটি কোডের একটি বিশাল গাদা দিয়ে শেষ করবেন।

Comments

যদি সাধারণ "অনুশীলন" প্রোগ্রামগুলি বিকশিত হতে শুরু করে, তবে সর্বোত্তম উপায় হ'ল এটিকে এমনভাবে প্রয়োগ করা যাতে এটি পরে যুক্ত করা যায়। যে ভাগ করে নেওয়ার জন্য আপনাকে ধন্যবাদ :) +1

— ফাইজানরব্বানী

@ কার্লস্মিথ: একেবারে। তবে আমি যখন আমার উত্তরটি লিখেছিলাম, তখন আমি আসল প্রশ্নের পয়েন্ট এবং স্কেলগুলিতে মনোনিবেশ করার চেষ্টা করেছি।

— ডক ব্রাউন

Answer 2

পেশাদার প্রোগ্রামাররা কীভাবে রায় ঘোষণা করবেন যে ওওপিতে যাবেন কিনা? এটা আমার জন্য সত্যিই সহায়ক হবে।

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

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

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

উদাহরণস্বরূপ, এখানে সি #-স্টাইল সিউডোকোডে কার্যকরী শৈলী:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

তবে আপনি এটি আবার কিছু লিখতে পারেন:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

এবং তারপরে কোডটি নিজেই:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

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

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

Comments

বিস্তারিত বিশ্লেষণের জন্য +1। :) আমি এই সম্পর্কে কিছু চিন্তা আছে।

— ফাইজানরব্বানী

পাশে: দয়া করে প্রতিটি উত্তরে "ধন্যবাদ" মন্তব্য পোস্ট করা বন্ধ করুন। আমরা আলোচনার ভিত্তিতে নয়, কেবল প্রশ্ন এবং উত্তরগুলিতে মনোযোগ দিতে পছন্দ করি।

— ফিলিপ কেন্ডল

কার্যকারণের চেয়ে সেই উদাহরণটি আরও জরুরি।

— অরেঞ্জডগ

Cf. শৃঙ্খল অফ দায়িত্ব প্যাটার্ন ।

— এরিক

কেবলমাত্র একটি নোট, আপনি যখন / অন্যথায় বা স্যুইচ স্টেটমেন্টগুলির একগুচ্ছের দিকে ঝুঁকছেন, তখন সর্বদা কোনও ধরণের লুকআপ টেবিল বিবেচনা করার বিকল্প। তাই অন্য উপায় যে পুনর্লিখন লাইনের বরাবর যায় var dict = new Dictionary<string,Action<UserInfo>{ { "email", callEmailFunction }, { "sms", callSmsFunction } }; dict[ action ]( userInfo );(অভি স্ট্যাটিক, ত্রুটি বাদ দেওয়া হ্যান্ডলিং হতে পারে)

— stijn

Answer 3

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

Comments

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

— জর্জিও

কখন থেকে "অবজেক্ট অরিয়েন্টেড" না বলা হয় "পুরাতন স্টাইল"?

— ড্যানিয়েলস্যাঙ্ক