le récit de ellie

우아한테크코스 강의 중 네오께서 해주신 "상속", "클래스와 인스턴스(심화)" 강의 중 일부를 정리하면서 추가로 학습한 내용과 나의 소소한 생각을 작성하였다. "상속보다는 컴포지션을 사용하라", "상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라", "추상 클래스보다는 인터페이스를 우선하라" 등 이펙티브 자바 3/E에는 조슈아 블로크님의 상속에 대한 부정적인 의견들이 가득하다. 상속은 정말 나쁜가? 상속은 죄가 없다!! 내가 잘 못 사용하고 있을 뿐!! 상속은 코드를 재사용하는 강력한 수단이지만 항상 최선의 선택이 되는 것은 아니다. 상속은 여러가지 단점을 가지지만, 근본적인 원인은 상속 그 자체가 아니라 상속을 잘 못 사용하고 있는 우리들이다. 상속을 잘 못 사용할 경우 큰 부작용이 ..

연료 주입 미션을 보면 예시 테스트 코드에 다음과 같이 System.getProperty()를 사용해 개행문자를 상수로 만들어 사용한다. public class RentCompanyTest { private static final String NEWLINE = System.getProperty("line.separator"); } 당시에는 "개행문자겠구나" 정도로 넘기고 "나중에 알아봐야지~"라는 생각을 했었다. (그때 그때 공부해야하는데 🥲 ) 그러다 오찌, 짱구와 코드 부검을 하는 과정에서 오찌가 "OS 마다 개행 출력 문자가 다르다. %n를 사용하는게 좋다."라는 조언을 해줬다. (땡큐 😆 ) 이렇게 이 키워드를 두번이나 듣고 나니 드디어 공부를 해야겠다는 마음이 생겼다 👍 OS에 맞춰 개행 문자를..

오늘 우아한테크코스에서 글쓰기 특강을 듣고 느낀바가 많아 글로 남겨보려한다. 워니 감사합니당 😆 글쓰는게 부담스러워.. 예전에는 정말 편하게 블로그에 글을 썼던 것 같은데 우테코에 들어와 슬랙 #학습블로그 채널에 블로그를 등록하면서부터 블로그에 글을 쓰기가 부담스러워졌다. 뭔가 틀린게 있으면 안 될 것 같고.. 자료조사도 엄청 많이해야할 것 같고.. 구성도 잘 해야할 것 같고.. 미션마다 회고도 쓰고 싶은데.. 리뷰 받은 것들 중 정리해놓고 싶은 것들도 많은데.. 점점 쓰고 싶은 아이템들은 쌓여가고 쓰다가 다 못 쓰고 포기해서 비공개로 남아버린 글들이 점점 늘어나고 있다. (그러다 보니 더 블로그에 글을 쓰는 것이 스트레스로 다가왔다 🥲) 자의식과잉 워니가 팩폭을 날려주셨따!!ㅋㅋㅋㅋㅋ 내 블로그를 보는..

본 포스팅은 이펙티브 자바 3/E의 아이템 48. 스트림 병렬화는 주의해서 적용하라를 읽고 정리한 내용이다. 아이템 45. 스트림은 주의해서 사용하라 기본적으로 스트림 파이프라인은 순차적으로 수행된다. 파이프라인을 병렬로 실행하려면 파이프라인을 구성하는 스트림 중 하나에서 parallel 메서드를 호출해주기만 하면 되나, 효과를 볼 수 있는 상황은 많지 않다. 1. 계산 결과가 정확하고 2. 성능도 좋아질 것이라는 확신이 없다면 스트림 병렬화를 적용하지 말자!! 계산량이 많거나 빅데이터를 처리하거나 성능 최적화가 필요한 상황에서 스트림 병렬화는 매력적이게 보일 수 있다. 모든 동시성 프로그래밍에서는 안전성(safety)과 응답 가능(liveness)상태를 유지해야 하는데, 스트림을 잘못 병렬화하면 오히려..

네오의 Generic 수업을 들으며 "아.. 제네릭 공부해야겠다.."라고 생각했지만.. 계속 미루고만 있었다. 그러다 로또 미션 학습 로그 말하기 때 어썸오가 "Type Erasure"를 주제로 얘기 하는 걸 들으면서 "아 맞다 얼른 제네릭 공부해야지.."라고 생각했다. 드디어 오늘 이펙티브 자바 스터디에서 제네릭에 관한 아이템들을 발표하는 것을 들으며 "오늘 안에는 제네릭 공부 시작한다!!"가 되었고, 이렇게 글을 작성하게 되었다. 난 좀 맞아야할 것 같다 👊 사실 제네릭이 뭔지는 알고 있었다. 대학교에서 자바 수업을 들을 적 당연히 배웠고, 과제도 하고, 시험도 봤다. 하지만 정작 이게 뭔지 이해를 한 적도, 내 코드에 어떻게 적용되고 있는 지에 대한 고민을 한 적도 없었다. 일단 제네릭의 기본 개념..

