বিমূর্ততা: সমস্যা সমাধানের এবং একটি সাধারণ সমাধানের মধ্যে যুদ্ধ [বন্ধ]

Question

একজন প্রোগ্রামার হিসাবে আমি নিজেকে সেই দ্বিধায় ফেলেছি যেখানে আমি আমার প্রোগ্রামটিকে যতটা সম্ভব বিমূর্ত এবং সাধারণ হিসাবে তৈরি করতে চাই general

এটি করা সাধারণত আমাকে আমার কোডটি পুনরায় ব্যবহার করার অনুমতি দেয় এবং এমন সমস্যার জন্য আরও সাধারণ সমাধান করতে পারে যা সম্ভবত আবার আসতে পারে (বা নাও পারে)।

তারপরে আমার মাথায় এই ভয়েস বলছে, কেবল সমস্যার সমাধান করুন ডামি এটি এত সহজ! আপনার চেয়ে বেশি সময় ব্যয় করবেন কেন?

আমরা সবাই সত্যিই এই প্রশ্নের মুখোমুখি হয়েছি যেখানে বিমূর্ততাটি আপনার ডান কাঁধে এবং সলভ-ই-বোকা বাম দিকে বসে আছে।

কোনটি শুনতে হবে এবং কতবার? এর জন্য আপনার কৌশল কী? আপনার কি সবকিছু বিমূর্ত করা উচিত?

Comments

"অ্যাবস্ট্রাক্ট এবং সাধারণ হিসাবে" সাধারণত প্রোগ্রামারের হুব্রিস হিসাবে পরিচিত :) তবে, মারফি আইনের কারণে, পরবর্তী টাস্কে কাজ করার সময় আপনার যে এক ডিগ্রি অভিযোজন প্রয়োজন হবে তা আপনি সরবরাহ করেন নি।

— ম্যাথিউ এম।

এক সেরা প্রশ্ন!

— explorest

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

Answer 1

কোনটি শুনতে হবে এবং কতবার?

আপনি আবশ্যক অবধি বিমূর্ত কখনও করবেন না।

জাভাতে, উদাহরণস্বরূপ, আপনাকে অবশ্যই ইন্টারফেস ব্যবহার করতে হবে। তারা একটি বিমূর্ততা।

পাইথনে আপনার ইন্টারফেস নেই, আপনার কাছে হাঁসের টাইপিং রয়েছে এবং আপনার বিমূর্ততার উচ্চ স্তরের প্রয়োজন নেই। সুতরাং আপনি ঠিক না।

এর জন্য আপনার কৌশল কী?

আপনি এটি তিনবার লিখে না দেওয়া পর্যন্ত বিমূর্ততা ফেলবেন না।

একবার হয় - ভাল - একবার। শুধু এটি সমাধান করুন এবং এগিয়ে যান।

দু'বার এখানে ইঙ্গিত পাওয়া যায় যে এখানে কোনও প্যাটার্ন থাকতে পারে। বা নাও পারে। এটা ঠিক কাকতালীয় হতে পারে।

তিনবার একটি প্যাটার্নের শুরু। এখন এটি কাকতালিকে ছাড়িয়ে যায়। আপনি এখন সফলভাবে বিমূর্ত করতে পারেন।

আপনার কি সবকিছু বিমূর্ত করা উচিত?

না।

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

এটি করার ফলে সাধারণত আমার কোডটি পুনরায় ব্যবহার করার সুযোগ পেত

এটি এমন একটি অনুমান যা প্রায়শই মিথ্যা। বিমূর্ততা কিছু সাহায্য করতে পারে না। এটি খারাপভাবে করা যায়। অতএব, আপনার প্রয়োজন অবধি এটি করবেন না।

Comments

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

— জেসন বেকার

@ জেসন বেকার: "ক্লাস, পদ্ধতি, লুপ বা বিবৃতি যদি আপনি ব্যবহার এড়িয়ে যান তবে আমি তা গ্রহণ করি"। প্রশ্নটি কী ছিল তা মনে হয় না। যদি আমরা আমাদের ডিজাইনগুলি অত্যধিক-বিমূর্ত করা এড়িয়ে চলি তবে কেন সমস্ত অযৌক্তিক দাবিটি অযৌক্তিক দাবি করে?

— এস .লট

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

— জেসন বেকার

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

— এস.লট

