금요일에 중간 발표를 했다,,
토요일에 기술면접 질문을 받았다,,
- Post 엔티티에서 PostLike와 PostTag가 하나는 HashSet, 하나는 LinkedHashSet인 이유가 있는지?
- Post 작성 시 동일한 emotion과 동일한 music을 골라 2명 이상이 동시에 Post를 작성했을 때 발생 할 수 있는 이슈와 이를 해결할 수 있는 방법은?
- Post 작성 시 post content(또는 cover) 길이를 db column 사이즈 이상으로 작성했을 때 발생할 수 있는 이슈와 이를 해결할 수 있는 방법은?
- controller에서 service 구현 클래스를 바로 주입받는 것이 아닌 service interface를 생성하여 contoller에서는 interface를 주입받고 service interface 구현체를 활용하는 구조가 갖는 이점이 뭐가 있을지?
작성한 사람이 달라서 다르게 사용했는데 우선 PostTag에 내가 LinkedHashSet을 사용했는데 단지 배울 때 중복 제거를 해주고 순서도 보장해준다~ 해서 사용했었다,,
이렇게 질문이 들어오니 민망하기도 하고 무슨 차이인지 알아야 할 거 같아서 자세히 찾아봤다.
- Set : 데이터의 중복된 값이 없는 자료구조, 저장된 객체를 인덱스로 관리하지 않아 저장 순서가 보장되지 않음
- HashSet
- 순서를 보장하지 않음, 셋 중 가장 빠른 성능을 보임
- equals()나 hashCode()를 오버라이딩 해서 인스턴스가 달라도 동일 객체를 구분해 중복 저장을 막을 수 있음
- LinkedHashSet
- HashSet 클래스를 상속받음
- 데이터에 삽입된 순서대로 데이터를 관리함
- TreeSet
- 오름차순으로 자동 정렬을 해줌
- 이진탐색트리의 형태로 데이터를 저장
- 데이터 추가, 삭제에는 시간이 걸리지만 검색과 정렬이 더 뛰어남
이건 어떤 이슈가 나타날지 조차 잘 모르겠다.. 우선 짐작가는 건 동시성 이슈인데,, 이게 맞나..?ㅜㅜ
지금 MySQL에 varchar(255)로 지정해놨음
- strict SQL mode가 활성화 기준
- 활성화 X : 값을 잘라서 보관하고 경고를 발생시킨다.
- 활성화 O : 공백이 아닌 문자열을 자를 때 경고 대신 에러를 발생시키고 값을 추가하지 못하도록 할 수 있음
- varchar일 경우 해당 열의 길이를 초과하는 공백들은 모드 관계 없이 잘린 후 저장되며 경고를 발생시킴
- 해결방법
- 문자열의 길이, length() > 300 을 해서 예외처리 하기
- 바이트 길이 변수.getBytes().length
이건 우리 조가 잘못 사용하고 있었던 거 같음..
- service-serviceImpl
- 인터페이스와 구현체를 분리함으로써 구현체를 독립적으로 확장할 수 있으며 구현체 클래스를 변경하거나 확장해도 이를 사용하는 클라이언트의 코드에 영향을 주지 않음
- class간의 느슨한 결합을 위해(OOP 관점에서 봤을때 인터페이스는 다형성(Polymorphism) 혹은 개방 폐쇄 원칙 때문에 사용)
- 하나의 service가 여러 구현체를 관리하거나 제어의 역전이 필요한 경우를 제외하고는 인터페이스를 무조건 써야 할 필요가 없음
- 느슨한 결합을 유지하여 각 기능 간 의존관계를 최소화 가능
- 의존관계 최소화로 인해 기능의 변화에도 최소한의 수정으로 개발할 수 있는 유연함을 가질 수 있음.
- 모듈화를 통해 어디서든 사용할 수 있도록 하여 재사용성을 높임
내가 찾아본 것은 이정도인데 내일 오전에 팀원들끼리 얘기 나누면서 맞는지, 틀린 부분이 있다면 수정해야겠다!
다른 조들의 기술면접 질문도 나중에 정리해보면 좋을 듯!
나에게 해당하는 부분들? 은 따로 정리해봐야겠다~