সরল আইওএস সফ্টওয়্যার ডিজাইনের চারটি বিধি

1990 এর দশকের শেষদিকে, এক্সট্রিম প্রোগ্রামিং বিকাশের সময় বিখ্যাত সফ্টওয়্যার বিকাশকারী কেন্ট বেক সহজ সফ্টওয়্যার ডিজাইনের নিয়মের একটি তালিকা নিয়ে আসে।

কেন্ট বেকের মতে, একটি ভাল সফ্টওয়্যার ডিজাইন:

  • সমস্ত পরীক্ষা চালায়
  • কোনও সদৃশ থাকে
  • প্রোগ্রামার এর অভিপ্রায় প্রকাশ করে
  • ক্লাস এবং পদ্ধতি সংখ্যা হ্রাস করে

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

সমস্ত পরীক্ষা চালায়

সফ্টওয়্যার ডিজাইন আমাদের এমন একটি সিস্টেম তৈরি করতে সহায়তা করে যা প্রয়োজন অনুযায়ী কাজ করে। তবে কীভাবে আমরা যাচাই করতে পারি যে কোনও সিস্টেম প্রাথমিকভাবে তার নকশা অনুসারে কাজ করবে? উত্তরটি যাচাই করে এমন পরীক্ষা তৈরি করে creating

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

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

একক দায়িত্বের নীতি (এসআরপি)

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

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

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

এই প্রয়োগের কোডটি বর্তমানে নীচের মত দেখাচ্ছে:

আমরা এই কোডটি কীভাবে পরীক্ষা করতে পারি? আমাদের প্রথমে কি পরীক্ষা করা উচিত? দাম ছাড় কি সঠিকভাবে গণনা করা হয়? ছাড়টি পরীক্ষা করার জন্য আমরা কীভাবে পেমেন্ট ইভেন্টগুলিকে উপহাস করতে পারি?

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

আমরা দেখতে পাচ্ছি যে আমাদের পণ্য লোড করার জন্য আমাদের যুক্তি রয়েছে have আমাদের পেমেন্ট ইভেন্টগুলি রয়েছে যা ব্যবহারকারীকে ছাড়ের যোগ্য করে তোলে। আমাদের কাছে ছাড়, একটি ছাড়ের গণনা রয়েছে এবং তালিকাটি চলছে।

সুতরাং আসুন কেবল এগুলি সুইফট কোডে অনুবাদ করার চেষ্টা করি।

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

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

আমাদের পেমেন্ট ভিউ নিয়ন্ত্রক তখন নিম্নলিখিতগুলির মতো দেখতে পারেন:

আমরা এখন পরীক্ষা লিখতে পারি

  • testCalculatingFinalPriceWithoutCoupon
  • testCalculatingFinalPriceWithCoupon
  • testCouponExists

এবং আরও অনেকগুলি! এখন পৃথক অবজেক্ট তৈরি করে আমরা অযৌক্তিক অনুলিপি এড়াতে এবং এমন একটি কোডও তৈরি করেছি যার জন্য পরীক্ষাগুলি লেখা সহজ।

ইনজেকশন নির্ভরতা

দ্বিতীয় নীতিটি নির্ভরতা ইনজেকশন। এবং আমরা উপরের উদাহরণগুলি থেকে দেখেছি যে আমরা ইতিমধ্যে আমাদের অবজেক্টের আরম্ভকারীগুলিতে নির্ভরতা ইনজেকশন ব্যবহার করেছি।

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

একটি ভাল কৌশল হ'ল আমাদের অবজেক্টগুলির জন্য প্রোটোকল তৈরি করা এবং নিম্নলিখিতগুলির মতো বাস্তব এবং মক অবজেক্ট দ্বারা কংক্রিট বাস্তবায়ন সরবরাহ করা:

এখন আমরা সহজেই সিদ্ধান্ত নিতে পারি যে আমরা কোন শ্রেণি নির্ভরতা হিসাবে ইনজেক্ট করতে চাই।

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

কোডটিকে আরও পরীক্ষামূলক করে তোলা আমাদের ভঙ্গ করার ভয়কেই কেবল দূর করে না (যেহেতু আমরা পরীক্ষাটি লিখব যা আমাদের ব্যাক আপ করবে) তবে ক্লিনার কোড লেখার ক্ষেত্রেও অবদান রাখে।

নিবন্ধটির এই অংশটি কীভাবে কোড লিখতে হবে যা প্রকৃত ইউনিট পরীক্ষা লেখার চেয়ে পরীক্ষামূলক হবে more আপনি যদি ইউনিট পরীক্ষা লেখার বিষয়ে আরও জানতে চান তবে আপনি এই নিবন্ধটি পরীক্ষা করে দেখতে পারেন যেখানে আমি পরীক্ষিত চালিত বিকাশ ব্যবহার করে জীবনের খেলা তৈরি করি।

কোনও সদৃশ থাকে

