বিমূর্ততার মাধ্যমে বিশদটি গোপন করার মান কী? স্বচ্ছতার কি মূল্য নেই?


30

পটভূমি

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

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

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

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

এখানে কি হচ্ছে? আমি কখনই কাজ করেছি এমন প্রতিটি সিস্টেম কি খারাপভাবে ডিজাইন করা হয়েছে (অন্তত এই দৃষ্টিকোণ থেকে)?

আমার দর্শন

আমি যখন সফ্টওয়্যারটি বিকাশ করি তখন আমার মনে হয় যে আমি কোনও দর্শনের অনুসরণ করার চেষ্টা করি যা আমার মনে হয় আর্লিনাক্স দর্শনের সাথে ঘনিষ্ঠভাবে জড়িত :

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

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

মনে মনে প্রশ্ন

  1. বিশদটি গোপন করার ক্ষেত্রে কি সত্যিকারের মূল্য আছে?
  2. আমরা কি স্বচ্ছতার ত্যাগ করছি না?
  3. এই স্বচ্ছতা কি মূল্যবান নয়?

7
বিমূর্ততা খারাপ ডিজাইনের আকারে আপত্তিজনক ব্যবহার করা যেতে পারে। তবে এর অর্থ এই নয় যে নীতিগতভাবে বিমূর্তি মূল্যবান নয়।
বার্নার্ড

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

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

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

8
আমার মনে হয় আপনার যে সমস্যার সাথে সমস্যা হচ্ছে তা অ্যাবস্ট্রাকশন নয়, এটি ইন্ডিরিশনের খালি স্তর যা আসলে কিছুই বিমূর্ত করে না। হ্যাঁ, এগুলি প্রায়শই বৃহত এন্টারপ্রাইজ সিস্টেমে পাওয়া যায় এবং না, সেগুলি ভাল নয়।
মাইকেল বার্গওয়ার্ট

উত্তর:


47

বিবরণ গোপন করার কারণ বিশদটি গোপন রাখা নয়; নির্ভরশীল কোডটি না ভেঙে বাস্তবায়নটি সংশোধন করা সম্ভব করে তোলা।

কল্পনা করুন যে আপনার কাছে বস্তুর একটি তালিকা পেয়েছে এবং প্রতিটি বস্তুর একটি Nameসম্পত্তি এবং অন্যান্য ডেটা রয়েছে। এবং অনেক সময়, আপনাকে তালিকার একটি আইটেম খুঁজে পেতে হবে যার Nameএকটি নির্দিষ্ট স্ট্রিংয়ের সাথে মেলে।

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

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

আপনার যদি FindByNameনাম অনুসন্ধানের প্রক্রিয়াটি encapsulate করার কোন পদ্ধতি থাকে তবে আপনি কেবল এটি প্রয়োগ করার উপায় এবং এটির কল করে যে সমস্ত কোড এটি চালিয়ে যেতে পারে তা পরিবর্তন করতে পারেন এবং অনেক দ্রুত বিনামূল্যে পান। এটি বিমূর্তি এবং এনক্যাপসুলেশন এর আসল মান।


আমি এটির সাথে একমত, কিন্তু এটি প্রশ্নের মূল বিষয় ছিল না। আমি সম্পূর্ণরূপে একমত হতে পারি যে নির্দিষ্ট কার্যকারিতা সজ্জিত করার জন্য একটি পদ্ধতি দরকারী তবে আমার মনে হয় এটি সর্বদা উদ্দেশ্য নয়। আমি কি ভূল?
ব্যবহারকারী 606723

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

3
@ ব্যবহারকারীর 606723: স্বচ্ছতা শক্ত সংযোগকে উত্সাহ দেয়, তাই সম্ভবত সর্বদা খারাপ না হলেও সাধারণত হয়।
মালফিস্ট

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

2
না, টাইট কাপলিং সবসময় খারাপ হয় না । এটি প্রায়শই খারাপ হয়, তবে এটি এড়াতে দুর্দান্ত দৈর্ঘ্যে যাওয়ার ফলে নরম কোডিংয়ের
ম্যাসন হুইলারের

16

আমি স্রেফ বিমূর্ততা সম্পর্কে কোড সম্পূর্ণ বিভাগটি পড়া শেষ করেছি, তাই এই উত্সগুলির বেশিরভাগই।