로또 미션 2단계 코드 리뷰에서 다음과 같은 리뷰를 받았다. 처음에는 진짜 띠용?? 이었다. 😨 이걸 어떻게 검색해봐야하지..? 하는 고민이 들었었다. 그러다 크루들과 로또 미션 코드 회고를 할 기회가 생겼는데, 당시 이에 대해 아는 크루가 있는지 물어봤었다. 감사하게도 로마가 @ParameterizedTest에도 name 인자를 지정해 넘겨줄 수 있다는 것을 알려줬다!! 👍 회고를 통해 알게 된 것도 많고, 공부할 것들도 늘어나고, 아직 진짜 모르는게 많다는 생각도 들고.. 좋다.. 😹 JUnit5 User Guide를 확인해보니 "2.15.6. Customizing Display Names"라는 소주제로 해당 내용을 다루고 있었다. 왜 JUnit5 문서를 찾아볼 생각은 안 하고 검색부터 할려고 했을까..

[개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴] 7-1. 전략(Strategy) 패턴 로또 미션 1단계 코드 리뷰에서 나는 다음과 같은 리뷰를 받았다. 당시 자동차 경주 미션에서는 인터페이스를 사용하지 않았어서.. 어떻게 해야하는거지?? 🤔 하는 당혹스러움이 있었다. 테코블에 "인터페이스를 분리하여 테스트하기 좋은 메서드로 만들기"라는 주제의 글이 있었고 많은 도움을 받았다. 해당 글에는 자동차 경주 미션을 예시로 보여줬기에 "아 이런 방식을 로또 미션에 적용해보면 되겠다"라는 생각으로 적용을 해봤었다. LottoGenerator 랜덤 로또 생성을 테스트하기 어렵기 때문에 랜덤이 아니라 고정된 로또를 생성하는 기능이 필요하다고 생각했다. 둘 모두 "로또를 생성"한다는 점에서 같으므로 일단 Lot..

[이펙티브 자바 3/E] 아이템 21 : 인터페이스는 구현하는 쪽을 생각해 설계하라 Java8 이전에는 기존 구현체를 깨뜨리지 않고는 인터페이스에 메서드를 추가할 수 있는 방법이 없었다. Java7까지만 해도 "현재 인터페이스에 새로운 메서드가 추가될 일은 영원히 없다"고 가정하고 작성됐다고 하니 말 다했다. 만약 요구사항이 추가되면서 인터페이스에 메서드를 추가해야하는 상황이 온다면, 해당 인터페이스의 구현체 클래스를 모두 변경해야줘야한다. 이게 작은 프로그램이라면 문제가 없겠지만 해당 인터페이스를 상속 받은 클래스가 무수히 많다면.... 변경 사항이 걷잡을 수 없이 많아질 것이다. 이러한 문제를 해결하기 위해 Java8 부터는 기존 인터페이스에 메서드를 추가할 수 있는 "디폴트 메서드"가 추가되었다. ..

[이펙티브 자바 3/E] 아이템 1 : 생성자 대신 정적 팩터리 메서드를 고려하라 핵심 정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다. 그렇다고 하더라도 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자. 정적 팩토리 메서드(Static Factory Method) 정적 팩토리 메서드란 그 클래스의 인스턴스를 반환하는 단순한 정적 메서드를 말한다. (new 없이 객체를 생성한다) 우리가 평소 습관적으로 public 생성자로 객체를 생성했다면 이제는 정적 팩토리 메서드를 이용해 객체 생성를 할 수 있다는 것을 알아야한다. // public 생성자 이용 Car car = new C..

이전에 우테코 크루들과 “final이 보장하는 불변은 어디까지인지?”에 대해 얘기를 나누었을 때, 어떤 크루가 본인은 컬렉션의 불변을 보장해야할 때는 unmodifiable 상태로 명시한다는 이야기를 했었다. "unmodifiable" 사실 Java 인생에서 처음 들어보는 단어였다. 그래서 그런지 뭔가 머릿속에서 휘발되고 말았는데.. "일급 컬렉션(First Class Collection)"에 대해 학습을 하다보니 다시 "객체의 불변"에 대한 내용이 나왔고, 불변과 관련해서 컬렉션에서는 unmodifiable이라는 상태를 지원한다는 것을 알게되었다. Unmodifiable Collection Unmodifiable Collection은 수정할 수 없는 컬렉션임을 뜻하며, "Read-Only" 용도로만 사..