@ জেসনবেকার কারও সাথে ঘুমানোর কোনও অযৌক্তিক কারণ নয়। সম্ভবত আপনি "অর্থ" ভাবছেন?

Answer 2

আহ, ইয়াজিএনআই প্রোগ্রামিংয়ের সবচেয়ে আপত্তিজনক ধারণা।

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

প্রবাদটি যেমন চলে যায় "সবচেয়ে সহজ কাজটি করুন যা সম্ভবত কাজ করতে পারে"। জিনিসটি হ'ল মানুষ সর্বদা সহজ সাথে সহজ বিভ্রান্ত করে । সরলতা কাজ লাগে। তবে এটি প্রচেষ্টা মূল্যবান।

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

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

Comments

মধ্যে নিস পার্থক্য simpleএবং easy!

— ম্যাথিউ এম।

en.wikedia.org/wiki/ আপনি_ain__nana_need_it

— স্টিভ বেনেট

"তবে আমার অভিজ্ঞতা হ'ল কয়েকটি সংস্থা" - মজার বিষয় হল, একাডেমিয়ায় বিপরীতটি সত্য হতে পারে।

— স্টিভ বেনেট

Answer 3

একটি পাঠ্যক্রম:

1. সাধারণতা ব্যয়বহুল।

2. আপনি অন্য লোকের অর্থ ব্যয় করছেন।

3. সুতরাং সাধারণতার ব্যয় অবশ্যই স্টেকহোল্ডারদের কাছে ন্যায়সঙ্গত হতে হবে।

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

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

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

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

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

Comments

দরকারী নীতিগুলির জন্য +1, অর্থের বিষয়ে এটি তৈরি করার জন্য -1।

— ম্যাসন হুইলারের

@ মেসন: এটি অর্থের বিষয়ে নয় , প্রচেষ্টা সম্পর্কে । অর্থ প্রচেষ্টা একটি ব্যবহারিক পরিমাপ । দক্ষতা হ'ল উত্পাদিত প্রতি প্রচেষ্টা ব্যয়িত উপকারিতা; আবার অর্থের মুনাফা হ'ল উপার্জনের একটি ব্যবহারিক ব্যবস্থা । প্রচেষ্টা, ব্যয় এবং উপকার পরিমাপের কিছু উপায় নিয়ে আসার চেয়ে অর্থের বিমূর্ততা সম্পর্কে আলোচনা করা সহজ। আপনি কি অন্য কোনও উপায়ে প্রচেষ্টা, ব্যয় এবং উপকার পরিমাপ করতে পছন্দ করবেন? আরও ভাল উপায়ের প্রস্তাব নির্দ্বিধায়।

— এরিক লিপার্ট

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

— 4'11

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

— এরিক লিপার্ট

আমার অভিজ্ঞতায়, অন্যান্য প্রকল্পগুলি ঝুঁকে যাওয়ার ঝোঁক থাকে না, তাই এগিয়ে চলার আগে এটি সাধারণত বর্তমান প্রকল্পে যতটা প্রয়োজন সময় ব্যয় করা উপযুক্ত।

— অর্বলিং করছেন

Answer 4

কেবল স্পষ্ট করে বলতে গেলে, কিছু সাধারণ করা এবং বিমূর্তি বাস্তবায়ন করা সম্পূর্ণ দুটি ভিন্ন জিনিস।

উদাহরণস্বরূপ, একটি ফাংশন বিবেচনা করুন যা মেমরি অনুলিপি করে।

ফাংশনটি একটি বিমূর্ততা যা 4 বাইট কীভাবে অনুলিপি করে তা গোপন করে।

ইন্ট কপি 4 বাইটস (চর * পিএসসিআর, চর * পিডেস্ট)

একটি সাধারণীকরণ এই ফাংশনটি বাইটের যে কোনও সংখ্যার অনুলিপি করবে।

ইন্টি কপিবিটস (চর * পিএসসিআর, চর * পিডেস্ট, ইন্ট নাম্বাইট টাইটোপি)

বিমূর্ততা নিজেকে পুনঃব্যবহারের জন্য ndsণ দেয়, যখন সাধারণীকরণ কেবল আরও কিছু ক্ষেত্রে বিমূর্তিটিকে দরকারী করে তোলে।

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

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

Comments

বিমূর্তি এবং সাধারণীকরণের মধ্যে পার্থক্য তৈরি করার জন্য +1।