বিমূর্তির মূল বিষয়টি "এটি কীভাবে প্রয়োগ করা হয়?" জিজ্ঞাসা করার প্রয়োজনীয়তা সরিয়ে ফেলা হয়। আপনি যখন কল করবেন তখন আপনি user.get_id()জানতে পারবেন যে idআপনি ফিরে পেতে যাচ্ছেন an যদি আপনাকে জিজ্ঞাসা করতে হয় "এটি কীভাবে ব্যবহারকারীর আইডি পায়?" তারপরে সম্ভবত আপনার কোনও প্রয়োজন হয় না id, বা get_id()এমন কিছু প্রত্যাশিত হয় যা অপ্রত্যাশিত এবং খারাপভাবে ডিজাইন করা।

আপনাকে ডিজাইনের অনুমতি দিতে আপনি বিমূর্ততা ব্যবহার করুন:

a house with doors and windows

নকশা না

a box with four walls,
    with 3 holes,
        two of which fit panes of glass surrounded by wood frames,
        one that fits a large plank of wood with hinges and a metal knob,
etc.

আমি এই ইন্টারফেস সম্পর্কে কথা বলছি না। এই ইন্টারফেস ঠিক আছে। আমি বিশাল জটিল সিস্টেমগুলির বিষয়ে কথা বলছি যা বিভিন্ন বিমূর্ততার পিছনে বিভক্ত।
ব্যবহারকারী 606723

9
@ ব্যবহারকারী 606723 তারপরে আপনার প্রশ্নটি অ্যাবস্ট্রাকশনগুলির চেয়ে ওভার কমপ্লেক্স ডিজাইন সম্পর্কে
অ্যান্ড্রেস এফ।

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

এই প্রশ্নটি বন্ধ করা উচিত বা শিরোনাম পরিবর্তন করা উচিত
জ্যাক বার্গার

8

বিশদটি গোপন করার ক্ষেত্রে কি সত্যিকারের মূল্য আছে?

হ্যাঁ। বিমূর্ততা উপস্থাপন করে আমরা উচ্চ স্তরে চিন্তা করতে এবং প্রোগ্রাম করতে পারি।

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

মানুষের কাজের স্মৃতি সীমিত থাকে। বিমূর্ততা আমাদের বৃহত সিস্টেমগুলি সম্পর্কে যুক্তি প্রদর্শন করতে দেয়।

Aren't we sacrificing transparency?

না যদি বিমূর্ততা ব্যবহার না করা হয়, তবে একটি সফ্টওয়্যার উপাদানটির উদ্দেশ্য বারবার বিবরণে সমাহিত করা হয়। বিকাশকারীরা কোডগুলির মাধ্যমে এইভাবে তাদের দিন কাটায়:

for (i = 0; i < pilgrim.wives.size(); ++i) {
  wife = pilgrim.wives[i];
  for (j = 0; j < wife.sacks.size(); ++j) {
     sack = wife.sacks[i];
     for (k = 0; j < sack.cats.size(); ++j) {
        cat = sack.cats[k];
        for (m = 0; m < cat.kits.size(); ++m) {
           ++count;
        }
     }
  }
}

এবং ভাবছেন "ওহ হ্যাঁ কিটগুলির ওপরে আরও একটি চার-স্তরের লুপ"

pilgrim.kits.each { ++count; }

এই স্বচ্ছতা কি মূল্যবান নয়?

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


