Optional 정리, Product DataAccess 계층 내, 다양한 Product 의 속성 값을 가지고 조회할 수 있는 유스케이스를 추가한다. PR 작성, 독서

오늘 하루도 정말 정신없이 지나갔다. 요즘 하루는 해가 짧아지듯, 내 하루도 짧아지는 듯 하다. 면접 준비, 프로젝트 개선, 개인공부, 운동.. 고작 4개를 하다보면 하루가 지나있다. 

 

하지만 이 4개의 일을 모두 해내지는 못하고있다.. 열심히 한다고 하지만.. 아직 내 능력이 많이 부족하다.. 최근에는 왜 인지 자꾸만 나도모르게 멍... 하니 있기도하고.. 이럴때면 잠깐 노래를 듣거나, 운동을 가거나, 책을 보곤하는데 자꾸만 이 상황을 원인을 알고 해결하려는 것이 아니라 회피하려는듯하다. (아니 원인은 분명한데, 내가 벙쪄버린거일 수도..)

 

---

Product DataAccess 계층 내, 다양한 Product 의 속성 값을 가지고 조회할 수 있는 유스케이스를 추가한다

 

오늘은 신규 유스케이스에 대한, 영속성 계층에 대한 작업을 완료했다. 그리고 해당 작업에 대한 셀프 리뷰를 진행하면서 내가 Optional 을 잘못 사용하고 있음을 인지했다.

 

Optional 을 잘못 사용한 나

 

내가 Optional 을 사용하던 이유는 해당 API 사용 시, productEntites 가 null 일 수 있을 거라는 생각 때문이었다. 하지만, 실제로 값이 존재하지 않을 때에는, null 이 아닌 빈 리스트를 반환했다. 그리고 이는 언제나 isPresent()값이 true 였다.

 

작성했던 테스트 코드는 항상 IfPresent() 같이 true 였다.

 

DisplayName 을 보고서 테스트코드를 유추해본다면, Product 가 존재하지 않을 경우에는, Optional.empty 를 반환해야할 것이다. 하지만 나는 ifPresent 가 true 인 경우, 해당 값이 isEmpty() 의 값이 true 임을 검증했다. 

 

개발할 때는 몰랐는데, 스스로 리뷰를 진행해보면서 이거 이상한데..? 를 인지했다. 이 문제의 원인을 나는 Optional 에 대한 제대로된 공부 없이 사용 + 개발할 때 생각이 없..었다.. 라고 생각을 할 수 있을 것 같다.

 

해당 부분은 Optional 을 제거하기로 하였다. 지금이라도 잘못된 부분을 개선할 수 있어서 다행이다.. 그리고 추가적으로 Optional 에 대한 정리를 진행하였다.

---

Optional 정리

 

이번 일을 계기로, Optional 에 대한 정리를 하게되었다. 진작에 했어야했는데, 이제서야 한 내 자신에 반성한다.. Optional 말고도 정리하면 좋을 내용들이 정말 많은데, 하나하나.. 추가적으로 정리를 해두어야겠다.

 

[ Java ] Optional

 

Optional 에 대한 정리를 통해 Optional 에 대해 좀 더 이해할 수 있게되었다. 단순히 Optional.of 및 Optional.ofNullable 정도만 알았던 내게 Optional 에서 제공하는 모든 메서드는 아니지만, 그래도 기존 보다 좀 더 다양한 메서드들에 대해 알 수 있게되었다.

 

그리고 이번 기회를 통해 Optional 을 다시 생각해보게되었다. 과연 나는 제대로 사용하고 있는 것인가? 나는 의도대로 올바르게 사용하고 있는 것인가? 를 생각해보게 되는것 같다. 그리고 이에대한 생각도 포스팅을 통해 정리하면 좋을 듯하다.

 

 

---

독서: 객체지향 프로그래밍과 절차적 프로그래밍의 비교