— জোরিস মেজ

Answer 5

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

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

Comments

এটি আমার রিফ্যাক্টরিং বিধিটির সংস্করণটির মতো মনে হচ্ছে: দুটি ধর্মঘট! refactor!

— ফ্র্যাঙ্ক শেয়ার

@ ফ্র্যাঙ্ক: এটি সম্ভবত আপনার রিফ্যাক্টরিং নিয়ম, তবে দ্বিতীয় অনুচ্ছেদে ব্যক্তিগত অভিজ্ঞতা থেকে যুক্ত হয়েছে।

— ল্যারি কোলেম্যান

+1: আমি বিশ্বাস করি এটি প্রায় প্রাগমেটিক প্রোগ্রামার আইআরসি-র প্রায় একেবারে প্রাথমিকভাবে উল্লেখ করা হয়েছিল ।

— স্টিভেন এভার্স

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

— ফ্র্যাঙ্ক শেয়ার

দু'জনের একটি নমুনা আমার মতে অসীমের পক্ষে সাধারণীকরণের পক্ষে খুব ছোট। অন্য কথায়, অনেক অনেক তাড়াতাড়ি।

Answer 6

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

প্রথম: অকাল সাধারণতা ব্যয়বহুল।

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

তৃতীয়: আপনার নীতিগুলি আপনার প্রক্রিয়া থেকে দূরে রাখুন।

Answer 7

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

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

Answer 8

আমি কেআইএসএস নীতির একটি বড় অনুরাগী।

আমি যা করতে বলি তা সরবরাহ করার বিষয়ে আমি মনোনিবেশ করি এবং এর সেরা সমাধান কী তা নয় on আমাকে পারফেকশনিজম (এবং ওসিডি) ছাড়তে হয়েছিল, কারণ এটি আমাকে দু: খিত করে তুলেছে।

Comments

নিখুঁততা অপছন্দ কেন? (আমি আপনাকে ভোট দিয়েছি না)

— এয়ারলিং 0'11

পরিপূর্ণতা জন্য লক্ষ্য না আমার জন্য কাজ করে। কেন? কারণ আমি জানি আমার প্রোগ্রামগুলি কখনই নিখুঁত হতে পারে না। পরিপূর্ণতার কোনও মানক সংজ্ঞা নেই, তাই আমি ঠিক এমন কিছু সরবরাহ করতে পছন্দ করি যা ভালভাবে কাজ করে।

— পাবলো

Answer 9

যেখানে বিমূর্ততাটি আপনার ডান কাঁধে এবং সলভ ইট-বোকা বাম দিকে বসে।

আমি "এটি নির্বোধের সমাধান করুন" এর সাথে একমত নই , আমি মনে করি এটি আরও "সমাধান করুন এটি স্মার্ট" ।

স্মার্ট কি:

• একটি জটিল সাধারণ সমাধান লিখেছেন যা একাধিক ক্ষেত্রে সমর্থন করতে পারে
• সংক্ষিপ্ত এবং কার্যকর কোডটি লেখা যা হাতের মুঠোয় সমস্যার সমাধান করে এবং বজায় রাখা সহজ, এবং যদি প্রয়োজন হয় তবে ভবিষ্যতে এটি বাড়ানো যেতে পারে ।

ডিফল্ট পছন্দ দ্বিতীয়টি হওয়া উচিত। যদি না আপনি প্রজন্মের জন্য প্রয়োজনীয়তা প্রদর্শন করতে পারেন।

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

সাধারণত আমি দেখতে পাই যে সাধারণ সমাধানগুলি "কোর লাইব্রেরি কোড" হিসাবে সবচেয়ে ভাল পরিবেশন করা হয়

Comments

আপনি যদি এখানে সমস্ত অনুমান করতে পারতেন তবে আপনার সমস্যা হবে না। সংক্ষিপ্ত এবং বজায় রাখা সহজ পারস্পরিক একচেটিয়া। যদি আপনি জানেন যে কোনও কিছু পুনরায় ব্যবহৃত হবে, তবে সাধারণ সমাধানটি এটিকে সমাধান করবে।

— জেফো

— @ জেফ

আপনি "সলভ ইট বোকা" প্রসঙ্গের বাইরে রেখেছেন।

— ব্রায়ান হ্যারিংটন