เป็นวิธีปฏิบัติที่ดีที่จะรวมชุดของคุณสมบัติที่เกี่ยวข้องไว้ในโครงสร้าง / คลาสของตัวเองหรือไม่?


10

การเขียนวัตถุผู้ใช้ในสวิฟท์ แต่คำถามของฉันเกี่ยวข้องกับภาษาที่พิมพ์ออกมาอย่างรุนแรง ผู้ใช้สามารถมีลิงก์จำนวนมาก (FacebookProfile, InstagramProfile, ฯลฯ ) คำถามสองสามข้อเกี่ยวกับเรื่องนี้

  1. เป็นการดีที่จะรวมลิงก์ในวัตถุของตนเองหรือไม่?
    struct ผู้ใช้ {
       var firstName: string
       var lastName: string
       อีเมล var: สตริง
       ลิงก์ var: ลิงค์
    }
    ลิงค์โครงสร้าง {
       var facebook: string
       var instagram: string
       var twitter: string 
    }

หรือพวกเขาควรจะหลวม? ฉันรู้ว่าทั้งสองวิธีใช้เทคนิคดี แต่สงสัยว่ามีวิธีแนะนำโดยทั่วไปหรือไม่โดยเฉพาะอย่างยิ่งสำหรับการอ่าน

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}
  1. ในสถานการณ์เช่นนี้ลิงก์ควรเป็นคอลเล็กชัน / รายการหรือไม่ ฉันคิดว่ามันไม่ควรเป็นรายการเพราะมีตัวเลือกลิงก์จำนวนคงที่และไม่ใช่จำนวนที่เพิ่มขึ้น ความคิดของฉันถูกต้องหรือไม่

  2. เป็นการดีหรือไม่ที่จะวางวิธีการเชื่อมต่อของฉันไว้ในวัตถุผู้ใช้เช่น getUsers, getUser, updateUser?

ฉันรู้ว่าสิ่งเหล่านี้อาจเป็นเรื่องส่วนตัว แต่ฉันพยายามเข้าใจว่าวิธีปฏิบัติที่ดีที่สุดในสถานการณ์ที่คล้ายคลึงกันคืออะไร จะขอบคุณพอยน์เตอร์ใด ๆ

คำตอบ:


30

คุณจะต้อง

  • ศูนย์ของสิ่ง
  • สิ่งใดสิ่งหนึ่งหรือ
  • จำนวนสิ่งโดยพลการ

ฉันตกใจที่การออกแบบของคุณคาดการณ์ว่าจำนวนลิงก์ที่ต้องการจะเป็นสามเสมอและคุณรู้ว่าชื่อของพวกเขาคืออะไรตลอดไป

สิ่งที่ฉันพระธรรมเทศนาที่เรียกว่ากฎศูนย์หนึ่งอินฟินิตี้ มันอาจจะไม่ชัดเจนในตอนแรก แต่มันเป็นสิ่งที่บอกฉันว่าการออกแบบของคุณไม่ทนทานในอนาคต

ฉันจะรู้สึกแตกต่างถ้ามีบางอย่างเกี่ยวกับลิงก์เหล่านี้ที่พิเศษสำหรับพวกเขา บางสิ่งพิเศษที่ฉันทำแตกต่างกันเมื่อเข้าถึงลิงก์ Facebook ที่ฉันไม่ได้ทำเพื่อลิงค์ทวิตเตอร์ นั่นจะทำให้พวกเขาแตกต่าง แต่นั่นไม่ได้ระบุไว้ในรหัสนี้

นั่นเป็นเหตุผลที่ฉันไม่ได้สนใจสตริงอีเมล ฉันรู้ว่ามันถูกใช้ในวิธีที่แตกต่างกันแล้วลิงค์

ดังนั้นจนกว่าฉันจะเห็นเหตุผลในการใช้ลิงก์เหล่านี้แตกต่างกันฉันอยู่ข้างคอลเลกชันลิงก์


4
FacebookProfile, InstagramProfile, ...ฉันคิดว่า OP ตอบคำถามแล้ว ภาษากำลังบอกเราว่าผู้ใช้อาจไม่มีโปรไฟล์ที่เกี่ยวข้องกับเครือข่ายทางสังคม แต่โปรแกรมเมอร์ในตัวเขา / เธอได้เปลี่ยนองค์ประกอบนี้ให้เป็นลิงก์ ทำไมไม่ได้เป็นคอลเลกชันของProfiles? ฉันเห็นด้วยกับ CandiedOrange คุณคิดมากเกี่ยวกับอนาคตมากเกินไป เครือข่ายโซเชียลใหม่อาจปรากฏขึ้น คนจริงอาจหายไป ผู้ใช้สามารถไปและกลับจากเครือข่ายหนึ่งไปยังอีกเครือข่ายหนึ่ง
Laiv

