"তথ্য" প্রত্যয় সহ ক্লাসের নামকরণের পিছনে কী ধারণা রয়েছে, উদাহরণস্বরূপ: "সোমারক্লাস" এবং "সামারক্লাসআইএনফো"?

20

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

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

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

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

এছাড়াও, সমস্ত সাধারণ উদাহরণ Employeeশ্রেণিটি অবশ্যই প্রকৃত ব্যক্তির উপস্থাপনা, তবে EmployeeInfoআমি যতদূর জানি কেউই পরিবর্তে ক্লাসটির নামকরণ করার পরামর্শ দেবে না।

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

Directoryএবং DirectoryInfoক্লাস;
Fileএবং FileInfoক্লাস;
ConnectionInfoবর্গ (কোনও সংবাদদাতা Connectionশ্রেণি ছাড়াই );
DeviceInfoবর্গ (কোনও সংবাদদাতা Deviceশ্রেণি ছাড়াই );

সুতরাং আমার প্রশ্ন: এই নামকরণের ধরণটি ব্যবহার করার বিষয়ে কি সাধারণ যুক্তি আছে? এমন কিছু মামলা রয়েছে যেখানে নামের ( Thingএবং ThingInfo) এবং অন্যান্য ক্ষেত্রে কেবল জুটি থাকা ThingInfoবা বর্গের উপস্থিতি থাকা উচিত, যেখানে কেবল এই Thingশ্রেণীর কোনও অংশ নেই?

— heltonbiker
সূত্র

5

বেন অ্যারনসন নীচে তার উত্তরে এটি পেয়েছিলেন; Infoপ্রত্যয় একটি আলাদা staticশ্রেণী তার stateful সহযোগীর থেকে উপযোগ পদ্ধতি রয়েছে। এটি যেমন "সেরা অনুশীলন" নয়; এটি কেবল একটি উপায় যা .NET টিম একটি নির্দিষ্ট সমস্যা সমাধানের জন্য এলো। তারা শুধু সহজে থাকতে পারে সঙ্গে আসা পর্যন্ত FileUtilityএবং Fileকিন্তু File.DoSomething()এবং FileInfo.FileNameভালভাবে পড়ার বলে মনে হচ্ছে।

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

1

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

— কেভিন ক্রামউইদে

1

সত্যি? "কেউ এমপ্লয়িআইএনফো ক্লাসের নাম দেওয়ার পরামর্শ দিবে না" ?? কেউ কিছু? এটি এতটা সুস্পষ্ট না বলে কিছুটা শক্তিশালী বলে মনে হয়।

— ThePopMachine

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

— হেলটনবাইকার

1

chegg.com/homework-help/questions-and-answers/... mathworks.com/help/matlab/matlab_oop/... stackoverflow.com/questions/22082434/binarytree-employee-class cplusplus.com/forum/general/24222

— ThePopMachine

21

আমার মনে হয় "তথ্য" একটি ভুল নাম। অবজেক্টগুলির স্থিতি এবং ক্রিয়া রয়েছে: "তথ্য" "রাষ্ট্র" এর অন্য একটি নাম যা ইতিমধ্যে OOP এ বেকড রয়েছে।

আপনি এখানে আসলে কী মডেল করার চেষ্টা করছেন? আপনার এমন একটি বিষয় দরকার যা সফ্টওয়্যারটিতে হার্ডওয়্যার উপস্থাপন করে যাতে অন্য কোড এটি ব্যবহার করতে পারে।

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

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

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

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

আমি কীভাবে একটি তাপমাত্রা সংবেদকের জন্য শ্রেণি শ্রেণিবিন্যাস ডিজাইন করব তার একটি উদাহরণ এখানে দেওয়া হয়েছে:

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

শীর্ষ স্তরে প্রতিটি হার্ডওয়্যার ধরণের জন্য আপনার ইন্টারফেস থাকবে। তারা সি # ডেটা টাইপ ব্যবহার করে ডিভাইসগুলিতে আপনার সি # কোড গ্রহণ করবে এমন ক্রিয়াগুলি বর্ণনা করে (যেমন বাইট অ্যারে যা কাঁচা ডিভাইস ড্রাইভার ব্যবহার করতে পারে) নয়।

একই স্তরে আপনার প্রতিটি হার্ডওয়্যার প্রকারের জন্য একটি উদাহরণ সহ একটি অঙ্কের শ্রেণি রয়েছে। তাপমাত্রা সেন্সর এক ধরণের, আর্দ্রতা সেন্সর অন্য হতে পারে।

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

