ওওপি এর স্বাদগুলি রয়েছে যেখানে কিছু বা সমস্ত সলিড নীতিগুলি কোড সাফ করার জন্য বিরোধী?


26

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

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

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

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

সুতরাং, আমার প্রশ্নটি হ'ল:

ওওপি-তে কি এমন কিছু মামলা রয়েছে যেখানে কিছু বা সমস্ত সলিড নীতিগুলি সাফ কোডের জন্য নিজেকে ধার দেয় না?

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

অন্য কেউ আছে? সম্ভবত কিছু ধরণের প্রকল্প বা নির্দিষ্ট লক্ষ্য প্ল্যাটফর্মগুলি কম সলড পদ্ধতির সাথে আরও ভাল কাজ করে?

সম্পাদনা:

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

তুমি আমার প্রকল্প সম্পর্কে জানতে আগ্রহী হন, তাহলে দেখুন এই

সম্পাদনা 2:

আমি ভেবেছিলাম এই প্রশ্নের উত্তর 3 টির মধ্যে একটিতে দেওয়া হবে:

  1. হ্যাঁ, ওওপি নকশার নীতিগুলি রয়েছে যা সলিডের সাথে আংশিকভাবে বিরোধ করে
  2. হ্যাঁ, ওওপি নকশার নীতিগুলি রয়েছে যা সম্পূর্ণরূপে সলিডের সাথে বিরোধ করে
  3. না, সলিড মৌমাছির হাঁটু এবং ওওপি এটির সাথে চিরকালের জন্য আরও ভাল হবে। তবে, সব কিছুর মতো এটি কোনও রোগ নিরাময়ের নয়। দায়িত্ব নিয়ে পান করুন।

বিকল্প 1 এবং 2 সম্ভবত দীর্ঘ এবং আকর্ষণীয় উত্তর তৈরি করতে পারে। অপশন 3, অন্যদিকে, একটি সংক্ষিপ্ত, উদ্বেগজনক, তবে সামগ্রিকভাবে আশ্বাস দেওয়া, উত্তর হবে।

আমরা মনে করি বিকল্প 3 এ রূপান্তর করা হচ্ছে।


আপনি কীভাবে 'ক্লিন কোড' সংজ্ঞা দিচ্ছেন?
গ্র্যান্ডমাস্টারবি

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

1
আমি আপনার গেমের পারফরম্যান্স নিয়ে অন্য যে কোনও কিছুর চেয়ে অনেক বেশি চিন্তিত। যদি না আমরা পাঠ্য-ভিত্তিক গেম সম্পর্কে কথা বলি।
ইউফোরিক

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

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

উত্তর:


20

ওওপি-তে কি এমন কিছু মামলা রয়েছে যেখানে কিছু বা সমস্ত সলিড নীতিগুলি সাফ কোডের জন্য নিজেকে ধার দেয় না?

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

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

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


14
আমি পছন্দ করি তবে মাঝে মাঝে অন্যান্য জিনিসও বেশি ভাল হয় । এটির কাছে এটি "পশুর খামার" অনুভব করে। ;)
হতাশ

12
+1 আমি যখন সলিড নীতিগুলি সন্ধান করেছি, তখন আমি 5 টি "ভাল লাগার" দেখতে পাচ্ছি। তবে তাদের কেউই শীর্ষ ডিআরওয়াই, কেআইএসএস এবং "আপনার উদ্দেশ্যগুলি পরিষ্কার করে না"। সলিড ব্যবহার করুন তবে কিছু সতর্কতা এবং সংশয় দেখান।
user949300

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

