কার্যবিধি কোড বনাম ওওপি কোড

Question

আমি কার্যনির্বাহী স্টাইলে 13000+ লাইনের পিএইচপি-তে একটি প্রকল্প শেষ করেছি [কারণ আমি এর সাথে খুব পরিচিত, যদিও আমি ওওপি জানি], এবং প্রকল্পটি পুরোপুরি চলছে।

তবে আমি কি এটি ওওপিতে রূপান্তর করব? [ কারণ ওওপি নিয়ে বিশ্বব্যস্ত ]

আমার কোডে ওওপির কোনও বৈশিষ্ট্য প্রয়োজন নেই [মূলত এনপ্যাপুলেশন, উত্তরাধিকার ...]!

তাহলে আমার কি করা উচিৎ?

এবং যদি আমি ওওপিতে রূপান্তর করি তবে আমি কী ধরনের সহায়তা পাব?

Comments

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

— জেফো

আপনার এনক্যাপসুলেশন প্রয়োজন। ওও এটি পাওয়ার এক উপায়; হতে পারে আপনার কাছে অন্যটি রয়েছে যা আপনার পক্ষে কাজ করে তবে একটি উপায় বা অন্য কোনও ক্ষেত্রে আপনাকে কোড নির্ভরতা নিয়ন্ত্রণ করতে হবে।

— মার্সিন

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

— চেষ্টাটি

হ্যাঁ এটা মূল্য ছিল। পুনরায় ব্যবহারযোগ্যতার দরজা খোলা রাখা সর্বদা এটির জন্য মূল্যবান।

— চানি

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

— কামিল তোমাক

Answer 1

আমার কোডে ওওপি-র কোনও বৈশিষ্ট্যের প্রয়োজন নেই

আপনি আপনার নিজের প্রশ্নের উত্তর দিয়েছেন - যদি আপনার এই ক্ষেত্রে ওওপি প্রয়োজন না হয় এবং আপনার প্রকল্পটি কাজ করছে তবে তা রূপান্তর করবেন না।

তবে আপনার নিজের পরবর্তী প্রকল্পের জন্য ওওপি ব্যবহার করা উচিত - তবে এটি যথাযথ হলেই।

পদ্ধতিগত প্রোগ্রামিংয়ের সাথে অভ্যন্তরীণ কিছু নেই - যতক্ষণ না এটি উপযুক্ত জায়গায় ব্যবহার করা হয়।

Comments

সম্মত হওয়ার +1 "আপনার নিজের পরবর্তী প্রকল্পের জন্য ওওপি ব্যবহার করা উচিত"।

— Cary চৌ

হ্যাঁ, যদি এটি সঠিকভাবে কাজ করে তবে এটি ঠিক করবেন না।

— setzamora

আমি বলব, যদি এটি এখন সঠিকভাবে কাজ করছে তবে এটিকে পরিবর্তন করবেন না, তবে পরবর্তী বৈশিষ্ট্যের অনুরোধটি কী হতে পারে তা আপনি কখনই জানেন না।

— জেফো

"আপনার নিজের পরবর্তী প্রকল্পের জন্য ওওপি ব্যবহার করা উচিত", তবে তা বোঝা না গেলে এটি ব্যবহার করবেন না। কিছু জিনিস প্রক্রিয়াগতভাবে আরও ভাল লেখা হয়, কিছু ওওপির জন্য ভাল ফিট হয়। যা উপযুক্ত তা ব্যবহার করুন।

— TMN

@ টিএমএন - এটি নিহিত - আমার এটি স্পষ্ট করা উচিত।

— ChrisF

Answer 2

না এবং কেবল আপনার OOP প্রয়োজন নেই বলে নয়।

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

ওওপি সমস্ত শক্তিশালী নয় প্রচুর জায়গাগুলি যেখানে ওওপি ব্যবহার করা উচিত নয় তাই কেবল এটি ব্যবহার করবেন না কারণ ওওপি হ'ল প্রবণতা।

