কেন কোনও শ্রেণি "বিমূর্ত" বা "চূড়ান্ত / সিল করা" ছাড়া অন্য কিছু হওয়া উচিত?

Question

জাভা / সি # প্রোগ্রামিংয়ের 10+ বছর পরে, আমি নিজেকে তৈরি করে দেখতে পাচ্ছি:

• বিমূর্ত শ্রেণি : চুক্তিটি হ'ল তাত্ক্ষণিকভাবে করা হয় না।
• চূড়ান্ত / সিল করা ক্লাস : বাস্তবায়ন বলতে অন্য কোনও কিছুকে বেস বর্গ হিসাবে পরিবেশন করা নয়।

আমি এমন কোনও পরিস্থিতির কথা ভাবতে পারি না যেখানে একটি সাধারণ "শ্রেণি" (যেমন বিমূর্ত বা চূড়ান্ত / সিল না হয়) "জ্ঞানী প্রোগ্রামিং" হবে।

কোনও শ্রেণি কেন "বিমূর্ত" বা "চূড়ান্ত / সিল করা" ছাড়া অন্য কিছু হওয়া উচিত?

সম্পাদনা

এই দুর্দান্ত নিবন্ধটি আমার উদ্বেগগুলিকে আমার চেয়ে অনেক বেশি ভালভাবে ব্যাখ্যা করে।

Comments

কারণ এটিকে বলা হয় Open/Closed principleনাClosed Principle.

— স্টুপার ইউজার

আপনি পেশাগতভাবে কি ধরণের জিনিস লিখছেন? বিষয়টি সম্পর্কে আপনার মতামতটি খুব ভালভাবে প্রভাবিত করতে পারে।

ওয়েল, আমি কিছু প্ল্যাটফর্ম ডেভস জানি যা সমস্ত কিছু সিল করে, কারণ তারা উত্তরাধিকারের ইন্টারফেসটি ছোট করতে চায়।

— কে ..

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

— মাইকেল শ

আমি অবাক হয়েছি উইন্ডো ক্লাসটিকে সিল করে পরিবর্তন করে কতগুলি ইউআই ফ্রেমওয়ার্কগুলি ভেঙে ফেলবে।

— 21:51

Answer 1

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

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

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

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

Comments

শেষ অনুচ্ছেদের জন্য +1। আমি খুব ঘন ঘন এনক্যাপসুলেশনের চেয়ে ব্যথার বড় কারণ হিসাবে তৃতীয় পক্ষের লাইব্রেরিগুলিতে (বা এমনকি স্ট্যান্ডার্ড লাইব্রেরি ক্লাস!) অনেক বেশি এনক্যাপসুলেশন পেয়েছি।

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

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

— রবার্ট হার্ভে

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

— মাইকেল

@ রবার্টহারভে যে কেবল এলএসপি ভাঙছে তারা কি প্রাপ্য তা পাচ্ছে না?

— StuperUser

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

— রবার্ট হার্ভে

Answer 2

যে হয় এরিক Lippert দ্বারা একটি মহান নিবন্ধ, কিন্তু আমি এটা আপনার দৃষ্টিকোণ সমর্থন মনে করি না।

তিনি যুক্তি দিয়েছিলেন যে অন্যের দ্বারা ব্যবহারের জন্য উন্মুক্ত সমস্ত শ্রেণিকে সিল করা উচিত, বা অন্যথায় অ-এক্সটেনসিবল করা উচিত।

আপনার ভিত্তিটি হ'ল সমস্ত ক্লাস বিমূর্ত বা সিল করা উচিত।

বড় পার্থক্য.

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

Comments

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

— ডিপিএম

আমি মনে করি যে ক্লাসগুলি বিমূর্ত বা সিল করা উচিত এমন ধারণা একটি বিস্তৃত নীতিটির অংশ, যা হ'ল তাত্ক্ষণিক শ্রেণীর ধরণের ভেরিয়েবলগুলি এড়ানো উচিত। এই জাতীয় পরিহার এ জাতীয় প্রাইভেট সদস্যদের উত্তরাধিকারী না করে একটি প্রকার তৈরি করা সম্ভব করে যা কোনও নির্দিষ্ট ধরণের গ্রাহকরা ব্যবহার করতে পারবেন। দুর্ভাগ্যক্রমে, এই জাতীয় ডিজাইনগুলি সত্যই পাবলিক-কনস্ট্রাক্টর সিনট্যাক্সের সাথে কাজ করে না। পরিবর্তে, কোড এর new List<Foo>()মতো কিছু দিয়ে প্রতিস্থাপন করতে হবে List<Foo>.CreateMutable()।

