여러 엔터티와 연결된 고객 클래스

Question

그래서 고객을 관리하는 것이 주 목적입니다. 내 문제는 고객과 관련된 모든 것을 묶는 방법을 모르겠다는 것입니다. 이 게시물을 위해 고객이 이메일을 무제한으로 가질 수 있다고 가정 해 봅시다. 내가, 내가 단순히 또 다른 목록의 구성원을 추가 할 수있는 회사의 대표에 관련된 고객을 만들 필요가 말을 이런 식으로하기 때문에이 디자인쪽으로 목표로하고 있습니다

class Customer { 
    private int id; 
    private String name; 
    private List<Email> emails = new List<Email>(); 

    public Customer(id, name) { 
    this.id = id; 
    this.name = name; 
    } 

    public addEmail(Email email) { 
    emails.Add(email); 
    } 

    public getEmails() { 
    return emails; 
    } 
} 

class Email { 
    string email; 

    public Email(email) { 
    this.email = email; 
    } 
} 

Customer newCustomer = new Customer(123, "Dummy Customer"); 
newCustomer.addEmail(new Email("dummy@abc.com")); 

: 아래는 내가 상상 한 것입니다. 또한 인터넷 검색을 시도했지만이 문제가 무엇인지 확실히 알지 못합니다.

여기에 몇 가지 내가 확실하지 오전입니다 :이 디자인은 단단한 바위 어떻게

• 입니까?
• 고객 클래스에 새 엔터티를 추가 할 때 해당 엔터티의 책임 범위가 조금 더 넓지는 않습니까?

감사합니다.

Answer 1

디자인이 좋아 보입니다.

고객이 전자 메일 주소가 여러 개인 경우 고객 클래스에 전자 메일 개체 목록이 포함되도록하는 것이 좋습니다.

유일한 문제는 여러 고객이 단일 전자 메일 주소를 공유하면 안되므로 고유성을 적용하지 않는다는 것입니다. (또는 가능할 수 있습니까? Bob, Mike, Susan 모두 전자 메일 salesteam@megaco.com을 사용할 수 있습니까?)

Answer 2

나는 ablensky에 동의합니다. 이 클래스를 어떻게 개발할 것인지, 발생한 문제에 대해 더 자세한 정보를 얻으려면보다 구체적인 정보를 얻으십시오.

FYI : 귀하가 사용하고있는 OO 기능은 그것이 도움이된다면 구성입니다.

Answer 3

귀하의 이름은 의심 스럽습니다. "전자 메일"은 실제로 전자 메일 주소입니까, 아니면 전자 메일 메시지의 텍스트입니까? 사용법에 따라 주소가 분명하기 때문에 마우스 오른쪽 버튼으로 클릭> 리팩터링> 이름 바꾸기를 원할 수 있습니다.

"이메일 추가"또는 "이메일 받기"방법을 사용하는 이유는 무엇입니까? 공개 getter 속성 만 노출하면됩니다.

다음은 어떻게 처리할까요?

class Customer 
{ 
    int id_; 
    string name_; 
    public IList<EmailAddress> EmailAddresses{get; private set;} 

    public Customer(int id, string name) 
    { 
     id_ = id; 
     name_ = name; 
     EmailAddresses = new List<EmailAddress>(); 
    } 
} 

var newCustomer = new Customer(123, "Dummy Customer"); 
newCustomer.EmailAddresses.Add(new EmailAddress("dummy@abc.com")); 

Answer 4

동의합니다. 디자인이 좋으므로 사용자가 작성한 데이터로 개체를 작성하는 데 문제가 없습니다.

주의해야 할 점은 객체에 비즈니스 로직이나 데이터 액세스 등을 포함시키지 않으려는 경우 자체를 표현하는 것 이상으로 책임을지게된다는 것입니다.

여기에 단일 책임 원칙에 모습 객체 멘토