29

আমি কীভাবে বলতে পারি যে আমার সফ্টওয়্যারটির অত্যধিক বিমূর্ততা রয়েছে এবং অনেকগুলি নকশার ধরণ রয়েছে, বা অন্যভাবে রাউন্ডে, আমি কীভাবে জানব যে এটির আরও বেশি থাকা উচিত কিনা?

আমি যে বিকাশকারীদের সাথে কাজ করি তারা এই বিষয়গুলি সম্পর্কে বিভিন্নভাবে প্রোগ্রামিং করছে।

কেউ কেউ প্রতিটি সামান্য ফাংশন বিমূর্ত করে তোলে, যেখানেই সম্ভব নকশার নিদর্শন ব্যবহার করে এবং যে কোনও মূল্যে অপ্রয়োজনীয়তা এড়ায়।

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

আমি জানি এটি একটি বাণিজ্য বন্ধ। প্রকল্পে যখন যথেষ্ট বিমূর্ততা রাখা হয় তখন আমি কীভাবে বলতে পারি এবং কীভাবে আমি জানি যে এটির আরও বেশি প্রয়োজন?

উদাহরণস্বরূপ, যখন জেনেরিক ক্যাচিং স্তরটি মেমক্যাচ ব্যবহার করে লেখা হয়। আমরা সত্যিই প্রয়োজন Memcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector, ... অথবা এই বজায় রাখার জন্য সহজ এবং এখনো ভাল কোড যখন সেই ক্লাস কেবলমাত্র অর্ধেক ব্যবহার করছে?

এটি টুইটারে পাওয়া গেছে:

( https://twitter.com/rawkode/status/875318003306565633 )

— ড্যানিয়েল ডাব্লু।
সূত্র

58

আপনি যদি বালতি থেকে টানটান জিনিসগুলি এবং প্রোগ্রামগুলি একত্র করার জন্য ব্যবহার করেন এমন ডিজাইন নিদর্শনগুলি ব্যবহার করে থাকেন, আপনি খুব বেশি ব্যবহার করছেন you're

— ব্লারফ্ল

22

"একজন ডিজাইনার জানেন যে যখন যোগ করার মতো কিছুই অবশিষ্ট থাকে না তখন যখন তিনি সিদ্ধি অর্জন করেছিলেন তবে যখন যখন কিছুই নিতে হবে না"। এন্টোইন ডি সেন্ট-এক্সুপেরি

— ডক ব্রাউন

5

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

— প্রাইম

8

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

— jpmc26

5

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

— আলেফজেরো

52

খাবারের জন্য কতগুলি উপাদান প্রয়োজনীয়? একটি গাড়ি তৈরি করার জন্য আপনার কত অংশের প্রয়োজন?

আপনি কি জানেন যে আপনার প্রয়োগ খুব সামান্য থাকে যখন সামান্য বাস্তবায়ন পরিবর্তন আপনার কোডের সমস্ত পরিবর্তনকে ক্যাসকেডের দিকে নিয়ে যায়। সঠিক বিমূর্ততা কোডের অংশটি পৃথক করতে সহায়তা করবে যা পরিবর্তন করা দরকার।

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

একদিকে, একটি নম্বর দিয়ে প্রশ্নের উত্তর দেওয়ার সত্যিই উপায় নেই। প্রকল্প থেকে প্রজেক্টে, ভাষা থেকে অন্য ভাষায় এবং এমনকি একজন বিকাশকারী থেকে অন্য একের মতো বিমূর্তির সংখ্যা একই হবে না।

— আরসেনি মরজেনকো
সূত্র

28

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

— তুলিনস কর্ডোভা

বিমূর্তির সংখ্যা একই প্রকল্পের বিভিন্ন অংশের জন্যও একই হবে না!

— টি। সর - মনিকা

ইঙ্গিত: মেমক্যাচ থেকে অন্য ক্যাশেিংয়ের ব্যবস্থায় পরিবর্তন (রেডিস?) একটি বাস্তবায়ন পরিবর্তন।

— ওগ্রে গীতসংহিতা 33

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

— jpmc26

আমি তর্ক করা চাই যে দুটি ইন্টারফেস এবং তাদের বাস্তবায়ন শ্রেণীর শত শত ক্ষেত্রে, আপনি বেশ সম্ভবত আছে আপনার বিমূর্ত overstretched। আমি অবশ্যই এটি এমন প্রকল্পগুলিতে দেখেছি যা অনেক জায়গাতেই খুব অস্পষ্ট বিমূর্ততা পুনরায় ব্যবহার করে ( interface Doer {void prepare(); void doIt();}) এবং যখন এই বিমূর্ততাটি আর ফিট না হয় তখন রিফ্যাক্টরটি যন্ত্রণাদায়ক হয়ে ওঠে। উত্তরের মূল অংশটি হল পরীক্ষাটি প্রয়োগ করা হয় যখন কোনও বিমূর্ততা পরিবর্তন করতে হয় - যদি এটি কখনও না ঘটে, এটি কখনই ব্যথার কারণ হয় না।

— জেমস_পিক

24

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

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

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

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

— নিল
সূত্র

হাতুড়ি সাদৃশ্যটি কেবল একটি ডিজাইনের প্যাটার্ন জানার সমস্যা হবে। ডিজাইন নিদর্শনগুলি থেকে নির্বাচন করতে এবং উপযুক্ত যেখানে প্রয়োগ করার জন্য একটি সম্পূর্ণ টুলকিট তৈরি করা উচিত। আপনি বাদাম ফাটানোর জন্য স্লেজহ্যামার নির্বাচন করবেন না।

— পিট কিরখাম

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

— নীল

আমি আমার বাদাম ফাটানোর জন্য প্রশিক্ষিত কাঠবিড়ালি একটি সেনা চাই।

— icc97

6

টি এল: ডিআর;

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

দীর্ঘ উত্তর

সম্ভবত আপনি কখনই বুঝতে পারবেন না যে আপনি কত স্তরের বিমূর্ততা তৈরি করছেন।

বিমূর্ততার বেশিরভাগ স্তর আমাদের কাছে অদৃশ্য এবং আমরা সেগুলি সম্মানের জন্য গ্রহণ করি।

এই যুক্তি আমাকে এই সিদ্ধান্তে নিয়ে যায়:

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

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

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

— তুলিনেস কর্ডোভা
সূত্র

2

"সম্ভবত আপনি কখনই বুঝতে পারবেন না যে আপনি কত স্তরের বিমূর্ততা তৈরি করছেন" " - আসলে, একটি বিমূর্ততা পুরো পয়েন্ট আপনি, জানি যে না এটা কিভাবে বাস্তবায়িত হয় IOW আপনি না (এবং না পারেন ) এটা কিভাবে abstractions অনেক মাত্রা লুকিয়ে রাখে।

— Jörg W Mittag

4

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

বিমূর্ততা বেড়া মত। তারা আপনার প্রোগ্রামের পৃথক অঞ্চলকে পরীক্ষামূলক এবং বিনিময়যোগ্য অংশে (নন-ভঙ্গুর অ-অনমনীয় কোড তৈরি করার প্রয়োজনীয়তা) সহায়তা করে। এবং অনেকটা বেড়ার মতো:

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

— dlasalle
সূত্র

4

refactoring

"এতক্ষণে একবার" উল্লেখ করা "রিফ্যাক্টরিং" শব্দটি আমি দেখিনি। সুতরাং, আমরা এখানে যাই:

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

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

প্যাটার্নস একটি মন সরঞ্জাম

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

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

লাইব্রেরি

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

— AnoE
সূত্র

2

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

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

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

গ্রাহক প্রোগ্রামারগুলির জন্য বিমূর্তির মান বিবেচনা করার পরে, তারপরে আমরা মূল্যায়ন করতে পারি এবং বাস্তবায়নের বিষয়টি বিবেচনা করতে পারি, যেমন ডিআরওয়াই-নেসের মতো।

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

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

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

— এরিক tদ
সূত্র

2

বিমূর্ততা কোড বোঝার জন্য আরও সহজ করার জন্য ডিজাইন করা হয়েছে। যদি বিমূর্ততার একটি স্তর জিনিসগুলিকে আরও বিভ্রান্ত করতে চলেছে - এটি করবেন না।

উদ্দেশ্য হ'ল বিমূর্তি এবং ইন্টারফেসের সঠিক সংখ্যাটি ব্যবহার করা:

উন্নয়নের সময় হ্রাস করুন
কোড রক্ষণাবেক্ষণ সর্বোচ্চ করুন

প্রয়োজন হলে বিমূর্ততা

যখন আপনি আবিষ্কার করবেন আপনি একটি সুপার ক্লাস লিখছেন
যখন এটি উল্লেখযোগ্য কোডটি পুনরায় ব্যবহারের অনুমতি দেবে
যদি বিমূর্তকরণটি কোড তৈরি করে তা উল্লেখযোগ্যভাবে পরিষ্কার হয়ে ওঠার সহজ হবে

বিমূর্ত না যখন

এটি করার ফলে কোড-পুনঃব্যবহার বা স্বচ্ছতার কোনও সুবিধা হবে না
এটি করার ফলে কোনও সুবিধা ছাড়াই কোডটি উল্লেখযোগ্যভাবে দীর্ঘ / আরও জটিল হয়ে উঠবে

কিছু উদাহরণ

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

— sdfgeoff
সূত্র

2

আমি মনে করি এটি একটি বিতর্কিত মেটা-উত্তর হতে পারে, এবং আমি পার্টিতে কিছুটা দেরি করেছি, তবে আমি এখানে এটি উল্লেখ করা খুব গুরুত্বপূর্ণ বলে মনে করি কারণ আমি মনে করি আমি জানি আপনি কোথা থেকে এসেছেন।

নকশার ধরণগুলি যেভাবে ব্যবহার করা হয় তা নিয়ে সমস্যাটি হ'ল যখন তাদের শেখানো হয়, তারা এ জাতীয় কেসটি উপস্থাপন করে:

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

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

এগুলি ছাড়াও, আমি সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বিষয়ে কথা বলার সময় আন্দ্রে আলেকজান্ড্রেসকুকে উদ্ধৃত করতে চাই, যিনি বলেছেন:

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

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

এটি এরকম সময়ে, ইনসমনিয়াকের গেম ইঞ্জিনের লিড মাইক অ্যাক্টনের ভবিষ্যদ্বাণীপূর্ণ কণ্ঠ আমার মাথায় চিৎকার করে:

আপনার ডেটা জানুন

তিনি আপনার প্রোগ্রামের ইনপুটগুলি এবং পছন্দসই ফলাফলগুলি সম্পর্কে কথা বলছেন। এবং তারপরে পৌরাণিক ম্যান মাসের এই ফ্রেড ব্রুকস রত্নটি রয়েছে:

আমাকে আপনার ফ্লোচার্টগুলি দেখান এবং আপনার টেবিলগুলি গোপন করুন এবং আমি রহস্যজনক হতে থাকব। আমাকে আপনার টেবিলগুলি দেখান, এবং আমার সাধারণত আপনার ফ্লোচার্টের প্রয়োজন হয় না; তারা সুস্পষ্ট হবে।

সুতরাং আমি যদি আপনি হয়ে থাকি তবে আমি আমার সাধারণ ইনপুট কেসের উপর ভিত্তি করে আমার সমস্যা সম্পর্কে তর্ক করব এবং এটি পছন্দসই সঠিক আউটপুট অর্জন করবে কিনা। এবং এই জাতীয় প্রশ্ন জিজ্ঞাসা করুন:

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

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

— নাসের-SH
সূত্র

2

সফ্টওয়্যার আর্কিটেকচার হ'ল ভাষা উদ্ভাবন করা

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

স্থাপত্য সংক্রান্ত বিষয়ে সিদ্ধান্ত নেওয়ার সময় এই দৃশ্যটি আমাকে সহায়তা করে।

সুপাঠ্যতা

সেই ভাষাটি সহজেই বোঝা উচিত (পরবর্তী স্তরটির কোডটি পাঠযোগ্য making কোড লিখিত চেয়ে অনেক বেশি বার পড়া হয়।

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

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

ব্যবহারযোগ্যতা

ভাষাটি ব্যবহার করা সহজ হওয়া উচিত ("সঠিক বাক্যগুলি প্রস্তুত করা সহজ করে)"।

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

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

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

সারাংশ

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

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

— রালফ ক্লেবারহফ
সূত্র

1

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

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

— Ryathal
সূত্র

-1

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

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

— মার্টিন মাট
সূত্র

2

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

— রাউকোড

নকশার কতগুলি নকশাগুলি এবং বিমূর্ততার স্তর প্রয়োজনীয়? [বন্ধ]