7

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

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

  • আপনি যখন কোনও ত্রুটিটি খুঁজে বের করেন এবং ঠিক করেন, একইরকম কোডের অনুলিপিযুক্ত অন্যান্য অনুলিপিগুলিতেও এটি উপস্থিত থাকতে পারে, তাই বাগটি সন্ধান এবং ফিক্সিংয়ের শীর্ষে, আপনাকে অন্যান্য সংক্রমণের জন্যও শিকার করতে হবে এবং সেগুলিও ঠিক করতে হবে।
  • কোনও ত্রুটি খুঁজে বের করতে বা কোনও পরিবর্তন কার্যকর করতে, কোনও রক্ষণাবেক্ষণ প্রোগ্রামার অবশ্যই প্রাসঙ্গিক কোডটি বুঝতে সক্ষম হবেন। এটি করতে সমস্যাটি প্রাসঙ্গিক কোড বিভাগের আকারের সাথে বৃদ্ধি পায় তবে এর পরিধিটি আরও বেশি more মানসিকভাবে কিছু কোডের মাধ্যমে পদক্ষেপ নেওয়ার সময় আপনার মাথায় অর্ধ ডজন ভেরিয়েবল রাখা do তবে যদি তাদের মধ্যে কয়েক শ'টি থাকে, আপনার উত্পাদনশীলতা মারাত্মকভাবে প্রভাবিত হবে (আমি চিন্তাভাবনা প্রক্রিয়াটি এমন একটি প্রোগ্রামের সাথে তুলনা করতে চাই যা শারীরিক র‌্যামের বাইরে চলে যায় এবং স্ব্যাপফাইলে ডুবতে হয়: কোডটি একবারে সাবলীলভাবে পড়ার পরিবর্তে of , প্রোগ্রামারকে জিনিসগুলি সন্ধান করতে পিছনে পিছনে ঝাঁপিয়ে পড়তে হবে)।
  • কিছু অংশের কোডের ব্যাগটি খুঁজে পাওয়ার জন্য কোডবেজটির আকারটিও প্রভাবিত করে। আপনার যদি দুটি পরামিতি সহ দশ-লাইনের ফাংশন থাকে, এবং কোনও গ্লোবাল না থাকে এবং আপনি যে ইনপুট এবং যে লাইনে এটি ক্র্যাশ করে তার মানগুলি জানেন, বাগটি সন্ধান করা সাধারণত তুচ্ছ হয় এবং প্রায়শই কোডটি দেখার চেয়ে আরও কিছু প্রয়োজন হয় না। যদি এটি কয়েকশ লাইন, বিশ প্যারামিটার, পনেরটি গ্লোবাল এবং অনুরূপ প্রকৃতির কয়েকটি অন্যান্য ফাংশন কল করে, আপনি কিছু গুরুতর ব্যথার জন্য রয়েছেন।
  • যথাযথ বিমূর্ততা ব্যতীত, কোনও পরিবর্তন সম্ভবত কোডবেসের বড় অংশগুলিকে প্রভাবিত করতে পারে, কারণ কার্যত কোনও কিছু পরিবর্তন করতে কোডের উপর নির্ভর করে। এই জাতীয় কোডবেসের একটি সাধারণ লক্ষণ হ'ল আপনি একটি ছোট, আপাতদৃষ্টিতে নির্দোষ পরিবর্তন করেন এবং একটি সম্পূর্ণ সম্পর্কযুক্ত বৈশিষ্ট্য হঠাৎ করে ভেঙে যায়। বিমূর্তকরণের সাহায্যে, আপনি পরিবর্তনটি যে পরিমাণ ক্ষতির পরিমাণ করতে পারেন তা সীমাবদ্ধ করতে পারবেন এবং আপনি প্রভাবটিকে আরও অনুমানযোগ্য করে তুলতে পারেন। আপনি যদি কোনও ব্যক্তিগত ক্ষেত্রের নাম পরিবর্তন করেন তবে আপনার কাছে কেবলমাত্র একটি উত্স ফাইল যাচাই করার জন্য রয়েছে; আপনি যদি বিশ্বব্যাপী ভেরিয়েবলের নাম পরিবর্তন করেন তবে আপনাকে পুরো কোডবেস দিয়ে চালানো দরকার।

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


2

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

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


1
অবশ্যই, তবে আমাকে প্রায়শই আমার অ্যালার্ম ক্লকটি কীভাবে কাজ করে তা পরিবর্তন করতে বলা হয় না, বা অন্যান্য লোকেরা পরিবর্তনের সম্পূর্ণ অবহিত না হয়ে আমার অ্যালার্ম ঘড়ি কীভাবে কাজ করে তা পরিবর্তন করতে বলা হয়।
ব্যবহারকারী 606723

1
আপনি কখনও ব্যবহার করেছেন এমন প্রতিটি কাঠামোর জন্য কোড পরিবর্তনগুলি দেখতে পান?
জেফো

1
না, তবে আমি প্রতিটি ফ্রেমওয়ার্কের জন্য কোড পরিবর্তনগুলি বজায় রাখছি না।
ব্যবহারকারী 606723

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

2

আপনার প্রশ্নের উত্তর বিশেষভাবে দিতে:

বিশদটি গোপন করার ক্ষেত্রে কি সত্যিকারের মূল্য আছে?

হ্যাঁ। আপনি যেমন আপনার প্রশ্নের প্রথম লাইনে স্বীকৃতি।

আমরা কি স্বচ্ছতার ত্যাগ করছি না?

আসলে তা না. একটি ভাল লিখিত বিমূর্ততা প্রয়োজন হলে বিশদটি বোঝা সহজ করে তুলবে।

এই স্বচ্ছতা কি মূল্যবান নয়?

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


