2022/09

2022.09.28 - [프로그래밍 노트/SPRING] - [Spring] 프록시팩토리_1 (feat. Advice) 2018.07.01 - [프로그래밍 노트/SPRING] - [Spring] Spring AOP(Aspect Oriented Programming)1 AOP 하면 빠질 수 없는 용어들이 있다. 블로그를 찾아보니 2018년도에 AOP 관련 용어를 정리한 글이 존재하는데… 프록시 팩토리에서 찍먹으로 사용되니 몇 개만 속성으로 알아보자 포인트 컷(Pointcut) 어떤 포인트(Point)에 기능을 적용할지 하지 않을지 잘라서(cut) 구분하는 것 어디에 부가기능(Advice)을 적용할지 판단하는 필터링 로직 어드바이스(Advice) 실제로 기능을 구현한 객체 프록시가 호출하는 부가 기능 어드바이..

2022.09.27 - [프로그래밍 노트/SPRING] - [Spring] 동적 프록시 기술(feat. 리플렉션) 바로 직전 포스팅에서 동적 프록시 기술에 대해 알아보았는데, 이런 의문점을 가질 수 있다. 인터페이스가 있는 클래스는 Jdk Dynmic Proxy를 사용하고, 존재하지 않는 경우에는 CGLib 를 사용해야하니 InvocationHandler 와 MethodInterceptor 를 모두 구현해놔야하는 것인가? 물론.. 그래도 되지만 스프링에서는 프록시 생성을 추상화하여 프록시 팩토리(ProxyFactory)라는 것을 제공해준다. 우리는 타겟 객체가 인터페이스를 구현했는지 안했는지 알필요가 없다. 프록시 팩토리에서 인터페이스가 있으면 자동으로 Jdk Dynamic Proxy를 사용하고, 구체 ..

2022.09.26 - [프로그래밍 노트/SPRING] - [Spring] 프록시 활용 - 프록시 패턴, 데코레이터 패턴 앞 전에서 프록시 관련 내용을 살펴보았다. 프록시를 사용하면 대상 클래스에 부가 기능이나 접근제어를 적용할 수 있는 장점이 있었다. 부가 기능을 추가해야하는 클래스의 수가 많지 않으면 프록시를 구현하여 적용하면 되지만, 문제는 부가 기능을 추가해야하는 클래수가 많다면 그 수 만큼 프록시 클래스를 만들어야하는 단점이 존재한다. (클래스 수 만큼 프록시 클래스를 만드는 것은 역시 미친짓이다..) 이러한 단점을 해결하기 위해 프록시를 적용할 코드를 하나만 만들고 프록시 객체를 만드는(찍어내는?) 동적 프록시 기술이 존재한다. JDK Dynamic Proxy - JAVA 에서 제공 CGLIB..

