সিতে "ধ্বংসকারীদের" বাদ দেওয়া কি YAGNI কে অনেক দূরে নিয়ে যাচ্ছে?


9

আমি ও-এর মতো কৌশল ব্যবহার করে সি-তে একটি মাঝারি এমবেডেড অ্যাপ্লিকেশন নিয়ে কাজ করছি। আমার "ক্লাস" হ'ল .h / .c মডিউলগুলি ডেটা স্ট্রাক্ট এবং ফাংশন পয়েন্টার স্ট্রাক্টগুলি এনক্যাপসুলেশন, পলিমারফিজম এবং নির্ভরতা ইনজেকশন অনুকরণ করতে ব্যবহার করে।

এখন, কেউ প্রত্যাশা করবে যে কোনও myModule_create(void)অনুষ্ঠান একটি myModule_destroy(pointer)প্রতিপক্ষের সাথে আসবে । তবে প্রকল্পটি এম্বেড করা হচ্ছে, বাস্তবসম্মতভাবে ইনস্ট্যান্ট করা সংস্থানগুলি কখনই প্রকাশ করা উচিত নয়।

আমি বলতে চাইছি, যদি আমার কাছে 4 টি ইউআরটি সিরিয়াল বন্দর থাকে এবং আমি তাদের প্রয়োজনীয় পিন এবং সেটিংস সহ 4 টি ইউআরটি দৃষ্টান্ত তৈরি করি, রানটাইম চলাকালীন কোনও সময়ে ইউআরটি # 2 ধ্বংস করার কোনও কারণ নেই।

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


4
আপনি যদি অবজেক্টটি নিষ্পত্তি করার কোনও উপায় না সরবরাহ করেন তবে আপনি একটি স্পষ্ট বার্তাটি পাঠাচ্ছেন যে তাদের একবার "অসীম" জীবনকাল তৈরি হয়ে গেছে। এটি যদি আপনার অ্যাপ্লিকেশনটিকে বোঝায় তবে আমি বলি: এটি করুন।
গ্ল্যাম্পার্ট

4
আপনি যদি আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে টাইপটি সংযুক্ত করে এতদূর যেতে চান তবে কেন একটি myModule_create(void)কার্যকারিতা থাকবে? আপনি যে ইন্টারফেসটি প্রকাশ করবেন তার মধ্যে আপনি যে নির্দিষ্ট উদাহরণগুলি ব্যবহারের প্রত্যাশা করেছেন তা কেবল হার্ড-কোড করতে পারেন।
ডোভাল

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

2
@ গ্ল্যাম্পার্ট নখ এটি; আমি যুক্ত করব যে আপনার তৈরি করা ফাংশনের ডকুমেন্টেশনে প্রত্যাশিত-অসীম আজীবন পরিষ্কার করা উচিত।
ব্লারফ্ল

উত্তর:


11

আপনি যদি অবজেক্টটি নিষ্পত্তি করার কোনও উপায় না সরবরাহ করেন তবে আপনি একটি স্পষ্ট বার্তাটি পাঠাচ্ছেন যে তাদের একবার "অসীম" জীবনকাল তৈরি হয়ে গেছে। এটি যদি আপনার অ্যাপ্লিকেশনটিকে বোঝায় তবে আমি বলি: এটি করুন।

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

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


3

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

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


মনে রাখবেন যে আপনি যদি কেবলমাত্র বরাদ্দগুলি শুরু করার সময় শুরু করেন তবে এটি প্রযোজ্য না, যা মেমরির সীমাবদ্ধতা ডিভাইসে আমি গুরুত্ব সহকারে বিবেচনা করব pattern
কোডসইনচাউস 5:38

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

3

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

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

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

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

এটি এইভাবে করা: আপনার পরীক্ষার / ভবিষ্যতের পুনঃব্যবহারের জন্য ডেস্ট্রাক্টর রয়েছে এবং আপনি YAGNI এর নকশা উদ্দেশ্যগুলি এবং "কোনও ডেড কোড নয়" বিধিকে সন্তুষ্ট করেছেন।


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

0

আপনার কোনও অনি-ডেসট্রেক্টর থাকতে পারে, এরকম কিছু

  void noop_destructor(void*) {};

তারপরে Uartসম্ভবত ব্যবহারের ডেস্ট্রাক্টর সেট করুন

  #define Uart_destructor noop_destructor

(প্রয়োজনে উপযুক্ত castালাই যুক্ত করুন)

ডকুমেন্ট করতে ভুলবেন না আপনি এমনকি চান

 #define Uart_destructor abort

বিকল্পভাবে, সাধারণ কোড কলিং ডেস্ট্রাক্টর ক্ষেত্রে বিশেষ কেসটি যখন ডাস্ট্রাক্টর পয়েন্টার ফাংশনটি NULLকল করা এড়াতে হয়।

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