SOLID নীতিগুলি বনাম YAGNI


43

সলিড নীতিগুলি কখন ইয়াগনি হয়?

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

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

মতামত জিজ্ঞাসা করা হিসাবে:


শিরোনামও হওয়া উচিত নয় SOLID principle vs YAGNI?
নেকড়ে

2
@ ওল্ফ: এটি বহুবচন "সলিড (একক দায়বদ্ধতা, ওপেন-ক্লোজড, লিসকোভ প্রতিস্থাপন, ইন্টারফেস বিভাজন এবং নির্ভরতা বিপর্যয়) হ'ল রবার্ট সি মার্টিনের প্রথম প্রথম পাঁচটি মূলনীতির জন্য মাইকেল ফেয়ার্স দ্বারা প্রবর্তিত একটি স্মৃতিচারণ সংক্ষিপ্ত বিবরণ) 2000s যা অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং এবং ডিজাইনের পাঁচটি মূল নীতিগুলির জন্য দাঁড়িয়েছে ""
লগ্ক

উত্তর:


55

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

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

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

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


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

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

YAGNI and SOLID coexistভাল উপসংহার যদিও এটি একটি ভাল সূচনা পয়েন্ট হতে পারে
ওল্ফ

মনে হয় কখনও কখনও একটি কুঁচকির প্রয়োজন হয়। আপনার বিস্তৃতকরণের স্তর বনাম নদীর গভীরতানির্ণয় থামতে শুরু করে কোথায় শুরু হবে তা জানতে আপনাকে প্রচুর পরিবর্তন দেখতে শুরু করতে হবে know
জননী

19

প্রথমে এবং সর্বাগ্রে সমস্যাটি নিয়ে ভাবুন। আপনি যদি YAGNI বা SOLID এর নীতিগুলি অন্ধভাবে প্রয়োগ করেন তবে পরে নিজেকে আঘাত করতে পারেন। আমি আশা করি এমন কিছু যা আমরা সকলেই বুঝতে পারি তা হ'ল কোনও "এক" ডিজাইন পদ্ধতির নেই যা সমস্ত সমস্যার সাথে খাপ খায়। আপনি তার প্রমাণ দেখতে পাচ্ছেন যে যখন কোনও দোকান "একটি আকার সবই ফিট করে" হিসাবে বিজ্ঞাপনিত একটি টুপি বিক্রি করে তবে এটি আপনার মাথার সাথে খাপ খায় না। এটি হয় খুব বড় বা খুব ছোট।

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

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

সলিড কীভাবে আমরা সেতুর টুকরোগুলি একসাথে যথাযথভাবে মাপসই করে তা নিশ্চিত করি এবং সময়ের সাথে সাথে বজায় রাখা যায় with আপনি কাঠের ব্রিজের পাশাপাশি সিলিড নীতিগুলি ইস্পাত পুনরায় বলপূর্বক কংক্রিট ব্রিজ প্রয়োগ করতে পারেন।

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


হ্যাঁ, সম্মত হোন .. এমন কোনও রূপালী-বুলেট পদ্ধতির নেই যা প্রতিটি দৃশ্যের সাথে খাপ খায়।
EL Yusubov

আপনার make sure the pieces of the bridge fit togetherএখন পর্যন্ত হিসাবে হিসাবে স্পষ্ট না can be maintained over time
নেকড়ে

মূলত, সলিড আপনাকে সেই কাঠের সেতুর পূর্ণ মাইল স্টিল সেতুর পুরো মাইক্রোসেট প্লাটুনকে পুরো পুনর্লিখন না করে বা হ্যাকের পরে কেবল হ্যাকের সাথে স্টিক করে সমর্থন করতে সক্ষম করতে সক্ষম করবে।
সারা

