인생을 코딩하다.

가변성을 제한하라. 읽고 쓸수 있는 프로퍼티 var을 사용하거나 mutable 객체를 사용하면 상태를 가질 수 있습니다. 상태를 가지면 해당 요스의 동작은 사용 방법뿐만 아니라 그 이력에도 의존하게 됩니다. 가변성이 있을 시 문제점 1. 프로그램을 이해하고 디버그하기 힘들어집니다. 이러한 상태를 갖는 부분들의 관계를 이해해야 하며, 상태 변경이 많아지면 이를 추적하는것이 힘들어집니다. 이러한 클래스는 이해하기도 어렵고, 이후에 코드를 수정하기도 힘들어집니다. 클래스가 예상하지 못한 상황 또는 오류를 발생시키는 경우에도 큰 문제가 됩니다. 2. 가변성이 있으면, 코드의 실행을 추론하기 어려워집니다. 시점에 따라서 값이 달라질 수 있으므로, 현재 어떤 값을 갖고 있는지 알아야 코드의 실행을 예측할 수 있습니..

🔍 우선, 코틀린에서 Entity Class 생성자에 매개변수를 선언할 때, id를 맨 위에 선언했을 경우로 예를 들어보겠습니다. 생성자 호출시, 네임드 파라미터를 사용하지 않았을 때 @Entity class User( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L, @Column(nullable = false) val email: String, @Column(nullable = false) val password: String, ) { fun user() = User("email@tistory.com", "password") } 위와 같은 코드는 파라미터 순서가 맞지 않기 때문에 컴파일 에러가 발생하게 됩니다. 위 문..

안녕하세요. 요즘 이펙티브 자바(Effective Java)를 읽어보고 있는데요, 읽다보니 코틀린은 이펙티브 자바가 대부분 반영이 되어있는 산물이라고 느꼈습니다. 보통 코틀린이 자바에 비해 훨씬 코드를 간결하게 작성할 수 있다는 것은 누구나 알고 있을텐데요, 구체적으로 어떤 어떤 사례들이 있는지 제가 이펙티브 자바를 읽으면서 한 번 분석하여 보았고, 직접 이펙티브 코틀린이라는 주제로 글을 작성해보고 있습니다. 그럼 Hyung1Jung의 Effective Kotlin 시작해보도록 하겠습니다. [Effective Kotlin - Item2] : 코틀린에서 빌더를 사용할 필요가 있을까? 이번 글은 이펙티브 자바 Item2를 읽어보며 이것이 코틀린라는 언어에서는 어떻게 녹여져 있을까에 관해 작성해보았습니다. 이..

@Transactional fun saveUser(userDto: UserDto) { // 이메일 중복체크 예외처리 로직 if (userRepository.existsByEmail(userDto.email)) { throw EmailDuplicateException() } ... 중간 생략 userMapper.save(user.toUserEntity()) } 위의 코드에서 saveUser메서드는 회원가입을 하는 API다. 이 메서드에는 이메일 중복검사에 관한 기능과 회원 정보를 저장하여 회원가입을 하는 기능이 있다. 또한 위에서 보이는 로직 말고도 추 후 변경이 생겨 다른 로직들이 더 추가 될 수 있다. 서비스에서 회원가입 기능의 흐름상 이메일 중복검사 기능은 어떤식으로든 들어가야 한다. 또 변경이 생겨..

1. 롬복은 왜 써야할까요 어노테이션 기반이기 때문에 코드 자동생성을 통한 생산성을 향상 시킬 수 있습니다. 그에 따라 반복되는 코드르 줄여 가독성 및 유지보수를 향상 시킬 수 있습니다. 추가로 빌더 패턴이나 로그 생성 등 다양하게 활용할 수 있습니다. 하지만 롬복에는 주의사항도 있습니다. @AllArgsConstructor,@RequiredArgsConstructor을 사용했을 떄, 필드 순서를 바꾸면 생성자의 순서도 바뀌는데, 기존 코드의 수정은 필요하지 않기 때문에, 개발자가 의도한 대로 동작하지 않아 버그가 생길 가능성이 큽니다. @Setter의 사용은 객체를 언제든지 변경할 수 있는 상태가 되어서 객체의 안전성이 보장받기 힘듭니다. @Data를 사용하면 모든 어노테이션을 한 번에 사용하기 떄문에..