প্রতিটি ডিভাইস শ্রেণীর নিজস্ব প্রাইভেট কম (যোগাযোগ) শ্রেণি থাকে যা হার্ডওয়্যারের সাথে কথা বলার নিম্ন-স্তরের কাজ পরিচালনা করে।

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

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

এই উত্তরে বর্ণিত নকশাটি দেখানো ইউএমএল শ্রেণীর চিত্রের উদাহরণ

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

খুব আকর্ষণীয় উত্তর। আমি দ্রুত সম্পাদনার জন্য জিজ্ঞাসা করব: আপনি উল্লিখিত চারটি শ্রেণীর মধ্যে উত্তরাধিকার / রক্ষণাবেক্ষণ / সহযোগিতা কী তা আরও স্পষ্টভাবে ছেড়ে দিন। আপনাকে অনেক ধন্যবাদ!

— হেলটনবাইকার

আমি একটি ইউএমএল শ্রেণির চিত্রটি যুক্ত করেছি। এটা কি সাহায্য করে?

2

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

— হেলটনবাইকার

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

11

এখানে একক একত্রীকরণের সম্মেলনটি পাওয়া কিছুটা কঠিন হতে পারে কারণ এই ক্লাসগুলি বেশ কয়েকটি নেমস্পেসে ছড়িয়ে আছে, ( ConnectionInfoমনে হয় CrystalDecisionsএবং এটি DeviceInfoভিতরে রয়েছে System.Reporting.WebForms)।

এই উদাহরণগুলির দিকে তাকালেও, প্রত্যয়টির দুটি স্বতন্ত্র ব্যবহার রয়েছে বলে মনে হয়:

ক্লাস সরবরাহকারী ক্লাসের সাথে স্ট্যাটিক পদ্ধতি সরবরাহকারী একটি শ্রেণীর পার্থক্য করা। System.IOক্লাসগুলির ক্ষেত্রে এটি তাদের বর্ণনার দ্বারা নিম্নরূপ:

ডিরেক্টরি :

ডিরেক্টরি এবং উপ-ডিরেক্টরিগুলির মাধ্যমে তৈরি, চলন এবং গণনার স্থির পদ্ধতি উদ্ভাসিত করে। এই শ্রেণিটি উত্তরাধিকারসূত্রে প্রাপ্ত হতে পারে না।

DirectoryInfo :

ডিরেক্টরি এবং উপ-ডিরেক্টরিগুলির মাধ্যমে তৈরি, চলন এবং গণনার জন্য উদাহরণ পদ্ধতি প্রকাশ করে। এই শ্রেণিটি উত্তরাধিকারসূত্রে প্রাপ্ত হতে পারে না।

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

আমি মনে করি যে বাক্যটির শেষ অংশটি ধাঁধাটির টুকরা হতে পারে যা বলে, ConnectionInfoথেকে আলাদা করে EmployeeInfo। যদি আমার একটি ক্লাস বলা Connectionহত, আমি যুক্তিসঙ্গতভাবে এটির সাথে সংযোগের যে কার্যকারিতা সরবরাহ করে তা প্রত্যাশা করতাম- আমি যেমন পদ্ধতিগুলির সন্ধান করছিলাম void Open()ইত্যাদি। তবে, তাদের ডান মনের কেউই আশা করবে না যে কোনও Employeeশ্রেণি আসলেই পারে কি একটি বাস্তব না Employeeমত পদ্ধতি জন্য কেমন, বা void DoPaperwork()বা bool TryDiscreetlyBrowseFacebook()।

— বেন অ্যারনসন
সূত্র

1

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

— হেলটনবাইকার

4

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

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

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

— supercat
সূত্র

1

এটি একেবারেই ভুল নয়, তবে এটি NET এর নামকরণের ধরণগুলি খুব ভালভাবে ব্যাখ্যা করার জন্য উপস্থিত হয় না, যেহেতু Fileশ্রেণিটি ইনস্ট্যান্ট করা FileInfoযায় না এবং অবজেক্টগুলি অন্তর্নিহিত ফাইল সিস্টেমের সাহায্যে আপডেট করে।

— নাথান টগি