— সুপারক্যাট

Answer 3

জাভা দৃষ্টিকোণ থেকে আমি মনে করি চূড়ান্ত ক্লাসগুলি যতটা স্মার্ট তা মনে হয় না।

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

Answer 4

দুটি সাধারণ ক্ষেত্রে যেখানে আপনার ভ্যানিলা, সিলবিহীন ক্লাসের প্রয়োজন হবে :

1. প্রযুক্তিগত: আপনার যদি স্তরের স্তর রয়েছে যা দুটি স্তরেরও বেশি গভীর এবং আপনি মাঝখানে কোনও কিছু ইনস্ট্যান্ট করতে সক্ষম হতে চান।

2. মূলনীতি: নিরাপদে প্রসারিত করার জন্য ডিজাইন করা স্পষ্টতা এমন ক্লাসগুলি লেখার জন্য এটি কখনও কখনও কাম্য হয় । (আপনি যখন এরিক লিপার্টের মতো এপিআই লিখছেন বা আপনি যখন কোনও বড় প্রকল্পে কোনও দলে কাজ করছেন তখন এটি অনেক ঘটে থাকে)। কখনও কখনও আপনি এমন একটি ক্লাস লিখতে চান যা নিজেরাই সূক্ষ্মভাবে কাজ করে তবে এটি এক্সটেনসিবিলিটি মাথায় রেখে তৈরি করা হয়েছে।

Sealing পেশাদারী এটি এই সাইটে এরিক Lippert চিন্তা অনুভূতি, কিন্তু তিনি স্বীকার করে যে তারা কি করতে বর্গ "খুলুন" যাব দ্বারা extensibility জন্য নকশা।

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

দুটি। নেট নির্দিষ্ট নোট:

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

Answer 5

আমি বিশ্বাস করি যে ক্লাসগুলি অনেক লোকের মনে হওয়ার আসল কারণটি হ'ল final/ sealedবেশিরভাগ নন-অ্যাবস্ট্রাক্ট এক্সটেন্ডেবল ক্লাসগুলি সঠিকভাবে নথিভুক্ত করা হয় নি ।

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

বিষয়টি প্রোগ্রামাররা কোডটি পুনরায় ব্যবহার করতে পছন্দ করে। এমনকি যখন এটি একটি ভাল ধারণা না। কোডের এই "পুনরায় ব্যবহার" এর উত্তরাধিকার হ'ল একটি মূল সরঞ্জাম। চূড়ান্ত / সিল প্রশ্নে ফিরে যান।

চূড়ান্ত / সিল করা শ্রেণীর জন্য যথাযথ ডকুমেন্টেশন তুলনামূলকভাবে ছোট: আপনি প্রতিটি পদ্ধতিটি কী করেন, আর্গুমেন্টগুলি কী কী, রিটার্নের মান ইত্যাদি বর্ণনা করে থাকেন সমস্ত সাধারণ জিনিস।

যাইহোক, আপনি যখন যথাযথভাবে একটি প্রসারণযোগ্য ক্লাসটি নথিভুক্ত করছেন তখন আপনাকে অন্তত নিম্নলিখিতটি অন্তর্ভুক্ত করতে হবে :

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

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

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

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

আমি মনে করি যে কোনও সমাধানের উপাদানগুলি হ'ল:

