শুধুমাত্র একটি একক (সার্বজনীন) পদ্ধতি সহ ক্লাসগুলি কি সমস্যা?

Question

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

সম্প্রতি, আমি প্রকল্পের জন্য যে নকশাগুলি তৈরি করেছি তার কয়েকটি পর্যালোচনা শুরু করেছি।

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

• ভিডিওকম্প্রেসর (এমন একটি compressপদ্ধতির সাথে যা টাইপের একটি ইনপুট ভিডিও গ্রহণ করে RawVideoএবং টাইপের আউটপুট ভিডিও দেয় CompressedVideo)।
• ভিডিওস্প্লিটার (এমন একটি splitপদ্ধতির সাথে যা টাইপের একটি ইনপুট ভিডিও গ্রহণ করে RawVideoএবং প্রতিটি ধরণের 2 আউটপুট ভিডিওর ভেক্টরকে ফেরত দেয় RawVideo)।
• VideoIndexer (এমন একটি indexপদ্ধতির সাথে যা টাইপের একটি ইনপুট ভিডিও গ্রহণ করে RawVideoএবং টাইপের একটি ভিডিও সূচক প্রদান করে VideoIndex)।

আমি নিজেকে প্রতিটি বর্গ শুরু করতে গিয়ে ঠিক কল করার জন্য এটি VideoCompressor.compress(...), VideoSplitter.split(...), VideoIndexer.index(...)।

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

আসলেই কি এই সমস্যা?

Comments

এটি ভাষার উপর নির্ভর করে। সি ++ বা পাইথনের মতো বহু-দৃষ্টান্তমূলক ভাষায়, এই শ্রেণীর কোনও ব্যবসায় বিদ্যমান নেই: তাদের "পদ্ধতি" ফ্রি ফাংশন হওয়া উচিত।

@ ডেলানন: এমনকি সি ++ তেও আপনি সাধারণত "ওও সক্ষমতার" প্রয়োজন না হলেও মডিউল তৈরির জন্য ক্লাস ব্যবহার করেন। প্রকৃতপক্ষে, মডিউলে "ফ্রি ফাংশন" একসাথে গ্রুপিংয়ের পরিবর্তে নেমস্পেসগুলি ব্যবহার করার বিকল্প রয়েছে তবে আমি এতে কোনও সুবিধা দেখতে পাচ্ছি না।

— ডক ব্রাউন

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

— জানু হুডেক

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

— জানু হুডেক

সম্পর্কিত (প্রায় একটি সদৃশ): প্রোগ্রামারস.স্ট্যাকেক্সেঞ্জারভিউ

— কিউ

Answer 1

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

Comments

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

— পিডিআর

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

— মাইলস রাউট

@ মাইলসআউট: আপনার মন্তব্য আপনাকে প্রশ্নের ভুল বোঝে - ওপি একটি পাবলিক পদ্ধতি সহ একটি ক্লাস সম্পর্কে লিখেছেন, একটি পদ্ধতি নয় (এবং তিনি আসলে একাধিক বেসরকারী পদ্ধতিযুক্ত একটি শ্রেণীর কথা বলেছেন, যেমন তিনি এখানে আমাদের একটি মন্তব্যে বলেছেন)।

— ডক ব্রাউন

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

— রডারবব

@ অ্যান্ডি: প্রশ্নটি ছিল "এটি কি এই সমস্যা" এবং এটি "একটি নির্দিষ্ট ওও সংজ্ঞা অনুসারে নয়" not তদুপরি, প্রশ্নটিতে একেবারে কোনও চিহ্ন নেই ওপি মানে রাজ্যবিহীন শ্রেণি classes

— ডক ব্রাউন

Answer 2

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

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

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