@ নাথানটগি আমি সম্মত হই যে এটি নেট নামকরণের সম্মেলনে NET- র সাথে ভালভাবে জড়িত নয়, তবে আমার বর্তমান সমস্যা সম্পর্কে আমি বিশ্বাস করি এটি অত্যন্ত প্রাসঙ্গিক এবং এটি একটি ধারাবাহিক সমাধান প্ররোচিত করতে পারে। আমি এই উত্তরটিকে

— অগ্রাহ্য

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

— সুপারক্যাট

@ সুপের্যাট: অবশ্যই; "কেন করে। নেট এই জিনিসগুলি করে?" এমন প্রশ্নের জবাব দেওয়ার পক্ষে এটি কেবল অদ্ভুত বলে মনে হচ্ছে? "এটি% THIS_WAY%" করা ভাল ধারণা হবে be

— নাথান টগি

@ নাথানটুগি: আমি প্রশ্নে থাকা ক্লাসগুলির সঠিক বিবরণটি মনে করতে পারি নি, তবে আমি ভেবেছিলাম যে FileInfoকেবলমাত্র স্থিতিযুক্ত-কৃত তথ্য রাখা আছে। এটা না? এছাড়াও, আমি অ-এক্সক্লুসিভ মোডে ফাইলগুলি খোলার উপলক্ষ কখনও পাইনি, তবে এটি সম্ভব হওয়া উচিত এবং আমি সেখানে একটি পদ্ধতি উপস্থিত থাকার আশা করবো যা কোনও ফাইলের বর্তমান আকারের প্রতিবেদন করবে, এমনকি খোলার জন্য ব্যবহৃত বস্তুটি না থাকলেও নামক File(সাধারণত আমি শুধু ব্যবহার ReadAllBytes, WriteAllBytes, ReadAllText, WriteAllText, ইত্যাদি)।

— সুপারক্যাট

2

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

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

আমি এই পার্থক্য পছন্দ করি না। সমস্ত অবজেক্টগুলি "সফটওয়্যারটিতে প্রতিনিধিত্ব [গুলি]"। "অবজেক্ট" শব্দের অর্থ এটাই।

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

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

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

— কেভিন
সূত্র

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

— হেলটনবাইকার

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

— কেভিন

1

আবার "মহিমান্বিত স্ট্রাক্ট" অংশের জন্য কুদোস :)। এটি আমাকে আঙ্কেল ববসের "ক্লিন কোড" বইয়ের Chapter ষ্ঠ অধ্যায় সম্পর্কিত সম্পর্কিত উক্তিটির কথা মনে করিয়ে দেয়: "পরিপক্ক প্রোগ্রামাররা জানেন যে সবকিছুই একটি অবজেক্টের ধারণা th

— হেল্টনবাইকার

2

আমি সেই প্রসঙ্গে / ডোমেনের বিষয়টি বলব, যেহেতু আমাদের উচ্চ স্তরের ব্যবসায়িক লজিক কোড এবং নিম্ন স্তরের মডেল, আর্কিটেকচার উপাদান এবং তাই ...

'ইনফো', 'ডেটা', 'ম্যানেজার', 'অবজেক্ট', 'ক্লাস', 'মডেল', 'কন্ট্রোলার' ইত্যাদি গন্ধযুক্ত প্রত্যয় হতে পারে, বিশেষত নিম্ন স্তরে, যেহেতু প্রতিটি বস্তুর কিছু তথ্য বা ডেটা থাকে তাই যে তথ্য প্রয়োজন হয় না।

ব্যবসায়ের ডোমেনের শ্রেণীর নামগুলি এটি সম্পর্কে সমস্ত স্টেকহোল্ডার আলাপের মতো হওয়া উচিত, এটি অদ্ভুত মনে হয় বা 100% সঠিক ভাষা না হয় তা বিবেচনা করুন।

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

আপনার সেন্সর দৃশ্যে আমি SensorInfoআপনার সেন্সরটি কী তা সংরক্ষণ করার আশা করব না তবে SensorSpec। Infoইমো আরও উত্পন্ন তথ্য, যেমন FileInfoআকারের মতো কিছু, আপনি সংরক্ষণ করেন না বা যে ফাইলপথটি পথ এবং ফাইলের নাম থেকে তৈরি করা হয়েছে, ইত্যাদি etc.

আর একটা কথা:

কম্পিউটার বিজ্ঞানে কেবল দুটি শক্ত জিনিস রয়েছে: ক্যাশে অবৈধকরণ এবং নামকরণের জিনিস।

- ফিল কার্লটন

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

