একটি প্রয়োগের আগে আমি কি একটি ইন্টারফেস এপিআই লিখব?


14

আমি সম্প্রতি আরও "সংগঠিত" প্রোগ্রামিংয়ের জন্য আগ্রহ প্রকাশ করেছি এবং আমি শিখছি যে আমার কোনও ইন্টারফেসে প্রোগ্রামিং করা উচিত, বাস্তবায়ন নয়। এই বিষয়টি মাথায় রেখে, যেখানে সম্ভব সেখানে প্রয়োগের কথা লেখার আগে ইন্টারফেসে কোনও প্রকল্প "স্কেচ" করা ভাল কি?

এবং যদি এটি হয়, তৃতীয় পক্ষের গ্রন্থাগারগুলি (অর্থাত্ লিডগ্রেন) ব্যবহারের ক্ষেত্রে, আমি কি সেগুলি ইন্টারফেসগুলিতেও আবৃত করে আইওসি পাত্রে সমাধান করতে পারি, বা তাদের ইন্টারফেসগুলিতে প্রকাশ করা কি ঠিক হবে?


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

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

উত্তর:


8

দুর্ভাগ্যক্রমে, আপনি এটি ব্যক্তিগত পছন্দের দিকে প্রায়শই ফুটে উঠবেন।

আপনি এতক্ষণ যা বর্ণনা করেছেন তা দুর্দান্ত মনে হয়েছে। আসলে, আপনি যদি চান (এবং আমি এটি প্রস্তাব দিই) তবে আপনি নীচের পদ্ধতিটি ব্যবহার করতে পারেন:

  1. ইন্টারফেস, অ্যাবস্ট্রাক্ট ক্লাস (স্ট্যাবড) এবং ক্লাস (এছাড়াও স্টাবড) হিসাবে আপনার অ্যাপ্লিকেশন কঙ্কাল লিখুন
  2. সেই ইন্টারফেস এবং স্টাবগুলির বিরুদ্ধে আপনার পরীক্ষাগুলি লিখুন (তারা আপাতত ব্যর্থ হবে)
  3. আপনার প্রয়োগগুলি লিখুন (আপনার পরীক্ষা শেষ হওয়ার সাথে সাথে আপনার পরীক্ষাগুলি পাস করা শুরু হবে)

আপনি আরও "সংগঠিত" কোড লেখার চেষ্টা করার দিকে মনোনিবেশ করছেন। টিডিডি অনুসরণ করা আপনাকে এটিতে সহায়তা করবে।

কিছু অতিরিক্ত পয়েন্ট:

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

1
এটি আমি প্রথমে ভেবেছিলাম তবে আমাকে বলা হয়েছিল যে এটি ইয়াজিএনআই নীতি লঙ্ঘন করবে। আমার প্রচুর প্রকল্পগুলির সাথে আমি যে সমস্যাটি পাই যা কখনই শেষ হয় না তা হ'ল আমি যে পরিমাণ ব্লব কোড লিখেছি তার সাথে তারা দ্রুত রক্ষণাবেক্ষণযোগ্য হয়ে যায়, কারণ আমি এটিকে সঠিকভাবে সংগঠিত করি না বা আমার আক্রমণাত্মক পরিকল্পনার পরিকল্পনা করি না।
ড্যান প্যান্ট্রি

কোন অংশটি YAGNI লঙ্ঘন করবে?
মেটাফাইট

তৃতীয় পক্ষের লাইব্রেরি মোড়ানো।
ড্যান প্যান্ট্রি

2
আমার ধারণা এটি নিচে নেমে আসে: তৃতীয় পক্ষের লাইব্রেরিটির পরিবর্তনগুলি কী কী? যদি এর 0% সম্ভাবনা থাকে তবে অবশ্যই YAGNI। তবে, এটি খুব কমই ঘটে। এছাড়াও, আপনার 3 য় পক্ষের লিবস মোড়ানো আপনার অন্যান্য
কোডকে

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

13

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

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

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

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

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


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

এপিআইগুলির জন্য কি কোনও নামকরণের সম্মেলন রয়েছে যা কেবলমাত্র ইন্টারফেস যা আমি পুরো জায়গা জুড়ে ব্যবহার করে শেষ করব? যেমন, যদি আমি একটি কমান্ড প্যাটার্নটি করি, আমি কি এটি "কমান্ডেবল" বলি?
স্নুপ

@ স্টেভিভ বিভিন্ন, যেমন IBlahপ্রয়োগ Blahবা Blahপ্রয়োগ করে বাস্তবায়ন করেছেন BlahImpl। আমি উভয়ই অপছন্দ করি, এবং এর Blahদ্বারা বাস্তবায়িত OralBlah, WrittenBlahবা ব্যবহার করার প্রবণতা রাখি ASLBlah। তবে যথারীতি, কোনও সাধারণ মানের তুলনায় আপনার বিদ্যমান কোড বেস এবং প্রত্যাশা মেনে চলা আরও গুরুত্বপূর্ণ।
কিলিয়ান ফট

4

কেবলমাত্র ইন্টারফেসে স্ল্যাশলি প্রোগ্রামিংয়ের পরিবর্তে টেস্ট ড্রাইভেন ডেভলপমেন্ট / ডিজাইনের (টিডিডি) তাকাতে হবে না কেন?

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

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

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

তৃতীয় পক্ষের গ্রন্থাগারগুলি ব্যবহার করার জন্য আমি তাদের যথাযথ যেখানে আপনার উপযুক্ত বিসর্জনগুলিতে মোড়ানো সুপারিশ করব; এবং আপনার API এর ক্লায়েন্টদের তাদের সম্পর্কে "জানতে" দেবেন না।

শুভকামনা!

[সম্পাদনা: মেগাফ্লাইটের উত্তর দেখেছি - সম্পূর্ণ সম্মত]


2
টিডিডি আপনার স্পষ্টতই ইমপ্লিমেন্টেশন না করে ইন্টারফেসের ক্ষেত্রে বিবেচনা করেছে, যদিও এটি আনুষ্ঠানিক "ইন্টারফেস" ঘোষণা হতে পারে না।
ডগএম

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

2

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

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


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

1

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

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

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

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