সম্পত্তি সম্পর্কিত কোনও সেটটিকে নিজস্ব স্ট্রাক / শ্রেণিতে গুটিয়ে রাখা কি ভাল অনুশীলন?


10

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

  1. লিঙ্কগুলি তাদের নিজস্ব বস্তুতে মোড়ানো কি ভাল অনুশীলন?
    কাঠামো ব্যবহারকারী {
       var firstName: স্ট্রিং
       var lastName: স্ট্রিং
       var ইমেল: স্ট্রিং
       var লিঙ্ক: লিঙ্ক
    }
    কাঠামো লিংক {
       var ফেসবুক: স্ট্রিং
       var ইনস্টাগ্রাম: স্ট্রিং
       var টুইটার: স্ট্রিং 
    }

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

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}
  1. এর মতো দৃশ্যে, লিঙ্কগুলি কি কোনও সংগ্রহ / তালিকা হওয়া উচিত? আমি অনুভব করেছি যে এটি কোনও তালিকা হওয়া উচিত নয় কারণ সেখানে একটি সংখ্যক লিঙ্ক বিকল্প উপলব্ধ রয়েছে, এবং ক্রমবর্ধমান সংখ্যা নয়। আমার চিন্তা কি ঠিক আছে?

  2. গেট ইউজার, গেট ইউজার, আপডেট ইউজারের মতো ইউজার অবজেক্টের মতো আমার নেটওয়ার্কিং পদ্ধতি স্থাপন করা কি ভাল অনুশীলন?

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

উত্তর:


30

আপনার হয় প্রয়োজন হবে

  • একটি জিনিস শূন্য,
  • একটি জিনিস, বা
  • জিনিস একটি নির্বিচারে সংখ্যা।

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

আমি যা প্রচার করছি তাকে শূন্য ও অনন্ত নিয়ম বলা হয় । এটি প্রথমে সুস্পষ্ট নাও হতে পারে তবে এটিই আমাকে বলে যে আপনার নকশাটি ভবিষ্যতে সহনীয় নয়।

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

এজন্য আমি ইমেলের স্ট্রিং দ্বারা বিরক্ত হই না। আমি জানি যে লিঙ্কগুলি অন্যভাবে ব্যবহৃত হয়।

সুতরাং যতক্ষণ না এই লিঙ্কগুলি আলাদাভাবে ব্যবহার করার কারণ দেখি আমি কোনও লিঙ্ক সংগ্রহের পাশে আছি।


4
FacebookProfile, InstagramProfile, ...আমি মনে করি ওপি ইতিমধ্যে প্রশ্নের উত্তর দিয়েছে। এর ভাষা আমাদের জানিয়েছে যে ব্যবহারকারীদের সামাজিক নেটওর্ক সম্পর্কিত কোনও বা একাধিক প্রোফাইল থাকতে পারে । তবে তার ভিতরে থাকা প্রোগ্রামার এই উপাদানটিকে নিছক লিঙ্কে পরিণত করেছে। কেন একটি সংগ্রহ না Profiles? আমি ক্যান্ডিডআরেঞ্জের সাথে একমত হয়েছি। আপনি ভবিষ্যতের বিষয়ে অনেক বেশি ধারণা করছেন। নতুন সামাজিক নেটওয়ার্কগুলি প্রদর্শিত হতে পারে। প্রকৃতগুলি অদৃশ্য হয়ে যেতে পারে। ব্যবহারকারীরা যেতে এবং এক নেটওয়ার্ক থেকে অন্য নেটওয়ার্কে আসতে পারে।
লাইভ

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

1
@ প্রভু আপনি কেন এটি সীমাবদ্ধ করছেন তার উপর নির্ভর করে। আমার অনুমান জিইআইতে কেবলমাত্র অনেকগুলি ফিট। যা ঠিক আছে। তবে জিইউআইয়ের কারণে ডেটা স্ট্রাকচারকে সীমাবদ্ধ করবেন না। জিইউআইগুলি একটি ঝকঝকে পরিবর্তিত হয়। ডেটা স্ট্রাকচার পরিবর্তন করতে ব্যয়বহুল। সত্যই প্রথম তাদের পাওয়ার জন্য এটি অর্থ প্রদান করে।
candied_orange

