Java에서 Kotlin으로

5장. 콩에서 가치로

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

많은 Java 프로젝트가 데이터를 표현하기 위해 변경 가능한 JavaBeans 또는 POJO(plain old Java object) 규칙에 정착했습니다. 하지만 변경 가능성은 복잡한 문제를 야기합니다. 변경 불가능한 값이 더 나은 선택인 이유는 무엇이며 코드베이스에서 변경 가능성에 따른 비용을 어떻게 줄일 수 있을까요?

콩

"빈 스타일"에서 설명한 것처럼( ), 자바빈은 Visual Basic 스타일의 드래그 앤 드롭 GUI 빌더를 개발하기 위해 도입되었습니다. 개발자는 버튼을 양식에 끌어다 놓고 제목과 아이콘을 변경한 다음 온클릭 핸들러를 연결할 수 있습니다. 그 뒤에서 GUI 빌더는 버튼 객체를 인스턴스화하는 코드를 작성한 다음 개발자가 변경한 속성에 대한 세터를 호출할 수 있습니다.

JavaBean을 정의하려면 클래스에 기본(인수가 없는) 생성자, 프로퍼티에 대한 게터, 변경 가능한 프로퍼티에 대한 설정자가 필요합니다. ( Serializable 요구 사항은 Sun조차도 이를 심각하게 생각하지 않았으므로 생략하겠습니다.) 이는 많은 속성을 가진 객체에 적합합니다. GUI 컴포넌트에는 일반적으로 전경색과 배경색, 글꼴, 레이블, 테두리, 크기, 정렬, 패딩 등이 있습니다. 이러한 속성의 기본값은 대부분 괜찮으므로 특수 값에 대해서만 세터를 호출하면 생성할 코드의 양이 최소화됩니다. 오늘날에도 변경 가능한 구성 요소 모델은 GUI 툴킷에 적합한 견고한 선택지입니다.

하지만 JavaBeans가 도입되었을 당시에는 UI 컴포넌트뿐만 아니라 대부분의 객체가 가변적이라고 생각했습니다. 왜 안 될까요? 객체의 핵심은 속성을 캡슐화하고 속성 간의 관계를 관리하는 것이었습니다. 구성 요소의 바운드가 변경될 때 너비를 업데이트하거나 항목이 추가될 때 장바구니의 총계를 업데이트하는 등의 문제를 해결하기 위해 설계되었습니다. 객체는 변경 가능한 상태를 관리하는 문제에 대한 해결책이었습니다. 당시 Java는 변경 불가능한 String 클래스를 만드는 데 상당히 급진적이었습니다(물론 어쩔 수 없이 변경 가능한 Date 클래스를 만들기는 했지만요).

직업인으로서 우리는 요즘 객체를 사용하여 값, 엔티티, 서비스, 작업, 트랜잭션 등 다양한 유형의 사물을 표현할 수 있다는 점을 잘 알고 있습니다. 하지만 Java 객체의 기본 패턴은 여전히 속성에 대한 게터와 세터가 있는 변경 가능한 객체인 JavaBean입니다. UI 툴킷에는 적합할 수 있지만 이는 좋은 기본 패턴이 아닙니다. 객체로 표현하려는 대부분의 사물에 대해서는 값이 더 좋습니다.

값

값은 영어에서 많이 오버로드된 용어입니다. 컴퓨팅에서 변수, 매개변수, 필드에는 값, 즉 바인딩된 프리미티브 또는 참조가 있다고 말합니다. 이 책에서 값을 언급할 때는 특정 유형의 프리미티브 또는 참조, 즉 값 의미를 가진 것을 의미합니다. 객체는 상호 작용에서 ...