সমষ্টিগুলির দক্ষ নকশা বনাম ইন্টিগ্রেশন বিভাজন সম্পর্কে কী? যদি বেসিক "সিক্যুয়েন্স" ইন্টারফেস [যেমন আইইনুমারেবল] এর মতো পদ্ধতি Countএবং এবং [যেমন প্রত্যাবর্তনগুলি জিনিসগুলি "দক্ষ" হবে কিনা ] এর মতো asImmutableবৈশিষ্ট্যগুলি অন্তর্ভুক্ত করে , তবে কারও কাছে একটি স্থির পদ্ধতি থাকতে পারে যা একাধিক ক্রম নেয় এবং সেগুলি একত্রিত করে তাই তারা 'একক দীর্ঘতর ক্রম হিসাবে আচরণ করব। যদি এই ধরনের ক্ষমতাগুলি মৌলিক অনুক্রমের ধরণে উপস্থিত থাকে, এমনকি যদি তারা কেবলমাত্র ডিফল্ট বাস্তবায়নের জন্য শৃঙ্খলাবদ্ধ থাকে তবে একটি সামগ্রিক সেই ক্ষমতাগুলি প্রকাশ করতে সক্ষম হবে ...getAbilitiesCount
সুপারক্যাট

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

13

আমি মনে করি যে আমি ফিনান্স এবং গেম উভয় ক্ষেত্রেই কাজ করেছি তাতে আমার অস্বাভাবিক দৃষ্টিভঙ্গি রয়েছে।

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

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

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

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

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

এটি বলার অপেক্ষা রাখে না যে, "বিপুল সংখ্যক শ্রেণি রক্ষণাবেক্ষণের দুঃস্বপ্ন দেখা দিতে পারে"। তবে এসআরপি সঠিকভাবে ব্যাখ্যা না করা থাকলে আপনি সহজেই এই সমস্যাটি শেষ করতে পারেন।

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

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

ওপেন-ক্লোজড এটির সমালোচক ছাড়া নয়। উদাহরণস্বরূপ, ওপেন ক্লোজড নীতিটি জন স্কিটির পর্যালোচনা দেখুন । আমি এখানে তার যুক্তি পুনরুত্পাদন করব না।

এলএসপি সম্পর্কে আপনার যুক্তিটি অনুমানমূলক বলে মনে হচ্ছে এবং নিরাপদ উত্তরাধিকারের অন্য কোনও রূপের দ্বারা আপনি কী বোঝাতে চেয়েছেন তা আমি সত্যিই বুঝতে পারি না?

আইএসপি কিছুটা নকল এসআরপি বলে মনে হচ্ছে। আপনার ইন্টারফেসের সমস্ত ক্লায়েন্ট কী করবে তা আপনি কখনই অনুমান করতে পারবেন না সে হিসাবে তাদের অবশ্যই একই ব্যাখ্যা করা উচিত। আজকের সমন্বিত ইন্টারফেসটি আগামীকাল আইএসপি লঙ্ঘনকারী। একমাত্র অযৌক্তিক উপসংহারটি হল ইন্টারফেসে একাধিক সদস্য না থাকা।

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

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


1
আপনার কাছে যদি প্রচুর পরিমাণে কনস্ট্রাক্টর প্যারামিটার থাকে তবে এটি আপনাকে এসআরপি লঙ্ঘন করার পরামর্শ দেয়। তবুও একটি ডিআই কনটেইনার যাইহোক বিপুল সংখ্যক কনস্ট্রাক্টর প্যারামিটারগুলির সাথে যুক্ত ব্যথা সরিয়ে দেয়, তাই আমি ডিআইপি-র আপনার বক্তব্যের সাথে একমত নই।
স্টিফেন

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

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

5

এখানে আমার মতামত:

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

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

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


3
+1 প্রায় সংজ্ঞা অনুসারে, একটি উচ্চ নমনীয় সিস্টেমের তুলনায় কম নমনীয় হওয়া উচিত যা কম নমনীয়। নমনীয়তা এনেছে এমন অতিরিক্ত জটিলতার কারণে ব্যয় হয় নমনীয়তা।
অ্যান্ডি

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

3