পরিশেষে একটি উত্তর আমার পছন্দ।
ব্যবহারকারী 606723

1

আমি বলব যে লুকানো জিনিসগুলি যখন কাজ করে তখন বিশদটি গোপন করা দুর্দান্ত great

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

ফেসবুকের সাথে সংযোগ স্থাপন এবং তাদের আইটেমগুলি পাওয়ার ক্ষেত্রে এখন অনেকগুলি বিবরণ রয়েছে .. এবং মাইস্পেসে কানেক্ট করার সময় সমান বিবরণ রয়েছে .. এবং আরও অনেক কিছু ...

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

সুতরাং আপনি কোডটি ব্যবহার করার সময় এটি এমন কিছু:

    new ItemManager(user) //passes in user, allowing class to get all user properties
    ItemManager.GetListItems()

এবং এখনই আপনি যেখানেই এটি সংরক্ষণ করেছেন ব্যবহারকারীর ডেটা পেয়ে গেছেন এবং যেহেতু আমি সমস্তই চিন্তিত সেগুলি আইটেমের তালিকা পাওয়া এবং এটি দিয়ে কিছু করা এবং যেহেতু এটি কেবলমাত্র 2 টি লাইন নিয়েছে যা কার্যকর হবে না কেন আরও অনেক স্টোর যুক্ত করা হয়েছে আমি স্ট্যাকের উপর প্রশ্নগুলির উত্তর / পোস্ট করতে ফিরে পেতে পারি ... লোল ..

সুতরাং, এটি ঘটানোর জন্য সমস্ত নদীর গভীরতানির্ণয় হ'ল "লুকানো" এবং যিনি যতক্ষণ না আইটেমগুলির সঠিক তালিকা পাই যতক্ষণ না এটি এটি কীভাবে যত্নশীল হয় .. যদি আপনার ইউনিট পরীক্ষা থাকে তবে আপনি আরও সহজ করে বিশ্রাম নিতে পারেন কারণ ফলাফলগুলি হওয়া উচিত ' ইতিমধ্যে পরিমাণযুক্ত হয়েছে ..


হ্যাঁ, তবে যে অংশটি বজায় রাখা দরকার তা কখনই সেই দুটি লাইন নয়। এগুলি স্ক্রু আপ করা অসম্ভব। এটি সর্বদা ২ য়, তৃতীয়, চতুর্থ স্তর নীচে থাকে যা আপনার পরিবর্তন করতে হবে। আমি সম্মতি জানাব যে এটির দুর্দান্ত যখন আপনি এমন একটি এপিআই রাখেন যে আপনি স্থিতিশীল হওয়ার জন্য বিশ্বাস রাখতে পারেন , তবে কী যদি এটি কেবল আপনার ব্যবসায়ের জটিলতায় স্থিতিশীল হতে না পারে?
ব্যবহারকারী 606723

1
@ ইউজার 606723 যদি আপনি এপিআই স্থিতিশীল না হন তবে সম্ভবত এটি অপরিপক্ক, বা সম্ভবত ভুল বিমূর্ততা হতে পারে
sdg

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

@ এসডিজি, বা কারণ সিস্টেমের প্রয়োজনীয়তা সর্বদা পরিবর্তিত হয়। কারণ আইনগুলি পরিবর্তন হয়, কারণ অন্যের এপিআই'র পরিবর্তন, এটি আমাদের নিয়ন্ত্রণের বাইরে।
ব্যবহারকারী 606723

1
@ ইউজার 606723 - আমি আসলে একটি আর্থিক সাআস সিস্টেমের উপর কাজ করি এবং আমি প্রতিটি মুক্তির চক্রের পর্যাপ্ত বিমূর্ততা না পাওয়ার সম্ভাবনাগুলি দেখি। এর কয়েকটি হ'ল দুর্বল ডিজাইনের ফলস্বরূপ, তবে সাধারণত এটি প্রাথমিকভাবে উদ্দেশ্যপ্রণোদিত নয় এমন স্থানে শোভার কোডের ফলাফল। এই মন্তব্যগুলি, নাম এবং এনক্যাপসুলেশন ছাড়াই শৃঙ্খলে নামা বেদনাদায়ক হতে পারে । যদি আমাকে যা করতে হয় তা হ'ল রিচার্চারমেন্টস et গেটআমিচারটাইপ (অনুদান), এবং তারপরে পুনঃমিজার্স P পারফর্মক্যাল্যাক (), সঠিক গণনায় পৌঁছতে বা একটি নতুন যুক্ত করার জন্য বিভিন্ন লজিকাল শাখাগুলি দিয়ে ওভারলোড যুক্ত করা এবং পড়ার চেয়ে এত সুন্দর হবে
হাঞ্জোলো