이 글의 내용은 김영한님의 스프링 핵심 원리 - 고급편 내용을 정리하였다. AOP들어가기 전 프록시에 대한 정리 프록시의 주요 기능 접근 제어 권한에 따른 접근 차단 캐싱 지연 로딩 부가 기능 추가 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행 요청 값이나, 응답 값을 중간에 변형한다. 실행시간을 측정해서 추가 로그를 남긴다. 클라이언트와 서버라고 하면 보통 서버 컴퓨터를 생각하게 된다. 하지만 클라이언트와 서버의 개념은 상당히 넓게 사용된다. 클라이언트는 의뢰인, 서버는 서비스나 상품을 제공하는 사람이나 물건을 뜻한다. 이 개념을 객체에 도입하면, 요청하는 객체는 클라이언트가 되고, 요청을 처리하는 객체는 서버가 된다. 클라이언트가 요청한 결과를 서버에 직접 요청한는 것이 아니라 어떤 대리자(P..

[ 상황 ] feature 브랜치에서 기능을 개발하고 develop 브랜치로 병합을 하였다. 병합 후 서버를 올렸더니, feature 브랜치의 기능에 오류가 있는 것을 발견하고 병합된 commit 을 revert 시켰다. 오류 수정 후 다시 feature → develop 머지를 진행하는 경우 case1. 이 후 작업한 내용이 revert 작업 파일과 다른 경우 revert 이후 작업들만 develop에 머지된다. (충돌이 나지 않아 실수하기 쉬움) feature 내용들이 모두 develop 에 머지될 것으로 보이지만, revert 한 commit 이 feature 에서 작성한 commit 보다 최신일 경우에는 이 후 작업 내용들만 머지된다. case2. revert 되었던 파일을 수정한 경우 수정된 파..

객체의 책임과 메시지 객체 설계를 더 잘하기 위해 객체를 이해해보자.. 객체는 객체지향 공동체에서 어떤 역할을 하는 것일까..? 자율적인 책임 객체지향 공동체를 구성하는 기본 단위는 ‘자율적'인 객체 자율적인 객체? 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로부터 요청을 수신했기 때문이다. 요청을 처리하기 위해 객체가 수행하는 행동을 책임 이라고 한다. 즉, 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다. 상세한 수준의 책임들은 자율성을 제한한다. 즉 요청하는 객체에 의존할 수 밖에 없다. 증언해라 vs 목격..

더 뛰어난 객체 설계를 하기 위해 역할 / 책임 / 협력에 대해 정리한다. 객체지향 설계의 전체적인 품질을 결정하는 것은 개별 객체의 품질이 아니라 여러 객체들이 모여 이뤄내는 협력의 품질이다. 훌륭한 객체지향 설계자는 객체들 간의 요청과 응답 속에서 창발하는 협력에 초첨을 맞춰 애플리케이션을 설게한다. 협력이 자리를 잡으면 저절로 객체의 행동이 드러나고 뒤이어 적절한 객체의 상태가 결정된다. 협력 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작된다. 요청을 받은 사람은 일을 처리한 후 요청한 사람에게 필요한 지식이나 서비스를 제공하는 것으로 요청에 응답한다. 다른 사람으로부터 요청을 받은 사람 역시 자신에게 주어진 일을 처리하던 중에 다른 사람의 도움이 필요한 경우가 있다. 결과적으로 협력은 다..

초기 지하철 노선도는 지형 위에 구불구불한 운행 노선과 불규칙적인 역 간의 거리를 사실적으로 묘사하였었다. 문제는 사실적인 정보가 오히려 지하철을 이용하는 승객들로 하여금 노선도를 이해하기 어렵게 만들었다는 점이다. 지하철 노선도 디자인에서 가장 중요한 것은 얼마나 사실적으로 묘사했느냐가 아니고 역과 역 사이의 연결성을 얼마나 직관적으로 표현했느냐인 것이다. 그 후 사실적인 지형과 축적은 무시하고 역 사이의 연결성에만 집중한 혁신적인 지하철 노선도를 창조하게 된다. 승객이 꼭 알아야 하는 사실만 정확하게 표현하고(연결, 열차를 갈아타는 것) 몰라도 되는 정보는 무시함으로써 이해하기 쉽고 단순하며 목적에 부합하는 지하철 노선도를 만든 것이다. 즉 ,지하철 노선을 추상화한 것이다. 추상화는 목적에 맞게 현상..

객체 설계시 주의해야할 점 객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 설계하는 것이다. 보통 먼저 객체에 필요한 상태가 무엇인지 결정한 후 그 상태에 필요한 행동을 결정을 하게 된다. 자동차에는 연료량과 바퀴를 가지고 있다 → 자동차가 달리면 연료량이 줄어든다. 이렇게 상태를 먼저 결정하고 행동을 나중에 결정한다면 설계에 나쁜 영향을 주게 되는데.. 첫째, 상태를 먼저 결정할 경우 캡슐화가 저해된다. 상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버릴 확률이 높아진다. 둘째, 객체를 협력자가 아닌 고립된 섬으로 만든다. 객체가 필요한 이유는 애플리케이션 문맥내 다른 객체와 협력하기 위함이다. 상태를 먼저 고려하는 ..

프로그래밍을 하면서 가장 힘든게 객체지향적으로 프로그래밍을 하는 것이다. 메소드를 어디에 위치를 시켜야 맞는 것일까? 객체의 책임은 어디까지 가져가야하는 것일까? 요즘들어 이런 생각들을 자주하게 되면서 코드를 썻다 지웠다하는 것 같다. 혼자 해결이 불가능하여 예전에 읽고 잊어버렸던, 사실은 그 당시에는 잘이해가 안되었던 것 같다. 객체지향의 사실과 오해란 책을 피고 객체에 대해 다시 읽어 보았다. 고민을 하고 읽을 때와 무지성으로 읽었을 때는 확실히 다르더라.. 이 곳에 정리되는 내용은 나중에 객체가 무엇이였지? 라고 생각될 때 기억을 되살리기 위해 작성됬다. 객체 개별적인 실체로 식별 가능한 물리적인 또는 개념적인 사물은 어떤 것이라도 객체가 될 수 있다. 개념적인 사물? - 오늘의 주문내역 혹은 어제..