관련 속성 집합을 자체 구조체 / 클래스로 래핑하는 것이 좋습니다.


10

내 질문은 강력한 형식의 언어와 관련이 있지만 Swift에서 User 객체를 작성합니다. 사용자는 많은 링크 (FacebookProfile, InstagramProfile 등)를 가질 수 있습니다. 이것에 관한 몇 가지 질문.

  1. 링크를 자체 객체로 감싸는 것이 좋습니다?
    struct 사용자 {
       var firstName : 문자열
       var lastName : 문자열
       var 이메일 : 문자열
       var 링크 : 링크
    }
    구조체 링크 {
       var 페이스 북 : 문자열
       var 인스 타 그램 : string
       var 트위터 : 문자열 
    }

아니면 느슨해 져야합니까? 나는 기술적으로 두 가지 방법이 모두 훌륭하다는 것을 알고 있지만 일반적으로 특히 가독성을 위해 권장되는 접근법이 있는지 궁금합니다.

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와 같이 User 객체 내에 네트워킹 방법을 배치하는 것이 좋은 방법입니까?

나는 이것이 주관적 일 수 있다는 것을 알고 있지만 비슷한 상황에 대한 모범 사례가 무엇인지 이해하려고 노력하고 있습니다. 모든 조언을 부탁드립니다.

답변:


30

당신은 필요합니다

  • 물건의 제로
  • 하나의, 또는
  • 사물의 임의의 수

디자인에 필요한 링크 수가 항상 3 개가 될 것으로 예상하고 그 이름이 영원히 무엇인지 알고 있습니다.

내가 설교하는 것을 0의 무한대 규칙 이라고합니다 . 처음에는 분명하지 않지만 디자인이 미래에 관대하지 않다는 것을 알려줍니다.

이 링크에 특별한 링크가 있으면 다르게 느낍니다. 트위터 링크에 대해하지 않은 페이스 북 링크에 액세스 할 때 다르게하는 특별한 일. 그것은 그것들을 다른 것들로 만들 것입니다. 그러나이 코드에는 표시되지 않습니다.

그래서 이메일 문자열에 신경 쓰지 않습니다. 나는 그것이 링크와 다른 방식으로 사용된다는 것을 안다.

따라서이 링크를 다르게 사용하는 이유를 알 때까지 나는 링크 모음의 측면에 있습니다.


4
FacebookProfile, InstagramProfile, ...OP가 이미 질문에 대답했다고 생각합니다. 이 언어는 사용자가 소셜 네트워크와 관련된 프로필이 없거나 여러 개일 수 있음을 알려줍니다. 그러나 그 안의 프로그래머는이 요소를 단순한 링크로 바꿨습니다. 왜 컬렉션이 Profiles아닌가? CandiedOrange에 동의했습니다. 당신은 미래에 대해 너무 많이 가정하고 있습니다. 새로운 소셜 네트워크가 나타날 수 있습니다. 실제 것들이 사라질 수 있습니다. 사용자는 한 네트워크에서 다른 네트워크로 이동할 수 있습니다.
Laiv

이것은 추측입니다. 소셜 로그인에이 프로파일을 사용하려고한다고 가정하십시오. 컴포넌트 프로파일을 가지고 시작해야합니다. 이러한 프로파일을 사용하여 인증 및 현재 세션에 관한 정보를 캡슐화 할 위치 이것은 YAGNI 또는 과도한 엔지니어링으로 간주 될 수 있지만 그것에 대해 생각할 가치가 없습니다. 이러한 기능이 요청 될 수 있는지 또는 우리 애플리케이션에 가치를 제공 할 수 있는지 확인하십시오. 그렇지 않다면 그냥 버립니다.
Laiv

1
@Prabhu는 당신이 그것을 제한하는 이유에 달려 있습니다. 내 추측은 GUI에 너무 많이 적합합니다. 어느 것이 좋습니다. 그러나 GUI 때문에 데이터 구조를 제한하지 마십시오. 변덕스러운 GUI. 데이터 구조는 변경 비용이 많이 듭니다. 처음부터 제대로 해내려면 비용을 지불해야합니다.
candied_orange

2
그게 요점입니다. 미래의 변화를 덜 고통스럽게 만드는 구조를 채택하십시오. 그 이상도 이하도 아닌. 우리, Candied와 나는 우리가 (나는 믿기 때문에) 비슷한 상황에 자주 직면하고 있으며 변화하거나 진화하기 쉬운 가능한 기능을 예상하기 때문에 이것을 말한다. 궁극적으로, 당신은 프로젝트와 미래 전망에 더 가깝습니다.
Laiv

1
@Prabhu : 특정 시나리오에 대한 가장 간결한 접근 방식이 아닌 모범 사례 에 대해 질문 했습니다. 나는 일반적으로 과도한 엔지니어링을 피하는 편이지만 향후 유지 관리 비용 (링크 추가 / 제거, 엔터티 클래스 정의 업데이트 등)은 링크 모음 구현 비용보다 훨씬 큽니다. 당신이 당신의 열라고하면 link1, link2, link3, 모음의 필요성이 더 분명했을 것이다. 그러나 열에 더 의미있는 이름을 부여했다고해서 반복되는 데이터의 수집이라는 사실은 바뀌지 않습니다.
Flater

