"অকাল বিমূর্ততা" কী?


10

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

সাধারণ কেস কী তা জানার আগে আপনি কোনও বিমূর্ততা তৈরি করতে চান না, অন্যথায় (1) আপনি আপনার বিমূর্তগুলিতে এমন জিনিস স্থাপন করতে পারেন যা সম্পর্কিত নয়, বা (২) গুরুত্বের বিষয় বাদ দেওয়া উচিত।

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

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

আমাদের সর্বদা বিমূর্ততা থেকে শুরু করে কনক্রেশন পর্যন্ত কাজ করা উচিত কারণ এটি জিনিসগুলির সর্বাধিক বাস্তব উপায়, না অন্যদিকে।

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

এখানে একটি উদাহরণ দেওয়া যাক, একজন ক্লায়েন্ট আপনার আইটেম ব্যাগিং রোবট তৈরি করতে চান:

public abstract class BaggingRobot() {
    private Collection<Item> items;

    public abstract void bag(Item item);
}

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

অকাল বিমূর্তকরণের মতো কোনও জিনিস নেই, কেবল অকাল সঙ্কোচন। এই বক্তব্যটি কী ভুল? আমার যুক্তিতে ত্রুটিগুলি কোথায়? ধন্যবাদ।


1
অকাল বিমূর্তনের বিপরীতটি হ'ল YAGNI - আপনার দরকার নেই এটি প্রয়োজন, যা আমার মতে প্রায় সর্বদা ভুল। প্রায়। আমি এটি ঘটতে দেখেছি, তবে এটি বিরল। আপনি এখানে যা বলছেন তাতে আমি বেশিরভাগ ক্ষেত্রেই একমত।
ব্যবহারকারী 1118321

উত্তর:


19

কমপক্ষে আমার মতে, অকাল বিমূর্ততা মোটামুটি সাধারণ, এবং বিশেষত ওওপি-র ইতিহাসে এত তাড়াতাড়ি ছিল।

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

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


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

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

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

6

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

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

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

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

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


আপনি কিছুটা classকেন্দ্রিক বলে মনে হচ্ছে … অনেকগুলি শ্রেণি থাকলেও বিমূর্ততা তাদের ব্যবহার / উপকারে সীমাবদ্ধ নয়।
উত্সাহক

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

3

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

এর মাধ্যমে সন্ধান করলে যে কোনও বিশেষ্য (বা বিশেষ্য বাক্যাংশ) একটি সম্ভাব্য শ্রেণি হিসাবে বিবেচিত হবে। কোনও ক্রিয়া (বা ক্রিয়া বাক্যাংশ) ক্লাসে সম্ভাব্য পদ্ধতি হতে পারে। সুতরাং "ব্যাগিং রোবট" একটি শ্রেণি হতে পারে BaggingRobot। "একটি ব্যাগ খুলুন" পদ্ধতিতে পরিণত হতে পারে OpenBag

কয়েকটি পুনরাবৃত্তির পরে, এটি একটি শ্রেণীর ডায়াগ্রামে পরিণত হবে।

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

বিমূর্ত ক্লাসগুলি কেবল তখনই চালু করা হয় যখন এটি স্পষ্ট হয়ে যায় যে:

  • এরকম বেশ কয়েকটি মিল রয়েছে যা শ্রেণিবদ্ধ হতে পারে।
  • তারা প্রকৃতপক্ষে সাধারণ কিছু ভাগ করে নেয়, যাতে একটি বেস শ্রেণি একটি কার্যকর উদ্দেশ্য করে।

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


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

একটি ব্যাগিংরোবট অবজেক্ট যা আইটেম অবজেক্টগুলিকে ব্যাগের আইটেমগুলিতে রাখে ইতোমধ্যে ব্যাগগুলিতে জিনিস রাখে এমন একটি আসল ব্যাগিং রোবোটের বিমূর্ততা।
ব্যবহারকারী 253751

1

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

উদাহরণস্বরূপ, আপনি কি ভাবছেন যে এটি নিজেই রোবট , আইটেমগুলি ব্যাগ করা হচ্ছে বা ব্যাগিংয়ের পদ্ধতি যা লাইনটি পরিবর্তন করবে?

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

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

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

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

public class Item {
/* Relevant item attributes as specified by customer */
}
public class BaggingRobot {
  private Collection<Item> items;

  public void bag(Item item);
}

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

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

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

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


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

"অনুমানের সমাধানটি বাস্তবায়নের বিষয়ে আমি আরও যোগাযোগের পরামর্শ দেব" - আপনার মতামতটি আমি যেমন প্রস্তাব করেছি বলেছি? আমি ওপিতে যা বলেছিলাম তা উদ্ধৃত করার জন্য "এর সমাধানটি আপনার নিজের মনস্তাত্ত্বিক সংস্থান এবং বর্জ্য সংস্থান নিয়ে আসে না যখন আপনি খুঁজে পেয়েছেন যে আপনি ভুল অনুমান করেছেন, এটি ক্লায়েন্টের কাছ থেকে আরও তথ্য পাওয়ার জন্য।"
জেমস

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

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

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