분류 전체보기

JPA를 공부하다가 1:1 관계에서는 FetchType.LAZY 를 사용해도 지연 로딩이 되지 않고 바로 객체를 불러온다고 한다. 책에 있는 내용을 통해 해당 링크를 찾아봤지만 어떠한 원리로 일어나고 해결방법은 어떤 것이 있는지 알고 있어야 실무에 실제로 사용할 때 주의할 수 있을 것 같다. 발생 원인 class A { private Set bees; public Set getBees() { return bees; } public void setBees(Set bees) { this.bees = bees; } } class B { // Not important really } 보통 하이버네이트에서 프록시객체를 생성할 때 위와 같은 클래스 구조가 있고 하이버네이트가 Class A를 호출하게 되면 일단 초기..

결합도가 낮은 설계는 서로 의존하는 정도가 낮으면 결합도가 낮다고 한다. 하지만 이러한 추상적인 의미는 실무하는데 있어서 크게 메리트가 없는 내용이다. 내가 결합도가 높은 코드를 짰을 때에도 이러한 조건에 충족이 되기 때문이다. 아래의 예제를 보면 public class RevervationServiceImpl implements RevervationService{ public Receipt reservation(List tickets) { for (Ticket ticket : tickets) { if(ticket.getMovieType == MovieType.WEEKEND) { } else if(movieType == MovieType.WEEKDAY) { ``` } else { ``` } } } } 이..

객체지향 설계를 접하다보면 흔히들 하는 이야기가 결합도가 낮고 응집성이 높고 캡슐화가 잘되어 있어야 한다고 한다 하지만 이런 전통적인 관점에서 응집도, 결합도, 캡슐화와 실무적인 응집도, 결합도, 캡슐화는 매우 다르다고 한다. 전통적인 관점 응집도 모듈 내부 요소들이 서로 관련이 있는 정도 모듈 내부의 기능적인 집중도 응집도가 높거나 낮다로 표현하며 좋은 설계는 응집도가 높다 결합도 한 모듈이 다른 모듈에 의존하는 정도 한 모듈이 다른 모듈에 대해 알고 있는 지식의 양 결합도가 강하다/느슨하다고 표현하며 좋은 설계는 결합도가 느슨하다. 캡슐화 상태와 행동을 함께 모음 데이터를 감추고 공용 메서드를 외부의 공개 이러한 전통적인 관점에서 응집도, 결합도, 캡슐화는 설계하는데 있어서 도움이 되긴 어렵다. 코드..

오브젝트 세미나 참여 이유? 요즘 클린 코드책과 소프트웨어 장인을 읽으면서 비록 개발팀 규모는 작지만 우리도 이러한 좋은 품질의 코드를 추구하고 변경되기 전보다 변경된 후가 더 깔끔해진 코드를 보고 작은 성공을 경험하고 성장한다는 것을 전파하고 싶었다. 그렇기에 내가 먼저 바뀌어야 했고 어제보다 더 발전해야했다. 그러다 우연히 개발자 커뮤니티에서 객체지향의 사실과 오해, 오브젝트를 집필하신 조영호 개발자님이 디어코퍼레이션에서 세미나를 여신다는 것을 보게 되었고 참여하게 되었습니다. 도메인이란? 입사를 하고 인수인계를 하게 되면 가장 먼저하는 것이 도메인에 대한 이해이다. 개발지식 만큼 가장 중요하게 생각하는 것이 도메인에 대한 지식이다. 조영호님은 이것을 실무적인 관점으로 간단하게 요약했는데 오프라인에서..

레디스에서 제공하는 자료구조 Strings 단순한 insert 문을 대체하기 위해 사용 key : Value 형태로 저장하며 모든 종류의 문자열 데이터를 저장할 수 있다. 예시: 유저 token 저장, JPEG 이미지를 저장하거나, HTML fragment 를 캐싱 등 List 일반적인 Linked List와 같은 구조로 되어 있어 데이터를 앞에서 넣거나 뒤에서 넣어도 소모되는 시간은 동일하다. LPUSH, RPUSH, LPOP, RPOP을 통해 양쪽에 데이터를 넣거나 꺼낼 수 있다. 순차적으로 처리를 해야할 때 유용하다. 예시: Job Queue, Pub-Sub 패턴(발행-구독 패턴) 생산자가 아이템을 만들어서 list에 넣으면 소비자가 꺼내와서 액션을 수행하는 식으로 동작합니다. 트위터의 타임라인에 ..

내가 주로 주석을 쓰던 때를 생각해보면 나쁜 디자인의 코드를 숨기고 설명을 하려고 주로 썼던 것 같다. 하지만 계속 업데이트가 되고 코드가 바뀌면서 주석의 신뢰성은 점점 낮아졌고 주석을 보지 않게 되었다. 결국 주석도 레거시가 되어 나쁜 코드를 더 나쁘게 만드는 상황이 된 것이다. 주석은 나쁜 코드를 막아주지 못한다. 나쁜 코드를 설명하기 위해 주석으로 설명하다 보면 점점 지저분해지는 코드를 볼 수 있다. 많은 개발자들이 가장 깔끔한 코드는 주석없이 의도를 잘 설명한 코드가 깨끗한 코드라고 한다. 그러니 우리는 주석에 시간을 투자하는 것보다 아래처럼 투자해보는 것은 어떨까? 주석을 달아야 코드를 이해할 수 있다면 다시 작성해보자 코드로 의도를 표현할 수 있게 고민하고 설계한다. 주석보단 좋은 네이밍을 통..