Comments

"সমাপ্ত কোড" দ্বারা আপনি কী বোঝাতে চেয়েছেন এটি কাজ করে?

— জেফো

@ এফ ও হ্যাঁ স্যার! এটি নিখুঁত :)

— সৌরভ

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

— স্কিথ

দয়া করে "প্রচুর জায়গাগুলি যেখানে ওওপি ব্যবহার করা উচিত নয়" এর বিস্তারিত ব্যাখ্যা করুন।

— ফ্যালকন

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

— এসকে-লজিক

Answer 3

আমার সাধারণ দৃষ্টান্তগুলি গ্রহণ করে (এবং কেন তিনটি প্রধান দৃষ্টান্তের কোনওটিই সঠিক পদ্ধতি বা প্রোগ্রামের ভুল উপায় নয়):

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

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

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

Comments

প্রতিটি ধরণের প্রোগ্রামিং দৃষ্টান্ত বর্ণনা করে এবং কখন / কীভাবে তাদের ব্যবহার করতে হয় তার উদাহরণ প্রদানের দুর্দান্ত উত্তরের জন্য ধন্যবাদ।

— কেভিন পেনো

Answer 4

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

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

Answer 5

যদি আপনার ওওপি-র প্রয়োজনের স্পষ্ট ইঙ্গিত থাকে তবে আপনার প্রজেক্টটিকে ওওপিতে রূপান্তর করা উচিত। এটি ঘটতে পারে এমন সম্ভাব্য পরিস্থিতিগুলি (অন্যদের মধ্যে):

• প্রকল্প স্কেলিং
• দলে আরও বিকাশকারী যুক্ত করা হচ্ছে

এমনকি এই পরিস্থিতিতেও আপনার প্রকল্পটিকে ওওপিতে রূপান্তর করা এখনও প্রয়োজন হবে না।

Comments

ভাল কথা, তবে আপনি কি আমাকে বলতে পারেন যে এটি যদি একটি প্রক্রিয়াগত কোড হয় তবে প্রকল্পটি স্কেল করা বা দলে আরও বিকাশকারী যুক্ত করা কেন সমস্যা হবে?

— সৌরভ

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

— টিমোথি গ্রোট

আমি যখন প্রশ্নটি পড়ি তখন এইটাই আমার মনে আসল। তিনি বলেছেন তিনি কোডের 13 কে লাইন লিখেছেন। আমি আশা করি এটি একবার ব্যবহার করে নষ্ট হবে না। এবং যদি এটি পুনরায় ব্যবহার করতে হয় তবে উওপ একটি আবশ্যক হয়ে উঠবে। অন্যথায় এটি নতুন বিকাশকারীদের জন্য দুঃস্বপ্ন হয়ে উঠবে

— চ্যানী

Answer 6

দুটোই ভাল হতে পারে, দুটোই খারাপ হতে পারে। তবে একজনকে অন্যের মতো দেখতে পুনঃনির্মাণ করা কখনই ভাল ধারণা নয়।

Answer 7

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

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

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

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

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

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

Answer 8

আমার কোডে ওওপির কোনও বৈশিষ্ট্য প্রয়োজন নেই [মূলত এনপ্যাপুলেশন, উত্তরাধিকার ...]!

আপনি সেটা কিভাবে জানেন?

আপনার এই প্রকল্পটি বজায় রাখা দরকার? কোন নতুন বৈশিষ্ট্য পরিকল্পনা আছে? আপনার সাথে আরও বিকাশ ঘটবে এমন অন্য ব্যক্তিরা কি থাকবে? আপনি নিজেকে পুনরাবৃত্তি করেছেন? কোডটি বোঝা কি শক্ত?

উত্তরটি যদি "হ্যাঁ" হয় তবে তার চেয়ে বেশি আপনার ওওপি কঙ্কাল স্থাপন এবং এই পথে চলার কথা চিন্তা করা উচিত।