আমার প্রথম বিকাশের দিনগুলিতে, আমি সি ++ এ একটি রোগুয়ালাইক লিখতে শুরু করি। যেহেতু আমি আমার পড়াশুনা থেকে শিখেছি ভাল অবজেক্ট-ভিত্তিক পদ্ধতিটি প্রয়োগ করতে চেয়েছিলাম, ততক্ষনে আমি গেমের আইটেমগুলিকে সি ++ অবজেক্ট হিসাবে দেখলাম। Potion, Swords, Food, Axe, Javelinsইত্যাদি সব মৌলিক কোর থেকে প্রাপ্ত Itemকোড, নাম, আইকন, ওজন, কাপড় যে ধরনের হ্যান্ডলিং।

তারপরে, আমি ব্যাগের যুক্তি কোড করেছিলাম এবং একটি সমস্যার মুখোমুখি হয়েছি। আমি Itemsব্যাগে রাখতে পারি, তবে তারপরে যদি আমি একটি বাছাই করি তবে কীভাবে জানব যে এটি একটি Potionবা একটি Sword? আমি কীভাবে আইটেমগুলি ডাউনকাস্ট করতে হবে তা ইন্টারনেটে সন্ধান করেছি। রানটাইম তথ্য সক্ষম করার জন্য আমি সংকলক বিকল্পগুলি হ্যাক করেছি যাতে আমার বিমূর্ত Itemপ্রকৃত প্রকারগুলি কী তা আমি জানতে পারি এবং আমি কী অপারেশনগুলি অনুমতি দেব তা জানার জন্য প্রকারগুলিতে যুক্তি পরিবর্তন করতে শুরু করে (উদাহরণস্বরূপ মদ্যপান এড়াতে Swordsএবং Potionsআমার পায়ে রেখে)

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

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


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

4
আপনার অভিজ্ঞতাটি অ্যান্টি-উদাহরণ হিসাবে ব্যবহার করা যেতে পারে। SOLID বা কোনও ধরণের মডেলিং পদ্ধতি ব্যবহার না করে আপনি অকল্পনীয় এবং অবর্ণনীয় কোড তৈরি করেছেন।
ইউফোরিক

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

2
কীভাবে এটি ওওপিতে ক্লিন কোডের বিপরীতে চলছে সলড নীতিগুলির উদাহরণ? এটি আরও একটি ভুল ডিজাইনের উদাহরণের মতো বলে মনে হচ্ছে - এটি ওওপি এর কাছে গোঁড়া!
আন্দ্রেস এফ।

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

3

তাঁর উদ্বেগ ছিল যে ক্লাসের বিশাল সংখ্যক একটি রক্ষণাবেক্ষণ দুঃস্বপ্নে অনুবাদ করবে। আমার মতামতটি হ'ল এটির ঠিক বিপরীত প্রভাব থাকবে।

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

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

আমাদের হাতে কয়েকটি মুখ্য বিমূর্ত (এবং খাঁটি) ইন্টারফেস প্রয়োগ করা হয়েছে সাব টাইপের একটি বোট লোড দ্বারা প্রয়োগ করা, যেমন (ইসিএস সুবিধাগুলি সম্পর্কে কথা বলার প্রসঙ্গে এই চিত্রটি তৈরি করেছে, নীচে বাম মন্তব্যটি উপেক্ষা করুন):

এখানে চিত্র বর্ণনা লিখুন

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

সুতরাং বিকল্পভাবে আমি গেমিং শিল্পে সাধারণত ব্যবহৃত সত্তা-উপাদান সিস্টেম আর্কিটেকচার অন্বেষণ শুরু করি। এটি সবকিছুকে এর মতো হতে পারে:

এখানে চিত্র বর্ণনা লিখুন

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

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

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

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

এখানে চিত্র বর্ণনা লিখুন

ওওপি-তে কি এমন কিছু মামলা রয়েছে যেখানে কিছু বা সমস্ত সলিড নীতিগুলি সাফ কোডের জন্য নিজেকে ধার দেয় না?

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

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

  1. হ্যাঁ, ওওপি নকশার নীতিগুলি রয়েছে যা সলিডের সাথে আংশিকভাবে বিরোধ করে
  2. হ্যাঁ, ওওপি নকশার নীতিগুলি রয়েছে যা সম্পূর্ণরূপে সলিডের সাথে বিরোধ করে।

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

