সোলিড নীতি প্রোগ্রামিং

সময়ের সাথে সাথে আমি সলিডের দুটি অংশ বুঝতে পারি - "এস" এবং "ও"।

"ও" - উত্তরাধিকার এবং কৌশল প্যাটার্নের সহায়তায় আমি ওপেন ক্লোজড নীতি শিখেছি।

"এস" - আমি ওআরএম শিখার সময় একক দায়িত্বের নীতি শিখেছি (জেদী যুক্তিটি ডোমেন অবজেক্ট থেকে সরিয়ে নেওয়া হয়েছে)।

একইভাবে, সলিডের অন্যান্য অংশগুলি ("এল", "আমি" এবং "ডি") শেখার সেরা অঞ্চল / কাজগুলি কী কী?

তথ্যসূত্র

object-oriented solid

— LCJ
সূত্র

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

ওআর-ম্যাপারগুলি একক দায়িত্বের নীতি নয়, উদ্বেগের বিভাজনের জন্য ভাল। পার্থক্যগুলির আলোচনার জন্য এই পোস্টার প্রোগ্রামার.সটাকেক্সচেঞ্জ / প্রশ্নগুলি / 155628/… দেখুন।

— ডক ব্রাউন

বাস্তব জগতে উদাহরণ blog.gauffin.org/2012/05/...

— LCJ

@ জারোদরবারসন হ্যাঁ, এজন্য তাদের সাবধানে নির্দেশিকা হিসাবে উল্লেখ করা হয়েছে । বাকি নীতিগুলিও ভুলে যাবেন না: adamjamesnaylor.com/2012/11/12/… (মোট 11)

— অ্যাডাম

@ অ্যাডামনাওলারের লিঙ্কটি এখন ৪৪৪ তম, এটি অ্যাডামজেমসনেলোর.কম

— পোস্টে

উত্তর:

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

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

মতামত হিসাবে ইঙ্গিত হিসাবে, আরও একটি খুব ভাল পিডিএফ পড়া আছে - পাবলো এর সলিড সফ্টওয়্যার বিকাশ ।

তদতিরিক্ত, কয়েকটি ভাল বই রয়েছে যা আরও বিশদে সোলিড নীতিগুলি বর্ণনা করে - সলড সফটওয়্যার বিকাশ সম্পর্কিত গুড বুক ।

প্রতিটি নীতির জন্য একটি সংক্ষিপ্ত সংক্ষিপ্তসার সম্পাদনা করুন এবং মন্তব্যগুলি:

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

কোডপ্লেক্সের একটি দরকারী উত্স হিসাবে মন্তব্যে উল্লেখ করা হয়েছিল, উদাহরণ হিসাবে উদাহরণটি SOLID এ অন্তর্ভুক্ত করা হয়েছে

— ই এল ইউসুবভ
সূত্র

আমি নিম্নলিখিত নিবন্ধগুলির সংগ্রহটি খুব দরকারী বলে খুঁজে পেয়েছি: lostechies.com/wp-content/uploads/2011/03/…

— স্ক্রোগ 1

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

— চাকরী

যেহেতু এখানে লস্টেচিজ নিবন্ধগুলি উল্লেখ করা হয়েছিল সেখানে এই সলাইডেক্স্যাম্পলস কোডপ্লেক্স.কম ( লস্টেচির উপর ভিত্তি করে )ও রয়েছে

— dark

আমি পাবলো ইবুকের অন্যতম অবদানকারী ছিলাম। আমি আনন্দিত যে লোকেরা এখনও এটি দরকারী বলে মনে করে। :)

— শন চেম্বারস

+1000000 যদি আমি আপনার উন্মুক্ত

— নীতিটির

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

— StriplingWarrior
সূত্র

+1 এটি খুব সত্য। এমনকি কখনও কখনও (ইমো) খুব কঠোর 'ইউনিট পরীক্ষা কেবল একটি জিনিস পরীক্ষা করা উচিত' নিয়মটি মেনে চলতে হবে না: আপনি যদি কয়েক মিনিটের মধ্যে কোনও শ্রেণির জন্য শালীন পরীক্ষার স্যুটটি নিয়ে আসতে না পারেন তবে এটি লঙ্ঘন করে আমি ও D এবং সম্ভবত alfabet বাকি পাশাপাশি

— stijn

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

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

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

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

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

— m3th0dman
সূত্র

লিসকভের উপর দুর্দান্ত ব্যাখ্যা। :)

— জন কর্সনেস