সদৃশ একটি ভাল নকশা করা সিস্টেমের প্রাথমিক শত্রু। এটি অতিরিক্ত কাজ, অতিরিক্ত ঝুঁকি, প্রতিনিধিত্ব করে অপ্রয়োজনীয় জটিলতা।

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

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

এই চ্যাটটিতে আমাদের বর্তমান চ্যাটের মত একই মতামত থাকবে তবে কয়েকটি আলাদা বিধি থাকবে:

  1. চ্যাট বার্তাগুলি প্রেরণের জন্য নেটওয়ার্কের অনুরোধটি আলাদা হবে।

২. চ্যাট বার্তাগুলি সংক্ষিপ্ত হতে হবে, বার্তার জন্য 20 টির বেশি অক্ষর থাকবে না।

৩. চ্যাট বার্তাগুলি আমাদের স্থানীয় ডাটাবেসে অবিচলিত হওয়া উচিত নয়।

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

একটি নিষ্পাপ বাস্তবায়ন নিম্নলিখিতগুলির মতো হবে:

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

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

আমরা চ্যাট উপস্থাপকের জন্য একটি প্রোটোকল তৈরি করতে পারি এবং আমরা পৃথক পদ্ধতিগুলি যা চ্যাট উপস্থাপক পর্যায়ে কংক্রিট অবজেক্টগুলির দ্বারা পৃথকভাবে প্রয়োগ করা হবে।

আমরা এখন আমাদের উপস্থাপকটিকে আইসিএটপ্রেসেন্টারের সাথে সামঞ্জস্য করতে পারি

আমাদের উপস্থাপক এখন নিজের মধ্যে সাধারণ ফাংশনগুলিকে কল করে বার্তা প্রেরণ পরিচালনা করে এবং বিভিন্নভাবে প্রয়োগ করা যেতে পারে এমন ফাংশনগুলি প্রতিনিধিত্ব করে।

এখন আমরা উপস্থাপনাগুলি সরবরাহ করতে পারি যা উপস্থাপক পর্যায়ের সাথে সামঞ্জস্য করে এবং তাদের প্রয়োজনগুলির ভিত্তিতে এই ফাংশনগুলি কনফিগার করে।

আমরা যদি আমাদের ভিউ কন্ট্রোলারে নির্ভরতা ইনজেকশন ব্যবহার করি আমরা এখন দুটি ভিন্ন ক্ষেত্রে একই ভিউ কন্ট্রোলারটিকে পুনরায় ব্যবহার করতে পারি।

ডিজাইন প্যাটার্ন ব্যবহার করে আমরা আমাদের আইওএস কোডটি সত্যই সহজ করতে পারি। আপনি যদি সে সম্পর্কে আরও জানতে চান তবে নীচের নিবন্ধটি আরও ব্যাখ্যা প্রদান করে।

ভাবপূর্ণ

একটি সফ্টওয়্যার প্রকল্পের বেশিরভাগ ব্যয় দীর্ঘমেয়াদী রক্ষণাবেক্ষণে হয়। সফটওয়্যার বিকাশকারীদের জন্য কোড সহজেই পড়া এবং বজায় রাখা সহজভাবে লেখা।

আমরা ভাল নামকরণ, এসআরপি এবং রাইটিং পরীক্ষা ব্যবহার করে আরও অভিব্যক্তিক কোড সরবরাহ করতে পারি।

নামকরণ

এক নম্বর জিনিস যা কোডটিকে আরও ভাবপূর্ণ করে তোলে - এবং এটি নামকরণ করে। নাম লিখতে গুরুত্বপূর্ণ যে:

  • অভিপ্রায় প্রকাশ করুন
  • বিশৃঙ্খলা এড়ান
  • সহজেই অনুসন্ধানযোগ্য

ক্লাস এবং ফাংশনগুলির নামকরণের বিষয়টি যখন আসে তখন ক্লাস এবং ব্যবহারকারীর ক্রিয়াগুলির জন্য ক্রিয়া বা ক্রিয়া বাক্যাংশের নামগুলির জন্য একটি বিশেষ্য বা বিশেষ্য বাক্যাংশ ব্যবহার করা ভাল কৌশল।

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

এসআরপি ব্যবহার করে

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

লেখার পরীক্ষা

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

ক্লাস এবং পদ্ধতি সংখ্যা হ্রাস করুন

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

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

আইওএস-এ একটি ভাল ধারণা হ'ল কনফিগারেশন কলগুলি কেটে ফেলা হয় যা আমরা সাধারণত ভিউডিডলড বা ভিউডিডঅ্যাপার ফাংশনগুলিতে করি।

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

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

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

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

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

নিয়ন্ত্রণকারীদের কোনও অজুহাত ছাড়াই এড়ানো যায় এমন কিছু জিনিস হ'ল:

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

উপসংহারে

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

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

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

আপনার যদি কোনও প্রশ্ন বা মন্তব্য থাকে তবে নির্দ্বিধায় এখানে একটি নোট রেখে বা আমাকে arlindaliu.dev@gmail.com এ ইমেল করুন।