কিশোরী ক্লাস

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

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

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

ইন্টারঅ্যাকশনগুলি

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

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

এটি এরকম কিছু ঘুরিয়ে দিতে পারে (যেখানে চিত্রের প্রতিটি কিছুর কার্যকারিতা রয়েছে এবং স্পষ্টতই বাস্তব-জগতের দৃশ্যে অনেকগুলি, বহুগুণ বস্তুর সংখ্যা থাকবে এবং এটি একটি "ইন্টারঅ্যাকশন" চিত্র, সংযুক্তি হিসাবে নয় একটির মধ্যে বিমূর্ততা থাকবে):

এখানে চিত্র বর্ণনা লিখুন

... এটিতে যেখানে কেবলমাত্র সিস্টেমগুলির কার্যকারিতা রয়েছে (নীল উপাদানগুলি এখন কেবলমাত্র ডেটা, এবং এখন এটি একটি সংমিশ্রণ চিত্র):

এখানে চিত্র বর্ণনা লিখুন

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


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

2

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

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


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

1
যদি KISS এবং YAGNI সর্বদা অগ্রাধিকার গ্রহণ করে তবে আপনার 1 এবং 0 এর মধ্যে কোডিং করা উচিত। এসেমব্লাররা অন্য কিছু যা ভুল হতে পারে। কোনও KISS এবং YAGNI নকশা কাজের অনেক ব্যয়ের মধ্যে দুটি উল্লেখ করে। কোনও খরচ নকশা কাজের সুবিধার বিরুদ্ধে সর্বদা ভারসাম্যপূর্ণ হওয়া উচিত। সলাইডের বেনিফিট রয়েছে যা কিছু ক্ষেত্রে ব্যয় করে। আপনি কখন লাইনটি অতিক্রম করেছেন তা বলার সহজ উপায় নেই।
candied_orange

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

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

1
@ জ্যাক্কসবি - সত্য। এবং ওসিপি এটির মূল ভিত্তিতে ইয়াএগএনআই-র প্রতিপন্ন হয়েছে; তবে আপনি এটি অর্জন করতে যান তবে পরে উন্নতি সক্ষম করার জন্য এটি আপনাকে এক্সটেনশন পয়েন্টগুলিতে ডিজাইন করতে হবে। দুটি আদর্শের মধ্যে একটি উপযুক্ত ব্যালেন্স পয়েন্ট সন্ধান করা হ'ল ... কৌশলপূর্ণ।
জুলস

1

আমার অভিজ্ঞতা:-

বড় ক্লাস বড় হওয়ার সাথে সাথে রক্ষণাবেক্ষণ করা তাত্পর্যপূর্ণভাবে আরও বেশি কঠিন।

ছোট ক্লাসগুলি বজায় রাখা সহজ এবং ছোট শ্রেণীর সংগ্রহ বজায় রাখা অসুবিধা ক্লাসের সংখ্যায় গাণিতিকভাবে বৃদ্ধি পায়।

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


0

দৃ Always়ের 'এস' এর মধ্যে লাইন আঁকানো আমার পক্ষে সবসময় কঠিন মনে হয় এবং (পুরানো ফ্যাশন হতে পারে) কোনও বস্তুর নিজের সমস্ত জ্ঞান থাকা উচিত।

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

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

এবং হ্যাঁ আমি জানি আপনি ডাটাবেসে আপনার জিনিসগুলি বেঁধে রাখতে চান না তবে এটি সমাধানের জন্য আপনি বড় বন্ধকী ক্লাসে একটি সংগ্রহস্থল ইনজেক্ট করতে পারেন।

এ ছাড়া ক্লাসগুলির জন্য ভাল নাম পাওয়া সর্বদা সহজ নয় যা কেবলমাত্র একটি ছোট কাজ করে।

সুতরাং আমি 'এস' সর্বদা একটি ভাল ধারণা হওয়ার বিষয়ে নিশ্চিত নই।

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