@ কাই, এটি একটি মিথ্যা ভিত্তি। আপনার যদি 1 মাইল বিস্তৃত একটি সেতু প্রয়োজন হয় তবে আপনি 1 মাইল বিস্তৃত একটি সেতু ইঞ্জিনিয়ার করুন। আপনার যদি 5 ফুট দৈর্ঘ্যের একটি সেতু প্রয়োজন হয় তবে আপনি 5 ফুট দীর্ঘ একটি সেতু তৈরি করুন। আমাকে ভুল করবেন না, সলিড নীতিগুলি খুব সহায়ক, তবে সমস্যাটির জন্য কোন নীতিগুলি অপরিহার্য নয় তা জানতে তাদের আরও বোধ করা দরকার। 10 এর মধ্যে 9 বার, অতিরিক্ত মাইল কখনও প্রয়োজন হয় না।
বেরিন লরিটস

@ বেরিনলরিটস এই কারণেই আমি সম্মত হই যে আপনার যদি 5 ফুট প্রয়োজন হয় তবে আপনি 5 ফুট তৈরি করেন তবে আপনি 2x4 সেকেন্ডের মাটিতে দু'ভাগ চাপ দিয়ে 5 ফুট তৈরি করবেন না। আপনি যা প্রয়োজন তা করেন এবং আপনি এটি ভালভাবে করেন। (যদিও উপমাটি এক ধরণের বিচ্ছিন্ন হয়ে
সারা

9

সলিড নীতিগুলির প্রয়োজন হয় না যখন এটি একটি ফেলা-দূরে অ্যাপ্লিকেশন হয়; অন্যথায় তাদের সর্বদা প্রয়োজন হয়।

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

এটি কোনও গাড়ী শ্রেণীর মধ্যে পার্থক্য যার সুনির্দিষ্টভাবে নির্ধারিত সীমানা (SOLID) এবং একটি গাড়ী শ্রেণীর মধ্যে যা গ্রাহকের কাছে জিজ্ঞাসা করার আগে তার আত্ম-নিরাময়ের ক্ষমতা (YAGNI) রয়েছে।


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

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

প্রায়শই বার অ্যাপ্লিকেশন নিক্ষেপ করা হয় না।
তুলাইনস কর্ডোভা

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

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

4

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

সম্প্রতি আমি একক দায়িত্বের নীতিটি কখন ব্যবহার করা উচিত তা বোঝার চেষ্টা করছিলাম ( আমি এখানে যা এলাম তা এখানে ))

আশাকরি এটা সাহায্য করবে!


2

আইনস্টাইনের প্রতি দায়বদ্ধ একটি উদ্ধৃতি রয়েছে (সম্ভবত কোনও বাস্তবের পরিবর্তনে ):

"সবকিছু যতটা সম্ভব সহজ করা উচিত, তবে কোনও সহজ নয়” "

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


ভাল কথা: you never know if a program is 'throw-away' code- ভাল, আমি মনে করি বিকল্প ধারণাটি তেমন ভাল নয়।
নেকড়ে

@ ওল্ফ: হ্যাঁ, আমি যে ধাপগুলিকে আমার সেরা বলে মনে হচ্ছে তার ক্রমটি প্রসারিত করছিলাম ('প্রথমে এটি সম্ভব করুন, তারপরে এটি সুন্দর করুন, তারপরে এটি দ্রুত করুন' স্লোগান সংক্ষেপিত) তবে আমি ভেবেছিলাম ... ইয়াগনি :)
লগ্ক

1

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

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

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


0

আমি মনে করি আপনার YAGNI শুরু করা উচিত এবং যখনই কোনও প্রয়োজন হবে, এটি সলিড করুন।

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

আপনি সময় নষ্ট করছেন না কারণ আপনাকে যেভাবেই কাজটি করতে হবে (শুরুতে) এবং যেখানেই এটি প্রয়োজন হয় আপনার কোডটি সুন্দর এবং পরিপাটি করা দরকার।

আমার ধারণা আপনি একে সলিডের অলস মূল্যায়ন বলতে পারেন।


এইচএম, পোস্টটি অপ্রয়োজনীয় সম্পর্কে আপনার বক্তব্যটি আমি দেখতে পাচ্ছি, আমি এটি মুছে ফেলব তবে মনে হয় এটি করার কোনও অধিকার আমার নেই (বা আমি বোতামটি দেখছি না)। যেভাবেই আমি এটিকে সম্পাদন করে পরিষ্কার হতে পারি cle
বিনয়ামিন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.