• প্রথমে আপনি কোডের ক্লায়েন্ট থাকাকালীন বিস্তৃত হওয়া ভাল ধারণা এবং উত্তরাধিকারের চেয়ে সত্যিকারের সংমিশ্রনের পক্ষে হওয়া নিশ্চিত করা make
• দ্বিতীয়টি হ'ল ম্যানুয়ালটি সম্পূর্ণরূপে (আবার ক্লায়েন্ট হিসাবে) পড়তে হবে তা নিশ্চিত করার জন্য যে আপনি উল্লিখিত কিছুটিকে উপেক্ষা করছেন না।
• তৃতীয়ত, আপনি যখন ক্লায়েন্টটি কোনও কোডের টুকরো লিখবেন তখন কোডটির জন্য সঠিক ডকুমেন্টেশন লিখুন (হ্যাঁ, দীর্ঘ পথ)। ইতিবাচক উদাহরণ হিসাবে, আমি অ্যাপলের আইওএস ডক্স দিতে পারি। ব্যবহারকারীর পক্ষে সর্বদা তাদের ক্লাসগুলি যথাযথভাবে প্রসারিত করার পক্ষে এগুলি পর্যাপ্ত নয় তবে তারা অন্তত উত্তরাধিকার সম্পর্কে কিছু তথ্য অন্তর্ভুক্ত করে। বেশিরভাগ এপিআই-এর জন্য আমি যা বলতে পারি তার চেয়ে বেশি।
• চতুর্থত, আসলে আপনার নিজের শ্রেণি প্রসারিত করার চেষ্টা করুন, এটি কাজ করে তা নিশ্চিত করার জন্য। আমি এপিআই-তে অনেকগুলি নমুনা এবং পরীক্ষাগুলি অন্তর্ভুক্ত করার একটি বড় সমর্থক এবং আপনি যখন একটি পরীক্ষা করছেন তখন আপনি উত্তরাধিকার শৃঙ্খলাও পরীক্ষা করতে পারেন: এগুলি সর্বোপরি আপনার চুক্তির একটি অংশ!
• পঞ্চম, আপনি যখন সন্দেহ করছেন এমন পরিস্থিতিতে ইঙ্গিত দেয় যে ক্লাসটি বাড়ানো নয় এবং এটি করা একটি খারাপ ধারণা (টিএম)। ইঙ্গিত করুন যে এই জাতীয় অনিচ্ছাকৃত ব্যবহারের জন্য আপনাকে দায়বদ্ধ করা উচিত নয়, তবুও ক্লাসটি সিল করবেন না। স্পষ্টতই, ক্লাসটি 100% সিল করা উচিত যখন এটি কেসগুলি কভার করে না।
• অবশেষে, ক্লাসটি সিল করার সময় একটি ইন্টারমিডিয়েট হুক হিসাবে একটি ইন্টারফেস সরবরাহ করুন, যাতে ক্লায়েন্ট ক্লাসটির নিজস্ব পরিবর্তিত সংস্করণটি "পুনর্লিখন" করতে পারে এবং আপনার 'সিলড' শ্রেণীর আশেপাশে কাজ করতে পারে। এইভাবে, তিনি তার প্রয়োগের সাথে সিল করা শ্রেণিকে প্রতিস্থাপন করতে পারেন। এখন, এটি সুস্পষ্ট হওয়া উচিত, যেহেতু এটি এর সহজতম ফর্মের মধ্যে looseিলে .ালা মিশ্রণ, তবে এটি এখনও উল্লেখ করার মতো।

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

Answer 6

কোনও শ্রেণি চূড়ান্ত / সিল করা বা বিমূর্ত না হওয়া উচিত:

• এটি নিজের উপকারী, অর্থাৎ class শ্রেণীর উদাহরণ থাকা উপকারী।
• অন্যান্য শ্রেণীর সাবক্লাস / বেস শ্রেণি হওয়া সেই শ্রেণীর পক্ষে উপকারী।

উদাহরণস্বরূপ, ObservableCollection<T>সি # তে ক্লাস নিন । এটি কেবলমাত্র এর সাধারণ ক্রিয়াকলাপগুলিতে ইভেন্ট উত্থাপন যুক্ত করা দরকার Collection<T>, এজন্য এটি সাবক্লাস হয় Collection<T>। Collection<T>এটি নিজস্বভাবে একটি কার্যক্ষম শ্রেণি, এবং তাই এটি ObservableCollection<T>।

Comments

আমি যদি এর দায়িত্বে থাকি তবে আমি সম্ভবত CollectionBase(বিমূর্ত), Collection : CollectionBase(সিল করা), ObservableCollection : CollectionBase(সিল করা) করব। আপনি সংগ্রহ <টি> ঘনিষ্ঠভাবে তাকান, আপনি এটি একটি অর্ধ assed বিমূর্ত শ্রেণি দেখতে পাবেন।

— নিকোলাসের প্রতিলিপি

মাত্র দুটি পরিবর্তে তিনটি ক্লাস করা থেকে আপনার কী লাভ? এছাড়াও, Collection<T>"অর্ধহীন বিমূর্ত শ্রেণি" কীভাবে হয়?

— ফিশব্যাসকেট গর্ডো