오늘은 육각형 개발자가 아닌 다른 책(디자인패턴의 아름다움)을 독서했다. 오늘 내가 다시 생각하게 된 부분은 객체지향 프로그래밍과 절차적 프로그래밍의 대한 부분이다. 객체지향 프로그래밍을 선호 했지만, 절차적 프로그래밍을 따르는 사람이었기 때문이다.

 

---

객체지향 프로그래밍과 절차적 프로그래밍

 

객체지향 프로그래밍은 클래스와 객체를 코드구성단위로 사용하며, 절차적 프로그래밍은 함수형 프로그래밍과 같이 함수 작성과 같은 특정 구현 세부사항에 중점을 둔다.

 

책의 내용을 인용하여 좀더 간단하게 이야기를 한다면, 절차적 프로그래밍은 사람의 사고대로 프로그래밍을 하는 것으로 이야기 할 수 있고, 객체지향 프로그래밍은 자기개발의 일부분처럼 작업 전체를 생각하기보다, 하나의 작업을 클래스로 만드는 것이라고 이야기 할 수 있다.

 

간단한 프로그램을 개발하는 경우에는, 절차적 프로그래밍 스타일과 객체지향 프로그래밍 스타일 중 어느것을 사용하더라도 구현되는 코드에서 큰 차이를 발견하기 어렵다. 그래서 나는 지금 만들어보고 있는 신발주문 시스템에서 객체지향 프로그래밍을 한다 생각했지만, 절차지향적인 프로그래밍으로 하고 있음을 이번 독서를 통해 알게되었다.

 

사실 객체지향 프로그래밍을 공부하면서 객체지향 프로그래밍이라는 사례는 많이 보았지만, 반대(객체지향이 아닌 경우)는 많이 접해보지 못했고, 또 생각하지 못했다. 객체지향 프로그래밍의 특징 4가지(다형성, 캡슐화, 추상화, 상속)에 대해 공부했지만, 이를 염두한 코드 설계는 많이 하지 못했던 것 같다.

 

특히 Getter 가 객체지향 원칙의 캡슐화를 해칠 수 있다는 것은 내게 정말 새로운 내용이였다.

 

내가 설계한 Order 도메인 객체의 속성 값들의 일부분, items 는 getItems 이후 수정이 가능하다.

 

나는 다음과 같은 이유로, setter 의 사용을 지양해야한다는 것으로 알고있었다.

• 객체의 일관성을 유지하기 힘들다.(가변)

 

그런데 이 뿐만 아니라이번 책에서는 setter 메서드를 노출하는 것은 캡슐화를 명백하게 위반하는 것이라고 표현하였다. setter 메서드는 노출이 되어야하면 안되기 때문이다.

• 내부 데이터는 접근 권한 제어를 통해 숨겨져야하며, 외부에서는 제공하는 제한된 인터페이스(getter)를 통해서만 접근할 수 있어야 한다.

그리고 일반적으로 getter 는 문제가 되지않지만, 컬렉션을 반환하는 경우에는 다르다는 것을 알게되었다. 컬렉션을 반환하는 경우에는 외부에서 값을 수정할 수 있기 때문에 캡슐화에 어긋나게 되는 것이다. 나는 이 부분을 정말 전혀 알지 못했다.

 

이에 대하여 책에서는 Collections.unmodifiableList() 를 활용하여, 수정이 불가능한 UnmodifiableList 컬렉션을 반환하는 것을 추천하였다.  처음으로 들어본 것인데, 다음에는 해당 컬렉션을 활용하여, 설계할 수 있도록 해야겠다.

 

---

요즘 하루를 마무리하는 글을 정리하다보면, 하루를 정리하는 것 이상의 생각이 떠오른다. 이걸해야하고, 저걸해야하고.. 이건 언제하지..? 정리보다는 점점 더 복잡해지는 것 같기도 하다.

 

요즘 나는 포복자세로 기어가는 기분이다. 전장이라는 것은 알고 있었지만, 이렇게 포복자세로 갈 것이라고는 생각을 못했던 것 같다. 어서 포복자세를 풀고 뛰댕기고 싶다.

 

안되면 될떄까지!!