1

আপনি "লুকোচুরি" হিসাবে উল্লেখ করেন, অনেকে উদ্বেগের বিচ্ছেদ হিসাবে দেখেন (যেমন বাস্তবায়ন বনাম ইন্টারফেস)।

আমার মতে, বিমূর্তকরণের একটি বড় সুবিধা হ'ল বিকাশকারীর সীমিত ব্রেনস্পেস থেকে অপ্রয়োজনীয় বিশদ বিশৃঙ্খলা হ্রাস করা।

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


1

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

আপনি সম্ভবত সম্মত হবেন যে এই আদিম বিমূর্তগুলি অত্যন্ত কার্যকর useful ঠিক আছে, তাই আপনার নিজের তৈরি করতে সক্ষম হচ্ছে। ওওএডি এবং ওওপি সব সম্পর্কে।

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

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


1
এমনকি মেশিন কোড একটি বিমূর্ততা, যুক্তিটির নীচে বাস্তব, শারীরিক, প্রক্রিয়াগুলি রয়েছে, এমনকি ডিজিটাল ইলেক্ট্রনিক্সগুলি কী ঘটেছিল এমন একটি বিমূর্ততা যা আসলেই ঘটে যায় যে কেউ একজন চিপকে ওভারক্লোকিংয়ের একটি হ্যাশ তৈরি করেছে যার সাক্ষ্য দিতে পারে
জে.কে.

খুব সত্য, যদিও এটি মেশিনের নির্দেশ স্তরে আরও কংক্রিট বলে মনে হচ্ছে।
ম্যাথু ফ্লিন

1

আমি মনে করি এটি সম্পর্কে আপনার অনুভূতিটি আমি বুঝতে পেরেছি এবং আমার কাছে একই মতামত রয়েছে বলে আমি মনে করি।

আমি জাভা বিকাশকারীদের সাথে কাজ করেছি যারা 50 কোড লাইন শ্রেণিকে 3 শ্রেণি এবং 3 ইন্টারফেসে পরিণত করেছে কারণ এটি বোঝা সহজ। এবং আমি এটি দাঁড়াতে পারি না।

জিনিসটি বোঝা খুব ভয়ঙ্কর ছিল, ডিবাগ করা প্রায় অসম্ভব এবং কখনও "বাস্তবায়ন স্যুইচ" করার দরকার পড়েনি।

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

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

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


1

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

কোনও মডিউল লেখার সময়, প্রয়োগের লুকানো অংশগুলি আপনাকে ভাবতে পারে না এমন অন্যান্য কোড ভঙ্গ করে ঝুঁকি না করে এগুলি পরিবর্তন করতে সক্ষম হওয়ার মনের অংশ দেয়।

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


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


0

অনেক ক্ষেত্রে আপনার কীভাবে জিনিসগুলি বাস্তবায়িত হয় তা জানার দরকার নেই । আমি প্রায় গ্যারান্টি দিতে পারি যে আপনি people.Where(p => p.Surname == "Smith")দিনে এতবার কোড লিখবেন তবুও আপনি খুব কমই ভাববেন "এই Where()পদ্ধতিটি আসলে কীভাবে কাজ করে?" আপনি কেবল পাত্তা দিচ্ছেন না - আপনি জানেন যে এই পদ্ধতিটি রয়েছে এবং এটি আপনার পছন্দমতো ফলাফলও দেয়। কেন এটি কাজ করে আপনি যত্ন করবেন?

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

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

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


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

সমস্যাPeopleFactory.People.Strategy.MakePeople.(CoutryLaw.NameRegistry.NameMaker.Make()) as People.Female
সংকেতপদ্ধতিরচয়িতা

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

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

0

বিমূর্ততা তথ্য গোপনের ফলাফল। এটি নিম্ন মিলনে শেষ হওয়া উচিত। এটি পরিবর্তনে কম ঝুঁকি নিয়ে যেতে হবে। কোডটি স্পর্শ করার সময় নার্ভাস হওয়া উচিত নয়, এতে হ্যাপি প্রোগ্রামারদের দিকে পরিচালিত হওয়া উচিত।

সফ্টওয়্যার আর্কিটেকচারের তিনটি প্রয়োজনীয় আইনের মাধ্যমে এই ধারণাগুলি প্রকাশ করা হয়েছে:

সাইমনসের আইন: "শ্রেণিবদ্ধতা জটিলতা হ্রাস করে।" (হায়ারারচিগুলি বিমূর্ততা প্রবর্তন করে)

পার্নার আইন: "কেবল যা লুকানো আছে তা ঝুঁকি ছাড়াই পরিবর্তন করা যায়।"

কনস্ট্যান্টিনের আইন: শক্তিশালী প্রোগ্রামগুলির কম সংযোগ এবং উচ্চ সংহতি প্রয়োজন


"শ্রেণিবদ্ধতা জটিলতা হ্রাস করে।" - অগত্যা সত্য নয়।
কোডার

কোনও ডিজাইনের পদ্ধতি নির্বিচারক নয়। এই আইন আইটি / সিএস থেকে আসে না এটি অনেক বিস্তৃত অর্থে প্রণীত হয় এবং এটি গণিত, পদার্থবিজ্ঞানী ইত্যাদি দ্বারাও উল্লেখ করা হয় এটি একটি বৈধ অধ্যক্ষ, তবে কেউ আপনাকে অযৌক্তিক হায়ারারচিজ তৈরি করা থেকে বাধা দিতে পারে না।
ins0m

0

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

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

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

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

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

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


0

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

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

এটি বলেছিল, বিমূর্ততা খুব কার্যকর নয় যদি আপনি এটি ব্যবহার করতে সক্ষম হতে তার ভিতরে কী রয়েছে তা দেখতে হবে। এটির নকশা করা খুব কঠিন হতে পারে। একটি ভাল বিমূর্তির উদাহরণ সংযোজন - সর্বশেষে কখন আপনাকে ভিতরে কী ঘটেছিল তা ভাবতে হয়েছিল? (তবে কখনও কখনও আপনি যেমন করেন, যেমন ওভারফ্লো)।

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

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

এই সব খুব নেতিবাচক বলে মনে হচ্ছে। তবে আমি মনে করি সত্য হ'ল আমরা এমন বিমূর্ততা ঘিরে রয়েছি যা এত ভালভাবে কাজ করে যে আমরা সেগুলি লক্ষ্য করি না, বা তারা কী লুকিয়ে রয়েছে তা বুঝতে পারি না। আমরা কেবল দুর্বল বিমূর্ততা লক্ষ্য করি, তাই সেগুলি সম্পর্কে আমাদের কাছে জন্ডিস দৃষ্টিভঙ্গি রয়েছে।


0

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

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

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

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

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

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

স্বচ্ছতার হিসাবে, শীর্ষ-নকশার কৌশল হিসাবে, মোট স্বচ্ছতা খারাপ ডিজাইনের জন্য তোলে। স্মার্ট প্রোগ্রামাররা তাদের হাতে থাকা তথ্যগুলির সর্বাধিক উপার্জন করার ঝোঁক দেয় এবং সিস্টেমটি তখন শক্তভাবে মিলিত হয়। মডিউলে বিশদটির ক্ষুদ্রতম পরিবর্তন (যেমন, কোনও ডাটা স্ট্রাকচারে বাইটের ক্রম পরিবর্তন করা) অন্য কোথাও কোথাও কোনও কোড ভঙ্গ করতে পারে, কারণ কোনও স্মার্ট প্রোগ্রামার সেই তথ্যটি দরকারী কিছু করার জন্য ব্যবহার করে। ডেভিড পার্নাস ১৯ 1971১ সালের পুরানো নিবন্ধগুলিতে এ সমস্যাটি উল্লেখ করেছিলেন যেখানে তিনি ডিজাইনে তথ্য গোপন করার প্রস্তাব করেছিলেন।

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


0

আমি আপনার প্রশ্নের উত্তর একটি প্রশ্ন দিয়ে দেব; যখন আপনি এই সকালে কাজ চালিয়েছেন (আমি ধরে নিলাম আপনি বাস্তবে এটি করেছিলেন), আপনি কী ঠিক যত্ন নিয়েছিলেন যে ইঞ্জিন কীভাবে জ্বালানী-বায়ু মিশ্রণের জন্য ভালভগুলি খুলল এবং সেগুলি জ্বলবে? না। আপনি যখন রাস্তায় গাড়ি চালাচ্ছেন তখন আপনার গাড়ির ইঞ্জিন কীভাবে কাজ করবে সেদিকে খেয়াল নেই। আপনি যত্ন এটি আছে হবে।

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

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

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.