kkoon9

자바에서 두 개의 오브젝트가 같은가라는 말은 주의해서 써야 합니다. 자바에서는 “같다"라는 표현에 다음과 같은 두 가지 의미가 담습니다. 동일성(identical) 두 개의 오브젝트가 완전히 같다는 의미 == 연산자 두 개의 오브젝트가 동일하다면 사실은 하나의 오브젝트만 존재하는 것이고, 두 개의 오브젝트 레퍼런스 변수를 가집니다. 동등성(equality) 두 개의 오브젝트가 같은 정보를 담고 있다는 의미 equals() 두 개의 오브젝트가 동등한 경우에는 두 개의 각기 다른 오브젝트가 메모리상에 존재합니다. 자바 클래스를 만들 때 equals() 메서드를 따로 오버라이딩하지 않았다면, 최상위 클래스인 Object 클래스에 구현되어 있는 equals() 메서드가 사용됩니다.

스프링의 핵심을 담당하는 건, 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것이다. 오브젝트 팩토리를 이용한 스프링 IoC 애플리케이션 컨텍스트와 설정정보 빈(bean) 스프링에서 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 뜻한다. 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전(IoC)이 적용된 오브젝트를 뜻한다. 빈 팩토리(bean factory) 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트 빈 팩토리보다는 더 확장한 애플리케이션 컨텍스트를 주로 사용한다. 애플리케이션 컨텍스트(application context) 별도의 정보를 참고해서 빈의 생성, 관계설정 등의 제어 작업을 총괄한다. 별도로 설정정보를 담고 있는 무엇인가를 가져와 이를 활..

자바빈(JavaBean)은 원래 비주얼 툴에서 조작 가능한 컴포넌트를 말한다. 자바의 주력 개발 플랫폼이 웹 기반의 엔터프라이즈 방식으로 바뀌면서 비주얼 컴포넌트로서 자바빈은 인기를 잃어갔다. 하지만, 자바빈의 몇 가지 코딩 관례는 JSP 빈, EJB와 같은 표준 기술과 자바빈 스타일의 오브젝트를 사용하는 오픈소스 기술을 통해 계속 이어져 왔다. 이제 자바빈은 두 가지 관례를 따라 만들어진 오브젝트를 가리킨다. [1]. 디폴트 생성자 자바빈은 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하기 때문에 필요하다. [2]. 프로퍼티 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 setter와 getter를 이용하여 수정 또는 조..

stereotype annotation들을 어떻게 찾을까? 스프링 부트가 시작되는 클래스에 붙어있는 SpringBootApplication 어노테이션을 조사해보았습니다. 여러 어노테이션이 있으나 @EnableAutoConfiguration와 @ComponentScan을 살펴보겠습니다. 1. EnableAutoConfiguration @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import(AutoConfigurationImportSelector.class) public @interface EnableAutoConfiguration { /** * Env..

stereotype annotation이 무엇일까? 전체 아키텍처에서 type 혹은 method의 역할을 나타내는 어노테이션을 뜻합니다. 종류로는 Component, Controller, Indexed, Repository, Service가 있습니다. 1. Indexed @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Indexed { } 어노테이션이 달린 요소가 index에 대한 stereotype임을 나타냅니다. CandidateComponentsIndex는 컴파일 시 생성된 메타데이터 파일을 사용하는 classpath scanning 대상입니다. index를 사용하면 stereotyp..

보다 나은 객체지향 실력을 위해 토이 프로젝트를 TDD로 개발해보려고 합니다. 토이 프로젝트에서는 다음 책이나 사이트에서 배운 것들을 무조건 혹은 최대한 반영하려고 합니다. 클린 코드 이펙티브 자바 객체지향 생활 체조 이번에 할 토이 프로젝트는 레이싱 카입니다. 요구사항은 다음과 같습니다. 주어진 경기수 동안 n대의 자동차는 전진 또는 멈출 수 있다. 사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다. 전진하는 조건은 0에서 9 사이에서 random 값을 구한 후 random 값이 4이상일 경우 전진하고, 3이하의 값이면 멈춘다. 매 경기마다 자동차들의 전진한 횟수를 “-”로 출력해야 한다. 위 요구사항을 보고 어떠한 도메인을 도출해내는 게 중요합니다. 도메인 도출 후 여러 테스트 케이스를 도..

🤔 DTO와 엔티티 중 validation을 어디에 걸어야 할까? DDD를 도입하는 초기 단계여서 그런지 위같은 질문이 계속해서 들었다. 책에서 배운 걸 떠올렸을 때에는 다음과 같다. 타입에 대한 검증은 컨트롤러 이전인 DTO에서 처리되어야 한다. 비즈니스적인 유효성 검증은 domain 엔티티에서 처리되어야 한다. 하지만 아래 나와있다시피 비즈니스 규칙을 검증하기가 여의치 않다면 도메인 엔티티 사용전에 사용해도 된다. 그래서 결론을 내린 게 입력명 길이나 필수값을 DTO에서 처리하기로 했다. 다음은 상점을 만드는 DTO 예시 코드와 같다. import lombok.Builder; import lombok.Getter; import net.logstash.logback.util.StringUtils; im..

API 설계자가 메서드 선언에 예외를 명시하는 까닭은, 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것입니다. API 설계자의 목소리를 흘려버리지 맙시다. 안타깝게도 예외를 무시하기란 아주 쉽습니다. 해당 메서드 호출을 try 문으로 감싼 후 catch 블록에서 아무 일도 하지 않으면 끝입니다. // catch 블록을 비워두면 예외가 무시된다. try { ... } catch (SomeException e) { } 예외는 문제 상황에 잘 대처하기 위해 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 없어집니다. 비유하자면 화재경보를 무시하는 수준을 넘어 아예 꺼버려, 다른 누구도 화재가 발생했음을 알지 못하게 하는 것과 같습니다. 운이 좋아 별 탈이 없으면 다행이지만 끔찍한 참사로 ..