Java boolean, Boolean Getter/Setter 차이 feat. IntelliJ

이미지
자바에선 원시 타입(primitive type)인 boolean과 클래스 타입 Boolean의 Getter를 생성할 때 규칙이 다릅니다. 자바의 프로퍼티 접근자(Getter/Setter)는  JavaBeans 스펙 에 그 내용이 기술되어 있는데 그 내용은 접근자를 만들 때 PropertyName앞에 get과 set을 붙인다는 내용입니다. 다만 boolean 타입에 대해선 별도로 명시 하고 있는데 그 내용은 다음과 같습니다. 간단히 설명하면 원시 타입 boolean의 경우 다음과 같이 is를 붙이는 형태로 작성할 수 있습니다. public boolean is<PropertyName>(); 물론 다른 타입에 사용하는 get 을 붙여 만드는 것도 가능하고 둘 다 사용할 수 있습니다. public boolean is<PropertyName>(); public boolean get<PropertyName>(); IntelliJ에서 원시 타입 boolean Getter/Setter 생성을 하면 아래와 같이 만들어 줍니다. public class PrimitiveBooleanClass { private boolean primitiveBoolean; public boolean isPrimitiveBoolean() { return primitiveBoolean; } public void setPrimitiveBoolean(boolean primitiveBoolean) { this.primitiveBoolean = primitiveBoolean; } } 그럼 클래스 타입 Boolean은 어떨까요? 이미 예상한 사람도 있겠지만 Boolean 클래스는 엄밀한 의미의 boolean이 아닙니다! 😧  자바의 특성상 클래스 타입 변수에 null 값을 할당할 수 있는데 이로 인해 Boolean 타입은 이름 값을 하지 못하고 true/false...

[깊게 이해하기] 객체지향 생활 체조 - 규칙 8: 일급 콜렉션 사용

이미지
이 주제에 대해 이미 많은 블로그 글이 있다는 것을 알고 있습니다. 그럼에도 불구하고 <소트웍스 앤솔러지> 책을 읽으며 생기는 의문이 있었고 그 의문에 대한 나름의 이해를 기록해 보려 합니다. 1. 일급 콜렉션 이란 용어는 어디서 온 것인가? 일급 콜렉션을 찾아보면 한글로 된 결과만 많이 보이고 그 말을 누가 처음 사용했는지 찾기가 어려웠습니다. 책의 원문엔 "Rule 8: Use First-Class Collections" 로 되어 있습니다. 하지만 그 어디에도 이 용어에 대한 정의가 없습니다. coderanch - What is a "first class collection"? 10년 전에 포스팅된 질문 글에서도 이와 같은 의문이 있었다는 것을 알 수 있습니다. 답변을 요약하면 "저자가 고안한 용어인것 같다." 입니다 제 생각 또한 같습니다. 이 용어는 저자가 고안한 용어라고 생각합니다. First-class citizen 이라는 용어는 프로그래밍 언어에서 다음과 같은 Operation이 가능한 entity를 의미합니다. 인자로 전달 함수에서 반환 변수에 대입 자바에서도 사용하는 용어인 First-class function 은 함수에 대해 위에서 말한 Operation이 가능하다는 것을 의미합니다. 그럼 First-class collection 은 어떻게 이해할 수 있을까요? 자바에 한정해서 보자면 (저자는 예제 코드로 자바를 사용합니다.) Collection 타입은 이미 First Class Citizen입니다. 위에서 언급한 모든 Operation을 수행할 수 있습니다. 2. 저자는 왜 콜렉션을 원시 타입이라고 하는가? 책에서 저자는 다음과 같은 언급을 합니다. "콜렉션은 실로 매우 유용한 원시 타입니다"  하지만 자바 언어 관점에서 콜렉션은 원시 타입이 아닙니다. 자바의 원시 타입은 byte, short, int, long, float, double, char 그리고...

개발 질문에 대해 "잘" 대답해주는 방법

이미지
비슷한 질문에 대해 대답할 일이 많아진다. 질문 답변 난이도는 질문자의 현재 지식 주준에 따라 달라진다. 답변 시간을 줄이면서 답변의 질을 높이기 위해선 자주 발생하는 질문에 대한 정리가 필요하다. 회사에서 후임의 질문에 대답하는 것은 쉽지 않은 일이다. 구글링 해보면 나오는 질문이라서거나, 질문이 잘못되었다거나 또는 너무 당연한 질문을 해서가 아니다. 질문자의 질문이 명확하더라도, 내가 그 질문의 대답을 알고 있더라도 때론 설명하기 어려운 경우가 있다. Source 리처드 파인만은 위 영상에서 상대방의 질문이 적절하고 좋은 질문이라고 말 한다. 그럼에도 불구하고 해당 질문에 대답하기 어려운 이유를 설명한다. 좋은 질문일 지라도 질문자의 현재 상태 (과거의 경험, 지식 수준) 를 알 수 없기 때문에 대답하기가 쉽지 않다고 말한다. 이와 비슷하게 질문을 받으면 나 나름대로 상대의 상태에 대해 생각을 한다. 내가 설명에 사용할 용어에 대해 이해하고 있을까? 내가 사용할 비유를 이해할 수 있을까? 하는 것들이다. 이 과정에서 질문자와 답변자가 뒤바뀌어 이번엔 제가 질문을 하게 되고 질문은 또 다른 질문을 만들게 된다. 그러다 보면 한 가지 질문에 대답하는데 30분이 훌쩍 넘어가는 경우가 부지기수다. 답변의 퀄리티 또한 문제다. 내가 잘 아는 것에 대해선 시간이 걸리더라도 어떻게든 적절한 답변을 할 수 있겠지만. 배경지식이 방대하고 다양한 예를 보여줘야 하는 경우엔 즉흥적인 설명에 한계가 존재한다. 최근에 "콘크리트 클래스에 사용을 지양하고 인터페이스를 이용하면 의존성이 심플해지고 테스트 코드를 작성하기 쉬워진다." 를 이해시키기 위해 SOLID의 I (인터페이스 분리 원칙) 에 대한 설명과 라이브 코딩을 했는데 중간중간 버벅이는 부분이 있었다. 요즘 이런 질문에 대답해야 하는 경우가 늘어나...