นี่เป็นการคาดเดา สมมติว่าคุณต้องการใช้โปรไฟล์เหล่านี้สำหรับการเข้าสู่ระบบสังคม มีโปรไฟล์ส่วนประกอบเรามีที่จะเริ่ม ตำแหน่งที่จะสรุปข้อมูลเกี่ยวกับการพิสูจน์ตัวตนและเซสชันปัจจุบันด้วยโปรไฟล์เหล่านี้ สิ่งนี้อาจถูกพิจารณาว่าเป็น YAGNI หรือ over-engineering แต่ไม่มีค่าอะไรที่จะต้องพิจารณาดูว่าอาจมีการร้องขอคุณสมบัติเหล่านี้หรือไม่ว่าพวกเขาจะให้คุณค่ากับแอปพลิเคชันของเราหรือไม่ ถ้าไม่เพียงแค่ทิ้งพวกเขา
Laiv

1
@Prabhu ขึ้นอยู่กับสาเหตุที่คุณ จำกัด มันไว้ ฉันเดาว่ามีหลายแบบใน GUI เท่านั้น ซึ่งเป็นเรื่องปกติ แต่อย่า จำกัด โครงสร้างข้อมูลเนื่องจาก GUI GUIs เปลี่ยนตามความต้องการ โครงสร้างข้อมูลมีค่าใช้จ่ายสูงในการเปลี่ยนแปลง มันจ่ายจริง ๆ เพื่อทำให้ถูกต้องในครั้งแรก
candied_orange

2
นั่นคือประเด็น เพียงแค่ใช้โครงสร้างเหล่านั้นที่จะทำให้การเปลี่ยนแปลงในอนาคตเป็นไปได้ที่เจ็บปวดน้อยลง ไม่มากไม่น้อย. เรา Candied และฉันพูดแบบนี้เพราะเรา (ฉันเชื่อ) ต้องเผชิญกับสถานการณ์ที่คล้ายกันบ่อยครั้งและเราคาดว่าคุณสมบัติที่เป็นไปได้ที่ไวต่อการเปลี่ยนแปลงหรือพัฒนา ท้ายที่สุดคุณจะเข้าใกล้โครงการและโอกาสในอนาคต
Laiv

1
@Prabhu: สังเกตว่าคุณถามคำถามเกี่ยวกับแนวปฏิบัติที่ดีไม่ว่าจะเป็นแนวทางที่กระชับที่สุดสำหรับสถานการณ์เฉพาะของคุณหรือไม่ ฉันมักจะหลีกเลี่ยงงานด้านวิศวกรรมมากเกินไป แต่ค่าใช้จ่ายในการบำรุงรักษาในอนาคต (การเพิ่ม / ลบลิงค์, การอัพเดทคำจำกัดความของคลาสเอนทิตี, ... ) มีค่ามากกว่าค่าใช้จ่ายในการใช้คอลเลกชันลิงก์ ถ้าคุณเรียกว่าคอลัมน์ของคุณlink1, link2, link3ที่จำเป็นสำหรับคอลเลกชันจะได้รับที่ชัดเจนมากขึ้น อย่างไรก็ตามความจริงที่ว่าคุณให้ชื่อที่มีความหมายมากกว่านี้กับคอลัมน์ก็ไม่ได้เปลี่ยนความจริงที่ว่ามันเป็นชุดของข้อมูลซ้ำ ๆ
Flater

6

คุณกำลังจะตกสู่กับดัก "ฉันเห็นความเป็นไปได้ทางเทคนิค"

เพียงเพราะคุณเห็นลักษณะทั่วไปในหมู่รายการไม่ได้หมายความว่าเหมาะสมที่จะใช้การรวมบางอย่างกับพวกเขา การรวมตัวควรมีความหมายอะไรบางอย่าง ไม่ได้อยู่ในระดับเทคนิค แต่อยู่ในโดเมนปัญหาของคุณ

ลิงก์ทั้งหมดเป็นไร แต่ในบริบทของคลาสผู้ใช้นั่นหมายความว่าอะไร ไม่มันไม่มีความหมายเหมือนกับการจัดกลุ่มย่อยโดยใช้คลาสที่มีชื่อว่า "strings" และ "numbers"

ปัญหาของสิ่งนี้คือทำให้โมเดลของคุณพร่ามัว มันบังคับให้เครื่องอ่านรหัสตัดการสื่อความหมายออกจากความหมายก่อนที่จะเข้าใจโดเมนอย่างสมบูรณ์

ไม่มีใครพูดถึงลิงก์ของผู้ใช้ มันจะแตกต่างกันถ้าคุณจะเรียกรวม SocialNetworkIds ของคุณ เพราะนั่นจะหมายถึงบางสิ่งบางอย่างมันจะเป็นคุณสมบัติที่แท้จริงของผู้ใช้มากกว่าการรวบรวมทางเทคนิคโดยพลการ


สิ่งที่ฉันสงสัยก็คือทำให้ฉันถามคำถามนี้ ความสัมพันธ์ระหว่างลิงก์ที่แตกต่างกันเพียงอย่างเดียวคือพวกมันอาจจะปรากฏร่วมกันใน UI ดังนั้นในกรณีนี้คุณไม่แนะนำให้วางวัตถุแยกต่างหาก แต่ควรเก็บไว้ใต้วัตถุผู้ใช้โดยตรงหรือไม่
Prabhu