6

"기술적 인 가능성이 있습니다"함정에 빠지기 직전입니다.

항목간에 공통된 특성이 있다고해서 해당 항목에 집계를 적용하는 것이 의미가있는 것은 아닙니다. 집계는 무언가를 의미해야합니다. 기술 수준이 아니라 문제 영역에 있습니다.

그것들은 모두 링크는 ​​괜찮지 만 사용자 클래스의 맥락에서 그것은 무엇을 의미합니까? 아니요. "strings"및 "numbers"라는 클래스를 사용하여 하위 그룹을 만드는 것만 큼 의미가 없습니다.

이런 종류의 문제는 모델을 흐리게 만드는 것입니다. 그것은 도메인을 완전히 이해하기 전에 코드 리더가 무의미한 의미를 끊도록 강요합니다.

아무도 사용자의 링크에 대해 이야기하지 않습니다. 집계 SocialNetworkIds를 호출하면 다를 수 있습니다. 이는 실제로 무언가를 의미하기 때문에 임의의 기술적 수집이 아닌 사용자의 진정한 재산이됩니다.


정확히 내가 의심 한 것은이 질문을하게했다. 다른 링크들 간의 유일한 관계는 그것들이 UI에 함께 표시 될 수 있다는 것입니다. 따라서이 경우 별도의 객체에 넣지 말고 User 객체 바로 아래에 두는 것이 좋습니다.
Prabhu

1
나는이 경우에 도움이 될 것이라고 생각하지 않습니다. 복잡성 계층 추가를 정당화하는 문제는 아직 없습니다. 훨씬 더 많은 속성을 가지고 있다면 그룹화 노력 (그룹의 적절한 이름으로)이 향상되었을 수 있습니다. 상황이 없으면 무엇이 적절한 지 말하기는 어렵습니다. 결론은 일을 더 쉽게 만드는 것입니다. 개발 프로세스의 다음 단계가 무엇인지 이해하고 진행합니다.
Martin Maat

일반적으로 오버 엔지니어링을 피하는 등의 I,하지만 난 궁금해 할 : 당신은 영업 이익은 자신의 필드 이름했다면 같은 일을 말한 것 link1, link2, link3? 데이터 구조의 디자인은 필드 이름과 무관하므로 예제는 기능적으로 동일합니다. 미래 보장의 문제입니다. YAGNI는 일반적으로 적용되지만 소셜 미디어 는 바이러스 인기와 변화에 취약한 것으로 판명되었습니다. 모든 새로운 인기있는 소셜 미디어 사이트에 대한 재개발을 피하는 것이 바람직합니다. 그렇지 않으면 "하나 이상의 필드가 무엇입니까?"에 빠질 위험이 있습니다. 큰 부채를 만들 수있는 함정.
Flater

1

일반적으로 각 링크에 struct유사한 작업을 적용 할 가능성이 높고 특히 모든 링크에서 항상 동일한 작업을 수행하는 경우 링크를 자체적으로 유지하는 것이 합리적이라고 생각 합니다. 응용 프로그램에서 관련이없는 목적이라면 분리하여 사용하십시오. 예를 들어 사용자의 홈페이지, 건강 보험 제공 업체의 웹 사이트 및 선호하는 뉴스 사이트 링크 인 경우 관련이없는 것처럼 그룹화하지 않을 것입니다. 그러나 3 개의 소셜 미디어 사이트의 경우 앱에서 비슷하게 취급되는 것처럼 보이므로 그룹화해야합니다. 그래도 더 설명적인 이름을 사용합니다 Links. (어떤 유형의 링크? 앱에서 어떤 목적으로 사용 하시겠습니까?)

# 2에 대한 귀하의 생각에 동의합니다. 위에서 언급했듯이 숫자가 커지거나 가변적이라면 목록이나 다른 모음이 좋은 선택이지만 설명 한 시나리오에서는 그렇지 않습니다.

네트워크에서 검색 한 데이터를 보유하는 개체 내에 네트워킹 방법을 배치하지 않습니다. 데이터의 출처와 데이터를 얻는 방법은 일반적으로 수업의 주요 목적과 관련이 없습니다. 나중에 디스크에서 일부 데이터를 얻으려면 어떻게해야합니까? 아니면 사용자가 입력하길 원하십니까? 그 길을 충분히 내려 가면 간단한 User클래스에는 가능한 모든 데이터 입력 및 검색 방법을 처리하는 코드가 있어야합니다. 그냥 만들 User클래스 보류하고 메모리에있는 동안 데이터를 유지합니다. 다른 모든 것은 더 적절한 클래스로 처리 할 수 ​​있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.