আমি এমন একটি লাইব্রেরির মূল্যায়ন করছি যার পাবলিক এপিআই বর্তমানে এর মতো দেখাচ্ছে:
libengine.h
/* Handle, used for all APIs */ typedef size_t enh; /* Create new engine instance; result returned in handle */ int en_open(int mode, enh *handle); /* Start an engine */ int en_start(enh handle); /* Add a new hook to the engine; hook handle returned in h2 */ int en_add_hook(enh handle, int hooknum, enh *h2);
নোট যে enhএকটি জেনেরিক হ্যান্ডেল, বিভিন্ন ডিটাটাইপগুলি ( ইঞ্জিন এবং হুকস ) এর হ্যান্ডেল হিসাবে ব্যবহৃত ।
অভ্যন্তরীণভাবে, এপিআইয়ের বেশিরভাগ অবশ্যই অভ্যন্তরীণ কাঠামোতে "হ্যান্ডেল" ফেলে দেয় যা তারা করেছে malloc:
engine.c
struct engine { // ... implementation details ... }; int en_open(int mode, *enh handle) { struct engine *en; en = malloc(sizeof(*en)); if (!en) return -1; // ...initialization... *handle = (enh)en; return 0; } int en_start(enh handle) { struct engine *en = (struct engine*)handle; return en->start(en); }
ব্যক্তিগতভাবে, আমি জিনিসগুলির পিছনে জিনিসগুলি গোপন করা ঘৃণা করি typedef, বিশেষত যখন এটি ধরণের সুরক্ষার সাথে আপস করে। (একটি দেওয়া হল enh, আমি এটি কীভাবে জানি যা এটি আসলে উল্লেখ করছে?)
সুতরাং আমি নীচের অনুরোধটি জমা দিলাম, নিম্নলিখিত এপিআই পরিবর্তনের পরামর্শ দিয়েছি ( পুরো লাইব্রেরিটি অনুসারে সংশোধন করার পরে ):
libengine.h
struct engine; /* Forward declaration */
typedef size_t hook_h; /* Still a handle, for other reasons */
/* Create new engine instance, result returned in en */
int en_open(int mode, struct engine **en);
/* Start an engine */
int en_start(struct engine *en);
/* Add a new hook to the engine; hook handle returned in hh */
int en_add_hook(struct engine *en, int hooknum, hook_h *hh);
অবশ্যই, এটি অভ্যন্তরীণ এপিআই বাস্তবায়নগুলি আরও ভাল দেখায়, কাস্টগুলি বাদ দেয় এবং গ্রাহকের দৃষ্টিকোণ থেকে / ধরণের সুরক্ষা বজায় রাখে।
libengine.c
struct engine
{
// ... implementation details ...
};
int en_open(int mode, struct engine **en)
{
struct engine *_e;
_e = malloc(sizeof(*_e));
if (!_e)
return -1;
// ...initialization...
*en = _e;
return 0;
}
int en_start(struct engine *en)
{
return en->start(en);
}
আমি নিম্নলিখিত কারণে এটি পছন্দ:
- সুরক্ষা যুক্ত করা হয়েছে
- প্রকার এবং তাদের উদ্দেশ্যগুলির উন্নত স্পষ্টতা
- সরানো কাস্টস এবং
typedefএস - এটি সি তে অস্বচ্ছ ধরণের জন্য প্রস্তাবিত প্যাটার্ন অনুসরণ করে
যাইহোক, প্রকল্পের মালিকটি টানার অনুরোধটি উপেক্ষা করলেন (প্যারাফ্রেসড):
ব্যক্তিগতভাবে আমি প্রকাশের ধারণা পছন্দ করি না
struct engine। আমি এখনও মনে করি বর্তমান উপায়টি পরিষ্কার এবং আরও বন্ধুত্বপূর্ণ।প্রথমদিকে আমি হুক হ্যান্ডেলের জন্য অন্য একটি ডেটা ধরণের ব্যবহার করেছি, তবে তারপরে ব্যবহারের জন্য স্যুইচ করার সিদ্ধান্ত নিয়েছে
enh, তাই সব ধরণের হ্যান্ডলগুলি এটিকে সরল রাখতে একই ডেটা টাইপ ভাগ করে দেয় share যদি এটি বিভ্রান্তিকর হয় তবে আমরা অবশ্যই অন্য একটি ডেটা ধরণের ব্যবহার করতে পারি।আসুন দেখে নেওয়া যাক এই জনসংযোগ সম্পর্কে অন্যরা কী ভাবছে।
এই গ্রন্থাগারটি বর্তমানে একটি বেসরকারী বিটা পর্যায়ে রয়েছে, তাই চিন্তার মতো ভোক্তার কোড নেই (এখনও) isn't এছাড়াও, আমি নামগুলি কিছুটা অবহেলা করেছি।
নামযুক্ত, অস্বচ্ছ স্ট্রাক্টের চেয়ে কীভাবে অস্বচ্ছ হ্যান্ডেলটি ভাল?
দ্রষ্টব্য: আমি কোড রিভিউতে এই প্রশ্নটি জিজ্ঞাসা করেছি , যেখানে এটি বন্ধ ছিল।