Collection<T>সুরক্ষিত পদ্ধতি এবং বৈশিষ্ট্যগুলির মাধ্যমে প্রচুর অভ্যন্তর উন্মোচিত করে এবং স্পষ্টতই এটি বিশেষায়িত সংগ্রহের জন্য বেস ক্লাস হিসাবে বোঝানো হয়। বাস্তবায়নগুলি সম্পর্কে কোনও বিমূর্ত পদ্ধতি নেই বলে এটি আপনার কোডটি কোথায় রাখবেন বলে পরিষ্কার নয়। ObservableCollectionউত্তরাধিকার সূত্রে প্রাপ্ত Collectionএবং সীলমোহর করা হয়নি, তাই আপনি আবার এটির উত্তরাধিকারী হতে পারেন। এবং আপনি ইভেন্টগুলিকে উত্থাপন ছাড়াইItems সংগ্রহে আইটেম যুক্ত করার অনুমতি দিয়ে সুরক্ষিত সম্পত্তি অ্যাক্সেস করতে পারেন ... দুর্দান্ত।

— নিকোলাসের প্রতিলিপি

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

— supercat

Answer 7

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

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

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

Comments

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

— কাজ

চূড়ান্ত / সিল ছিল না ওওপি-তে কিছু যুক্ত করা, কারণ আমি যখন ছোট ছিলাম তখন মনে হয় না। এটি মনে হয় একটি চিন্তাভাবনা মত বৈশিষ্ট্য পরে।

— 22,12

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

— কাজ

আমি মনে করি না যে এটি একই জিনিস, কারণ এটি কেবলমাত্র একটি অপটিমাইজেশন বৈশিষ্ট্য। জাভার সমস্ত সংস্করণে সিল থাকা আমার মনে নেই তবে আমি এটিকে বেশি ব্যবহার না করায় ভুল হতে পারি।

— রিট্যাগুলার

আপনি কোডে রাখতে হবে এমন কিছু ঘোষণার হিসাবে এটি নিজেকে প্রকাশ করে কেবল তার অর্থ এটি একই জিনিস নয় thing

— কাজ

Answer 8

অবজেক্ট সিস্টেমে "সিলিং" বা "চূড়ান্তকরণ" নির্দিষ্ট অপ্টিমাইজেশনের অনুমতি দেয় কারণ সম্পূর্ণ প্রেরণের গ্রাফটি জানা যায়।

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

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

ভবিষ্যতের সম্প্রসারণ রোধের পদক্ষেপ গ্রহণের মাধ্যমে আমরা আজ কোনও নতুন কার্যকারিতা অর্জন করব না।

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

Answer 9

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

Comments

আপনি কি সম্পর্কে কথা বলছেন? কোন উপায়ে পরীক্ষা ক্লাসগুলি চূড়ান্ত / সিল / বিমূর্ত না হওয়া উচিত?

Answer 10

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

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

ক্লাস বাড়ানোর জন্য এটি একটি দুর্দান্ত সুযোগ।

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

এর উপরে প্রতিটি ধরণের ডেটা নিয়ে কাজ করার জন্য আমার আলাদা রফতানিকারক রয়েছে, সম্ভবত ব্যবহারকারীর ক্রিয়াকলাপ, লেনদেনের ডেটা, নগদ পরিচালনার ডেটা ইত্যাদি রয়েছে is

এই স্ট্যাকের উপরে আমি একটি গ্রাহক-নির্দিষ্ট স্তর রাখি যা গ্রাহকের প্রয়োজনীয় ডেটা ফাইল কাঠামো প্রয়োগ করে।

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

সুতরাং কাঠামোটি দেখে মনে হচ্ছে:

Base
 Function1
  Customer1
  Customer2
 Function2
 ...

আমার প্রাথমিক বিষয়টি হ'ল কোডটি এইভাবে আর্কিটেকিংয়ের মাধ্যমে আমি মূলত কোড পুনরায় ব্যবহারের জন্য উত্তরাধিকারের ব্যবহার করতে পারি।

আমাকে বলতে হবে যে তিনটি স্তর পেরিয়ে যাওয়ার কোনও কারণ আমি ভাবতে পারি না।

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

Answer 11

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

Comments

এটি একটি ভাল মন্তব্য, তবে সরাসরি প্রশ্নের উত্তর দেয় না। আপনার চিন্তা এখানে প্রসারিত বিবেচনা করুন।

Answer 12

আমি আপনার দৃষ্টিভঙ্গির সাথে একমত আমি মনে করি জাভাতে, ডিফল্টরূপে, ক্লাসগুলি "চূড়ান্ত" হিসাবে ঘোষণা করা উচিত। আপনি যদি এটি চূড়ান্ত না করেন, তবে নির্দিষ্টভাবে এটি প্রস্তুত করুন এবং এটি এক্সটেনশনের জন্য নথি করুন।

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

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

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