— Aitch
সূত্র

1

থিংইনফো থিংয়ের জন্য দুর্দান্ত পঠনযোগ্য প্রক্সি হিসাবে পরিবেশন করতে পারে।

দেখতে http://www.dofactory.com/net/proxy-design-pattern

প্রক্সি: "এটিতে অ্যাক্সেস নিয়ন্ত্রণ করতে অন্য কোনও সামগ্রীর জন্য সার্গেট বা স্থানধারক সরবরাহ করুন" "

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

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

— Shmoken
সূত্র

চমৎকার। আজকের আগে আমি আমার স্থাপত্যের প্রয়োজনীয়তাগুলি বিশ্লেষণ করছিলাম, প্রশ্নটিতে আমি যে ক্লাসগুলি ব্যবহার করেছি সেগুলি সম্পর্কে এবং এই একই সিদ্ধান্তে পৌঁছেছি। আমার ক্ষেত্রে, আমার কাছে এমন একটি রয়েছে Receiverযা অনেকগুলি থেকে ডেটা স্ট্রিম গ্রহণ করে Sensor। ধারণাটি হ'ল: প্রাপকের প্রকৃত সেন্সরগুলি বিমূর্ত করা উচিত। তবে সমস্যাটি হ'ল: আমার সেন্সর তথ্য দরকার যাতে আমি সেগুলি কোনও ফাইল হেডারে লিখতে পারি। সমাধান: প্রত্যেকের IReceiverএকটি তালিকা থাকবে SensorInfo। আমি যদি প্রাপকের কাছে আদেশগুলি প্রেরণ করি যা ইঙ্গিত দেয় যে সেন্সর রাষ্ট্র পরিবর্তন করে, তবে এই পরিবর্তনগুলি প্রতিফলিত হবে (গেটারের মাধ্যমে) সম্পর্কিত SensorInfo।

— হেলটনবাইকার

(অব্যাহত ...) অর্থাৎ: আমি নিজে সেন্সরগুলির সাথে কথা বলি না, আমি কেবলমাত্র উচ্চ-স্তরের কমান্ডের মাধ্যমে রিসিভারের সাথে কথা বলি, এবং রিসিভার প্রতিটি সেন্সরের সাথে কথা বলে। তবে অবশেষে সেন্সরগুলির কাছ থেকে আমার তথ্য প্রয়োজন যা আমি এটির List<SensorInfo>পাঠ্য সম্পত্তি হিসাবে রিসিভার উদাহরণ থেকে পাই ।

— হেলটনবাইকার

1

এখনও পর্যন্ত এই প্রশ্নের কেউ এই নামকরণ কনভেনশনটির আসল কারণটি গ্রহণ করেছে বলে মনে হয় না।

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

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

বিসিএলে আসলে একটি উদাহরণ রয়েছে যেখানে উভয় শ্রেণি বিদ্যমান: এ ServiceControllerএকটি শ্রেণি যা একটি উইন্ডোজ পরিষেবা বর্ণনা করে। প্রতিটি পরিষেবার জন্য এই জাতীয় সংখ্যক নিয়ামক থাকতে পারে। একটি ServiceBase(বা উত্পন্ন শ্রেণি) হ'ল আসল পরিষেবা এবং এটি স্বতন্ত্র পরিষেবা প্রতি এর একাধিক দৃষ্টান্ত ধারণাগতভাবে বিবেচনা করে না।

— usr ডিরেক্টরির
সূত্র

এটি Proxy@ শ্মোকেন দ্বারা উল্লিখিত প্যাটার্নের মতো বলে মনে হচ্ছে, তাই না?

— হেলটনবাইকার

@ হেলটনবাইকার এটির প্রক্সি হওয়ার দরকার নেই। এটি এমন কোনও বস্তু হতে পারে যা এটি বর্ণিত জিনিসটির সাথে কোনওভাবেই সংযুক্ত নেই। উদাহরণস্বরূপ আপনি EmployeeInfoএকটি ওয়েব পরিষেবা থেকে একটি পেতে পারেন । এটি প্রক্সি নয়। আরও উদাহরণ: একটি AddressInfoএমনকি নেই আছে একটি ঠিকানা একটি সত্তা নয় কারণ একটা জিনিস এটা প্রক্সি পারেন। এটি একটি একা মান

— usr ডিরেক্টরির

1

আমি দেখতে পাচ্ছি!

— হেলটনবাইকার