2
এটাই আসল কথা. কেবল সেই কাঠামোগুলি গ্রহণ করুন যা ভবিষ্যতের সম্ভাব্য পরিবর্তনগুলি কম বেদনাদায়ক করে তুলবে। বেশিও না, কমও না. আমরা, ক্যান্ডি এবং আমি এটি বলি কারণ আমরা (আমি বিশ্বাস করি) প্রায়শই একইরকম পরিস্থিতির মুখোমুখি হয়েছি এবং আমরা সম্ভাব্য বৈশিষ্ট্যগুলি পরিবর্তন বা বিকশিত হওয়ার সম্ভাবনাময় ভবিষ্যদ্বাণী করি। শেষ পর্যন্ত, আপনি প্রকল্পের কাছাকাছি এবং এর ভবিষ্যতের প্রত্যাশা।
লাইভ

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

6

আপনি "আমি প্রযুক্তিগত সম্ভাবনা দেখছি" ফাঁদে পড়ার পথে ge

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

তারা সমস্ত লিঙ্ক ঠিক আছে, কিন্তু একটি ব্যবহারকারী শ্রেণীর প্রসঙ্গে, এর অর্থ কি কিছু? না। এটি "ত্রুটি" এবং "সংখ্যা" নামের ক্লাস ব্যবহার করে উপ-গোষ্ঠীর মতোই অর্থহীন।

এই জাতীয় জিনিসটির সাথে ঝামেলা হ'ল এটি আপনার মডেলটিকে ঝাপসা করে। এটি কোড পাঠকটিকে ডোমেনের সম্পূর্ণ বোঝার আগে অর্থহীন থেকে অর্থবহকে আলাদা করতে বাধ্য করে।

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


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

1
আমি মনে করি না যে এটি এক্ষেত্রে সহায়ক হবে। আপনার এখনও কোনও সমস্যা নেই যা জটিলতার একটি স্তর যুক্তিকে ন্যায়সঙ্গত করে। আপনার যদি আরও অনেক সম্পত্তি থাকত তবে গ্রুপিংয়ের প্রচেষ্টায় লাভ হতে পারে (গ্রুপগুলির উপযুক্ত নাম সহ)। প্রসঙ্গ ব্যতীত কোনটি উপযুক্ত তা বলা শক্ত। নীচের অংশটি হ'ল জিনিসগুলি সহজ করা উচিত। বিকাশ প্রক্রিয়াতে আপনার পরবর্তী পদক্ষেপ যা আছে তা বোঝার জন্য এবং / অথবা এগিয়ে যেতে।
মার্টিন মাট

আমি সাধারণত ওভার ইঞ্জিনিয়ারিং এড়ানো মত, কিন্তু আমি আশ্চর্যবোধ করছ: আপনি একই কথা বলেন যদি ওপি তার ক্ষেত্র নামে করতাম link1, link2, link3? একটি ডেটা স্ট্রাকচারের নকশা ক্ষেত্রের নামের তুলনায় স্বতন্ত্র, সুতরাং আমার উদাহরণটি কার্যত সমতুল্য। এটি ভবিষ্যতপ্রকাশের বিষয়। YAGNI সাধারণত প্রয়োগ করা হত, তবে কিছু না হলে সামাজিক যোগাযোগ মাধ্যম ভাইরাল জনপ্রিয়তা এবং পরিবর্তনের জন্য নিজেকে সংবেদনশীল প্রমাণ করেছে ven প্রতিটি নতুন জনপ্রিয় সামাজিক মিডিয়া সাইটের জন্য পুনর্নবীকরণ এড়ানো বাঞ্ছনীয় বলে মনে হয়। অন্যথায়, আপনি "আরও একটি ক্ষেত্রের মধ্যে পড়ার ঝুঁকি নিয়েছেন?" ফাঁদ, যা বিশাল createণ তৈরি করতে পারে।
ফ্ল্যাটার

1

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

আমি # 2 এ আপনার চিন্তাভাবনার সাথে একমত উপরে উল্লিখিত হিসাবে, সংখ্যাটি বৃদ্ধি পেতে বা পরিবর্তনশীল হয়ে উঠলে একটি তালিকা বা অন্য সংগ্রহটি ভাল পছন্দ হবে তবে আপনার বর্ণিত দৃশ্যের জন্য নয়।

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

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