একক ক্ষেত্রে যখন আপনার একক পাবলিক পদ্ধতিতে ক্লাসের প্রয়োজন হতে পারে কারণ এটি একক পাবলিক পদ্ধতির সাথে ইন্টারফেস প্রয়োগ করতে হয়। এটি পর্যবেক্ষক প্যাটার্ন বা নির্ভরতা ইনজেকশন বা যা কিছু হোক না কেন। এখানে এটি আবার ভাষার উপর নির্ভর করে। যে ভাষাগুলিতে প্রথম শ্রেণীর ফান্টেক্টর রয়েছে (সি ++ ( std::functionবা টেমপ্লেট প্যারামিটার), সি # (প্রতিনিধি), পাইথন, পার্ল, রুবি ( proc), লিস্প, হাস্কেল, ...) এই নিদর্শনগুলিতে ফাংশন ধরণের ব্যবহার করা হয় এবং তাদের ক্লাসের প্রয়োজন হয় না। জাভাতে (এখনও, সংস্করণ 8 এ থাকবে) ফাংশনের ধরণ নেই, তাই আপনি একক পদ্ধতি ইন্টারফেস এবং সংশ্লিষ্ট একক পদ্ধতি ক্লাস ব্যবহার করেন।

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

Comments

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

— থেকে আসা

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

— জান হুডেক

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

— জার্গ ডব্লু মিট্টাগ

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

— ডেস্পের্টার

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

— থেকে আসা

Answer 3

একটি উত্সর্গীকৃত শ্রেণিতে একটি প্রদত্ত পদ্ধতি নিষ্কাশন করার কারণ থাকতে পারে। সেই কারণগুলির মধ্যে একটি হ'ল ডিপেন্ডেন্সি ইনজেকশনকে অনুমতি দেওয়া।

কল্পনা করুন যে আপনার কাছে একটি ক্লাস বলা হয়েছে VideoExporterযা শেষ পর্যন্ত কোনও ভিডিও সংকোচন করতে সক্ষম হবে। একটি পরিষ্কার উপায় একটি ইন্টারফেস থাকতে হবে:

interface IVideoCompressor
{
    Stream compress(Video video);
}

যা এভাবে প্রয়োগ করা হবে:

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

এবং এটির মতো ব্যবহৃত:

class VideoExporter
{
    // ...
    void export(Destination destination, IVideoCompressor compressor)
    {
        // ...
        destination = compressor(this.source);
        // ...
    }
    // ...
}

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

Comments

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

— ডক ব্রাউন

@ ডকব্রাউন: ব্যক্তিগত পদ্ধতিগুলি এই প্রশ্নের সাথে প্রাসঙ্গিক নয়। তাদের অভ্যন্তরীণ সহায়ক শ্রেণি বা যাই হোক না কেন রাখা যেতে পারে।

— জানু হুডেক

@ জানহুদেক: বর্তমানে পাঠ্যটি হ'ল "একটি খারাপ বিকল্পের জন্য ভিডিও এক্সপোর্টার থাকা উচিত যার প্রচুর পদ্ধতি রয়েছে" - তবে এটি "খারাপ বিকল্প হতে হবে এমন একটি ভিডিও এক্সপোর্টার থাকা উচিত যেখানে প্রচুর পাবলিক পদ্ধতি রয়েছে"।

— ডক ব্রাউন

@ ডকব্রাউন: এখানে সম্মত হন।

— জানু হুডেক

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

— আর্সেনী মোরজেঙ্কো

Answer 4

এটি এমন একটি চিহ্ন যা আপনি অন্য ফাংশনে আর্গুমেন্ট হিসাবে ফাংশনটি পাস করতে চান pass আমি আপনার ভাষা অনুমান করছি (জাভা?) এটি সমর্থন করে না; যদি এটি হয় তবে এটি আপনার নকশায় এতটা ব্যর্থ নয় যেহেতু এটি আপনার পছন্দের ভাষার ক্ষেত্রে একটি ঘাটতি। ভাষাগুলির সাথে এটি অন্যতম বৃহত্তম সমস্যা যা জোর দিয়ে বলে যে সবকিছু অবশ্যই একটি শ্রেণি হতে হবে।

যদি আপনি বাস্তবে এই ভুল-ফাংশনগুলি পাশ করে না থাকেন তবে আপনি কেবল একটি ফ্রি / স্ট্যাটিক ফাংশন চান।

Comments

জাভা 8-এর পরে, আপনার কাছে ল্যাম্বডাস রয়েছে, তাই আপনি খুব বেশি কার্য সম্পাদন করতে পারেন।

— সিলভিউ বুর্কিয়া

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

— ডোভাল

প্রকাশের তারিখ মার্চ মাসে। এছাড়াও, ইএপি বিল্ডগুলি

— জেডিকে

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

— জুলাই

Answer 5

আমি জানি আমি পার্টিতে দেরি করেছি তবে যেমন মনে হচ্ছে সবাই এই বিষয়টি উল্লেখ করতে ব্যর্থ হয়েছে:

এটি পরিচিত একটি নকশার প্যাটার্ন: কৌশল প্যাটার্ন ।

যখন কোনও সাব-সমস্যা সমাধানের জন্য বেশ কয়েকটি সম্ভাব্য কৌশল রয়েছে তখন কৌশল প্যাটার্ন ব্যবহার করা হয়। সাধারণত আপনি একটি ইন্টারফেস সংজ্ঞায়িত করেন যা সমস্ত বাস্তবায়নের উপর একটি চুক্তি কার্যকর করে এবং তারপরে আপনার জন্য কংক্রিট কৌশল সরবরাহ করতে নির্ভরতা ইনজেকশনটির কিছু ফর্ম ব্যবহার করে ।

এই ক্ষেত্রে উদাহরণস্বরূপ, আপনি হতে পারে interface VideoCompressorএবং তারপর উদাহরণস্বরূপ বিভিন্ন বিকল্প বাস্তবায়নের আছে class H264Compressor implements VideoCompressorএবং class XVidCompressor implements VideoCompressor। ওপি থেকে এটি পরিষ্কার নয় যে একটি ইন্টারফেস জড়িত রয়েছে, এমনকি না থাকলেও, সহজভাবে এটি হতে পারে যে মূল লেখক প্রয়োজনে কৌশল প্যাটার্ন বাস্তবায়নের জন্য দরজা উন্মুক্ত রেখেছিলেন। যা নিজেই এবং খুব ভাল ডিজাইনও।

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

অনেক ক্ষেত্রে কৌশলগত প্যাটার্নটির ফলাফল কেবল একটি একক doStuff(...)পদ্ধতিতে ইন্টারফেস ক্লাসে (যেমন আপনি প্রদর্শিত হচ্ছেন) ফলাফল করে ।

Answer 6

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

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

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

Comments

এই প্রতিটি ফাংশনটির পরিবর্তনের প্রয়োজনীয়তার কারণটি কিছুটা আলাদা, আমি যুক্তি দিয়ে বলছি যে এগুলিকে এই জাতীয় সংযুক্ত করা যেমন এসআরপি লঙ্ঘন করে।

— জুলাই

Answer 7

এটি একটি সমস্যা - আপনি ডেটা না করে ডিজাইনের কার্যকরী দিক থেকে কাজ করছেন। আপনার কাছে যা আছে তা 3 টি স্ট্যান্ডেলোন ফাংশন যা ওও-আইএফআইড হয়েছে।

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

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

সম্পাদনা করুন:

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

string mystring("Hello"); 
mystring.concat("World");

তবে ওপি এটি এইভাবে কাজ করতে চায়:

string mystring();
string result = mystring.concat("Hello", "World");

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

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

Comments

-1, আমি সম্পূর্ণ একমত। প্রারম্ভিক OO ডিজাইন কেবলমাত্র a এর মতো ডেটা অবজেক্টের সাথে কাজ করে Videoএবং কার্যক্ষমতার সাথে এই ধরণের ক্লাসগুলিকে ছাপিয়ে যায় যা প্রায়শই ক্লাস প্রতি> 10 কে এলওসি দিয়ে অগোছালো কোডে শেষ হয়। উন্নত ওও ডিজাইনটি কার্যকারিতাটিকে ছোট ছোট ইউনিটগুলির মতো ভেঙে VideoCompressorদেয় (এবং একটি Videoশ্রেণিকে কেবল একটি ডেটা ক্লাস বা তার জন্য একটি মুখোমুখি হতে দেয় VideoCompressor)।

— ডক ব্রাউন

@ ডকব্রাউন: কোন মুহুর্তে এটি এখন কোনও অবজেক্ট ওরিয়েন্টেড ডিজাইন নয়, কারণ এটি VideoCompressorকোনও বস্তুর প্রতিনিধিত্ব করে না । এতে কোনও ভুল নেই, কেবল অবজেক্ট অরিয়েন্টেড ডিজাইনের সীমা দেখায়।

— জানু হুডেক

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

— gbjbaanb

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

— yjwong

আমি মনে করি এটি একটি Videoশ্রেণি রাখা ঠিক হবে , তবে এটি একটি , ক এবং অন্যান্য সম্পর্কিত ক্লাসের সমন্বয়ে গঠিত , যা ভাল ওও আকারে, খুব সমন্বিত ব্যক্তি শ্রেণি হওয়া উচিত। VideoCompressorVideoSplitter

— এরিক কিং

Answer 8

আইএসপি (ইন্টারফেস পৃথকীকরণ নীতি) বলছেন যে কোন ক্লায়েন্ট পদ্ধতি ব্যবহার করে না উপর নির্ভর করতে বাধ্য করা উচিত নয়। সুবিধাগুলি একাধিক এবং পরিষ্কার। আপনার পদ্ধতির ISP কে সম্পূর্ণ সম্মান করে এবং এটি ভাল good

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

যাইহোক, আপনি বলেছেন

আমি নিজেকে প্রতিটি বর্গ ইনস্ট্যান্ট করতে দেখি

, এই শ্রেণিগুলি পরিষেবাদি বলে মনে হচ্ছে (এবং এভাবে রাষ্ট্রবিহীন)। আপনি তাদের সিলেটলেট তৈরি করার কথা ভেবেছেন?

Comments

সিলেটলেটগুলি সাধারণত অ্যান্টিপ্যাটার্ন হয়। সিলেটলেটগুলি দেখুন : সমস্যা সমাধানের জন্য 1995 সাল থেকে আপনি জানতেন না ।

— জান হুডেক

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

— জানু হুডেক

আমি সিঙ্গেলটন কোনও প্যাটার্ন বা অ্যান্টিপ্যাটার্ন কিনা তা নিয়ে আলোচনা করতে যাচ্ছি না। আমি তার সমস্যার সম্ভাব্য সমাধানের (এটির একটি নামও আছে) পরামর্শ দিয়েছি , এটি খাপ খায় কিনা তা সিদ্ধান্ত নেওয়া তার পক্ষে।

— ডায়োগমটাসিস

আইএসপি প্রাসঙ্গিক কিনা বা না, এই বিষয়ে প্রশ্নটির বিষয় হ'ল "কেবলমাত্র একক পদ্ধতিতে ক্লাস করা কি সমস্যা?", এর বিপরীতে অনেক পদ্ধতি রয়েছে এমন একটি শ্রেণি, যা আপনি যখনই তৈরি করেন তখনই সমস্যা হয়ে দাঁড়ায় ক্লায়েন্ট সরাসরি তার উপর নির্ভর করে ... ঠিক রবার্ট মার্টিনের জেরক্স উদাহরণটি তাকে আইএসপি গঠনে নিয়ে গিয়েছিল।

— ডায়োগমটাসিস

Answer 9

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

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