분류 전체보기

[Effective Java] item 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 클래스를 안전하게 상속할 수 있도록 하려면 (상속만 아니었다면 기술하지 않았어야 할) 내부 구현 방식을 설명해야만 한다. [상속을 고려한 설계와 문서화] : 메서드를 정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다. → 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야 한다. 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출하는데, 그 메서드가 재정의 가능 메서드인 경우 어떤 순서로 API를 호출해야 하는지 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지 넓게 말하면, 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다. ☑️..

[Effective Java] item 18. 상속보다는 컴포지션을 사용하라 *

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 다른 패키지의 구체 클래스를 상속하는 일은 위험하다. [메서드 호출과 달리 상속은 캡슐화를 깨뜨린다] : 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스가 오동작할 수 있다. ☑️ HashSet를 상속받은 클래스 InstrumentedHashSet public class InstrumentedHashSet extends HashSet { // 추가된 원소의 수 private int addCount = 0; @Override public boolean addAll(Collection

[Effective Java] item 17. 변경 가능성을 최소화하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다. ☑️ 불변 클래스 생성 규칙 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. 클래스를 확장할 수 없도록 한다. 상속을 막는 대표적인 방법 ↔ 클래스를 final로 선언하기 모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법 모든 필드를 private로 선언한다. 필드가 참조하는 가변 객체를 ..

[Effective Java] item 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 이따금 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다. 이처럼 퇴보한 클래스는 public이어서는 안 된다! [패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공해야 한다] : public 클래스에서는 필드를 모두 private으로 바꾸고 public 접근자(getter)를 추가해야 한다. ☑️ 접근자와 변경자 메서드를 활용해 데이터 캡슐화하기 class Point{ public double x; public double y; } 이런 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다. API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불..

[Effective Java] item 15. 클래스와 멤버의 접근 권한을 최소화하라

본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다. 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. [모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다] : 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다. ☑️ 톱레벨 클래스, 인터페이스에 부여할 수 있는 접근 수준 public..

[Spring/fairer] 반복 기능 api 개발 - 조회

반복 기능 구현 방법을 설계하고, 나는 조회 api를 담당했다. 반복기능 구현 전 집안일 api 에서도 조회를 담당했는데, 굉장히 비효율적으로 구현했던 전적이 있어서 이번에는 개선해 보고자 도전했는데 … fromDate ~ toDate에 속한 집안일을 조회하려면 반복 종류에 따라서 ONCE (반복x) scheduled_date가 조회 범위 안에 속하는지 확인 DAILY (매일 반복) scheduled_date ~ end_date가 조회 범위와 겹치는 구간이 있는지 확인 repeat_exception 테이블에 조회할 날짜가 등록되어 있는지 확인 WEEKLY (요일 반복) scheduled_date ~ end_date가 조회 범위와 겹치는 구간이 있는지 확인 (repeat_pattern에 저장된 요일 == ..

[Spring/fairer] 반복 기능 api 설계

반복 기능은 fairer를 개발하며 가장 신경써야할 부분이 많았던 기능이다. 일/주/월 단위로 반복되는 집안일을 관리해야하고, 수정&삭제를 할 때에도 반복 일정 모두 삭제/오늘 일정만 삭제/ 앞으로 예정된 집안일만 삭제 등 선택지가 많았다. 반복기능을 어떻게 개발할 것인지 설계하는 데에만 몇 주를 사용했던 것으로 기억한다. 4명의 의견이 모두 달랐어서 신기했고, 배울점도 많았던 기능이다. 의견1 새로운 테이블을 추가하지 않고, 기존 housework 테이블에 주기 칼럼만 추가 생성 : 기존 집안일 생성과 동일, 주기 칼럼에 주기만 추가하여 생성 조회 : 해당 날짜에 포함되는 집안일(반복x) 조회 반복되는 집안일 중 반복 요일이 같고, 시작 날짜~종료 날짜 안에 해당 날짜가 포함된 집안일 조회 수정 : 집..

[TIL/adone] 2022-08-25~26 dto 디렉토리 구조 변경, @Embeddable

1. dto 디렉토리 대규모 수정 서비스에 estimate(견적)에 관련된 기능이 가장 많은데, dto 구조가 필요 이상으로 복잡하고 가독성이 떨어진다 생각이 들었다. 합칠 수 있는 dto는 합치고, request/response 위주로 분리했다. 매우 헷갈리고.. 오래 걸렸지만 훨씬 깔끔해진 것 같아 뿌듯하다. 2. 유저가 디자인한 간판 생성 api 😇 save the transient instance before flushing : FK 로 사용되는 컬럼값이 없는 상태에서 데이터를 넣으려하면 발생하는 에러이다. → 나는 진짜로 데이터가 없어서 발생했는데, 연관 관계 매핑해줄 때 사용하는 @ManyToOne, @OneToOne, @OneToMany 어노테이션에 cascade옵션을 변경하면 해결 할 수 ..

[TIL/adone] 2022-08-23~24 API 설계, @Builder.Default, Swagger 설정

1. 보안그룹 설정, RDS 연결, 탄력적 IP 할당 RDS 보안그룹의 인바운드 규칙을 추가하여, RDS를 생성한 IP주소 외에서도 접근 가능하도록 바꿔주었다. 3306 포트의 IPv4, IPv6 규칙을 추가해주어야 한다. 탄력적 IP도 할당해주었다. 2. 기능명세 + 코드 파악 하나의 화면에서 여러개의 API를 호출하는데, 각각 다른 controller에서 호출하는 것 보다는 하나의 controller로 묶는 것이 좋아보인다. member_role은 하나의 칼럼으로 처리하는 것이 편할 것 같다. 도메인 디렉토리가 estimate → requestEstimate → SignboardInfo로 구성되어 있는데, 간판 객체는 그냥 별도의 디렉토리로 분리하는게 나을 것 같다. service 로직에서 다른 도메..

[Spring/Data JPA] 인터페이스 기능

😊 순수 JPA 기반 레포지토리 만들기 ▪ 순수 jpa 기반 레포지토리 @Repository public class MemberJpaRepository { @PersistenceContext private EntityManager em; public Member save(Member member) { em.persist(member); return member; } public void delete(Member member) { em.remove(member); } public List findAll() { return em.createQuery("select m from Member m", Member.class) .getResultList(); } public Optional findById(Long..

[Java] 백준 #1463 1로 만들기

https://www.acmicpc.net/problem/1463 1463번: 1로 만들기 첫째 줄에 1보다 크거나 같고, 106보다 작거나 같은 정수 N이 주어진다. www.acmicpc.net 정수 X에 사용할 수 있는 연산 세 가지를 적절히 사용해서 정수 N을 1로 만든다. X가 3으로 나누어 떨어지면, 3으로 나눈다. X가 2로 나누어 떨어지면, 2로 나눈다. 1을 뺀다. 연산 사용 횟수의 최솟값 구하기 💡 알고리즘 다이나믹 프로그래밍 💡 접근 RGB거리처럼 모든 케이스의 계산횟수가 동일한 문제가 아니므로, 배열만으로는 해결하기 어려울 것 같다. → 재귀함수를 작성하고, 전역변수를 통해 최솟값을 관리하자. 💡 코드 package DP; import java.io.BufferedReader; imp..

[Algorithm/Java] 다이나믹 프로그래밍 복습

DP문제 해결 과정 = 규칙을 찾아 점화식 세우기 큰 문제를 작은 문제로 나눌 수 있다. 작은 문제에서 구한 정답은 그것을 포함하는 큰 문제에서도 동일하다. 처음엔 감이 안잡히므로.. 그냥 몇문제 답을 보고 시작하는게 효율적이다. 💡 ex1. RGB거리 https://www.acmicpc.net/problem/1149 1149번: RGB거리 첫째 줄에 집의 수 N(2 ≤ N ≤ 1,000)이 주어진다. 둘째 줄부터 N개의 줄에는 각 집을 빨강, 초록, 파랑으로 칠하는 비용이 1번 집부터 한 줄에 하나씩 주어진다. 집을 칠하는 비용은 1,000보다 작거나 www.acmicpc.net 주어진 비용으로 N개의 집을 빨, 초, 파로 칠하는데 N번 집은 N-1, N+1번 집과 색이 같으면 안된다 집을 칠하는 최소..