# 5. 단위 인터페이스를 작게하라

## 가이드라인

* 단위당 **파라미터 개수는 4개 이하**로 제한, 적을수록 좋기는하지만 **적절성**은 항상 고려
* **파라미터를 객체로 추출**한다
* **파라미터 개수가 줄면 단위를 이해하고 재사용하기 쉬워**져서 유지보수하기 좋아진다.

> 함께 돌아다니는 **데이터 뭉치는 자기객체**로 빼내야한다.
>
> -마틴 파울러

단위의 파라미터 개가 많아질 수 밖에 없는 상황은.. 흔히.. 자주 발생

유지보수 좋게 만드려면.. 파라미터 개수 제한하여 목록(단위 인터페이스)이 길어지지 않도록 조절해야 한다.

### 1. 필요성

* 작은 인터페이스가 **이해하고 재사용**하기 쉽다.
  * **EmployeeDao.save(User user) vs EmployeeDao.save(name, age,...)**
* 인터페이스가 작아야 **메서드를 수정**하기 쉽다.
  * 크기는 단위크기 및 복잡도와 연관
  * 일단 **`분할`** -> 각자 **책임이 분명하게 드러나짐**

**결론은 적절하고, 작게 구성하라!!**

**2. 적용가이드**

* 얼마나 작게?
  * **최대 4개가 적당, 그 이상은 가독성에서 비효율**
  * 인터페이스(객체) 크기는 본질적 문제보다는 유지보수성을 결정하는 요소. -> 크고 분석이 어려울수록 코드의 악취
  * 진짜 문제 -> 부실하고 불명확한 데이터 모델, 임시방편용 자료구조 등
* 파라미터 **객체를 활용하여 전달**
* 객체에 필드 수가 증가하고, 그 필드의 수의 적당선에서 또 다른 클래스로 분리가 필요할 수 있음 

```java
public void buildAndSendMail(MailMan m, String firstName, String lastName, String division, String subject,
                               MailFont font, String message1, String message2, String message3) {
    // 여러가지 일을 한다!
  }
  
  public void buildAndSendMail(MailMan m, MailAddress mailAddress, MailBody mailBody) {
    Mail mail = new Mail(mailAddress, mailBody);
    m.sendMail(mail);
  }
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ssosso.gitbook.io/study/dev-build-up/undefined/5..md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.