1
ฉันไม่คิดว่ามันจะเป็นประโยชน์ในกรณีนี้ คุณยังไม่มีปัญหาที่จะช่วยเพิ่มความซับซ้อนของเลเยอร์ หากคุณมีคุณสมบัติมากขึ้นอาจมีความพยายามในการจัดกลุ่ม (โดยใช้ชื่อ apt สำหรับกลุ่ม) เป็นการยากที่จะบอกสิ่งที่เหมาะสมโดยไม่มีบริบท บรรทัดล่างคือมันควรทำให้สิ่งต่าง ๆ ง่ายขึ้น เพื่อทำความเข้าใจและ / หรือดำเนินการตามขั้นตอนต่อไปของคุณในกระบวนการพัฒนา
Martin Maat

ฉันมักจะหลีกเลี่ยงเช่นมากกว่าวิศวกรรม แต่ฉันสงสัย: คุณจะได้กล่าวว่าสิ่งเดียวกันถ้า OP ได้ชื่อสาขาของเขาlink1, link2, link3? การออกแบบโครงสร้างข้อมูลไม่ขึ้นอยู่กับชื่อของฟิลด์ดังนั้นตัวอย่างของฉันจึงเทียบเท่ากับการใช้งานได้ มันเป็นเรื่องของการป้องกันในอนาคต โดยทั่วไปแล้วจะใช้ YAGNI แต่ถ้ามีอะไรสื่อสังคมออนไลน์ได้พิสูจน์ตัวเองไวต่อความนิยมของไวรัสและการเปลี่ยนแปลง การหลีกเลี่ยงการพัฒนาขื้นใหม่สำหรับเว็บไซต์สื่อสังคมออนไลน์ยอดนิยมทุกรายการนั้นเป็นที่ต้องการ ไม่เช่นนั้นคุณก็เสี่ยงที่จะตกอยู่ใน กับดักซึ่งสามารถสร้างหนี้มหาศาล
Flater

1

โดยทั่วไปฉันคิดว่ามันมีเหตุผลที่จะมีลิงค์เป็นของตัวเองstructหากคุณมีแนวโน้มที่จะใช้การดำเนินการที่คล้ายกันกับแต่ละรายการและโดยเฉพาะอย่างยิ่งถ้าคุณดำเนินการแบบเดียวกันกับทุกคน หากพวกเขามีวัตถุประสงค์ที่ไม่เกี่ยวข้องในใบสมัครของคุณแล้วฉันจะทำให้พวกเขาแยกจากกัน ตัวอย่างเช่นหากพวกเขาเป็นหน้าแรกของผู้ใช้เว็บไซต์ของผู้ให้บริการด้านประกันสุขภาพและลิงก์ไปยังเว็บไซต์ข่าวที่พวกเขาชื่นชอบฉันอาจจะไม่จัดกลุ่มพวกเขาเข้าด้วยกันเนื่องจากดูเหมือนว่าไม่เกี่ยวข้องกัน แต่สำหรับเว็บไซต์โซเชียลมีเดีย 3 แห่งดูเหมือนว่าพวกเขาจะได้รับการปฏิบัติคล้าย ๆ กันในแอพและน่าจะถูกจัดกลุ่มเข้าด้วยกัน ฉันจะใช้ชื่อที่มีความหมายมากกว่าLinksนี้ (ลิงค์ประเภทใดมีไว้เพื่ออะไรในแอพของคุณ?)

ฉันเห็นด้วยกับความคิดของคุณใน # 2 ดังที่ได้กล่าวไว้ข้างต้นหากจำนวนนั้นเพิ่มขึ้นหรือกลายเป็นตัวแปรรายการหรือคอลเล็กชันอื่น ๆ จะเป็นตัวเลือกที่ดี แต่ไม่ใช่สำหรับสถานการณ์ที่คุณอธิบายไว้

ฉันจะไม่วางวิธีการเชื่อมต่อเครือข่ายภายในวัตถุที่เก็บข้อมูลที่เครือข่ายดึงมา ข้อมูลมาจากไหนและทำอย่างไรจึงจะได้รับข้อมูลนั้นไม่เกี่ยวข้องกับวัตถุประสงค์หลักของชั้นเรียน ถ้าในอนาคตคุณต้องการรับข้อมูลจากดิสก์ หรือต้องการให้ผู้ใช้ป้อน ไปให้ไกลพอถนนสายนั้นและUserชั้นเรียนที่เรียบง่ายจะต้องมีรหัสเพื่อจัดการทุกวิธีที่เป็นไปได้ในการป้อนและเรียกข้อมูล เพียงแค่ให้Userชั้นเรียนและเก็บรักษาข้อมูลในขณะที่อยู่ในหน่วยความจำ ทุกสิ่งสามารถจัดการได้โดยคลาสที่เหมาะสมกว่า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.