2025-08-12-TIL
Today I Learned
2025-08-06-Mentoring-Review
과제 피드백
- 최근 chatGPT로 코딩테스트가 검증이 어려워져서 과제 전형으로 많이 채용하는 추세
- 의존성이 너무 불필요한게 많은데, 보일러 플레이트로 보일 수 있음. 의존성이 무엇을 포함하고 왜 쓰는지 명확히 할 것
- 답변을 달면서 레퍼런스를 다는 것은 좋은데, 레퍼런스를 달게되면 그 내용이 반드시 포함되어야 한다.
- MDC도 깊이 학습해볼 것
- 손자병법에 졸속행진 이라는 말이 있는데, 전쟁은 완전한 준비가 되고나서 하는게 아니라 행군하면서 전쟁 준비를 하는 것이다. 완벽한 준비는 없다. 일단 시작하는 것이 중요하고, 하면서 계속 완성해나가면 된다.
질문
캡슐화란?
구현을 숨기고, 클라이언트가 접근할 수 없도록 해야한다. 즉, 접근제어자를 통해서 내부 구현을 숨기는 것이다.
캡슐화가 있어서 코드가 클린해질 수 있다.
상속의 단점은?
강한 결합: 자식 클래스가 부모 클래스의 내부 구조와 구현에 의존하게 된다. 부모 글래스 변경 시 줄줄이 수정이 필요하다. 변경에 취약
유연성 저하: 상속 구조가 한 번 깊어지면 설계를 바꾸기 어렵다. 객체 간 관계가 고정되어서 동적으로 다른 기능을 조합하기 어렵다.
다중 상속의 복잡성: 다이아몬드 문제를 포함해서 여러 부모 클래스를 상속하면 메서드나 속성이 충돌할 수 있다.
테스트와 유지보수에 부담: 부모와 자식 간 의존이 깊으면, 단위 테스트가 어려워진다. 상속 트리 변경 시 전체 테스트를 다시 해야 보장된다.
추상화란?
객체지향에서 추상화는 현실 세계를 모델링하는 것이다.
현실 -> 모델링 -> 패턴 발견 -> 묶기/분리
면접장에서 추상화를 물어보면, 면접장의 사물을 바탕으로 직접 설계를 해보면 좋다. 이런 내용에서 시간을 많이 끌 수 있어서 면접을 무난하게 마무리할 수 있다.
대수학에서 수의 체계를 분류할 때 추상화가 도움이된다.
로컬 파일 업로드, AWS S3 파일 업로드하는 클래스가 있다고 했을 때, 이 둘을 어떻게 추상화할 수 있을까?
인터페이스 하나만 가지고 한 시간, 두 시간 이상 이야기할 수 있도록 깊이 생각해보고 고민해보기. 그리고 정리해보기
TDD의 효과
추상 클래스와 인터페이스의 차이
항목 인터페이스 (Interface) 추상 클래스 (Abstract Class) 목적 기능 명세 제공 (계약) 공통 기능 정의 (상속 기반 구현 공유) 다중 상속 가능 (여러 개 구현) 불가 (단일 상속만 허용) 메서드 추상 메서드 위주 ( default/static허용)추상 메서드 + 일반 메서드 모두 가능 필드 public static final만 가능 (상수)인스턴스 변수, 상태 보관 가능 생성자 없음 있음 접근 제어자 모든 메서드는 public메서드/필드에 접근 제어자 사용 가능 사용 예 전략, 규약, DI, 콜백 등 공통 기능 묶기, 기본 구현 제공 ISP가 인터페이스와 밀접하고, LSP가 추상 클래스와 밀접하다.
다중 상속은 다이아몬드 문제가 있다.
final을 선언하면?
final은 마지막이라는 뜻 그대로 ‘더 이상 변경을 금지한다’는 뜻이다.
필드에 붙이면 값을 변경하지 못하므로 상수화, 클래스에 붙이면 하위 클래스에서의 변경을 금지하므로 상속 불가, 메소드에 붙이면 메소드를 재작성하는 것을 막으므로 오버라이딩 불가이다.
특히 클래스에 final은 버그 발생 가능성을 줄여준다. 상속을 통해서 비정상적인 하위클래스를 밀어넣어서 해킹을 할수도 있다. 따라서 안전한 코드를 위해서 명확히 상속하지 않는 클래스는 final로 막아두는것이 좋다. 특히 외부로 배포하는 라이브러리 성격의 코드는 더욱 이 내용이 중요시된다. 예를 들어, 자바의 String 클래스도 final로 선언되어 있다.
SRP를 잘 지켰다고 말하기 위한 기준은?
응집도가 높고, 결합도가 낮게 설계하는게 SRP를 잘 지키는 방법 중 하나이다.
클래스가 담당하는 변경 이유가 하나뿐인가?
이 클래스에 영향을 미치는 이해관계자가 하나인가?
모든 메서드가 같은 목적을 위해 협력하는가?
기능 변경 시 수정 범위가 작고 한정적인가?
클래스 설명을 한 문장으로, 접속사 없이 말할 수 있는가?