Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Share] 6주차 토론 내용 #19

Open
sojeongw opened this issue Feb 13, 2020 · 1 comment
Open

[Share] 6주차 토론 내용 #19

sojeongw opened this issue Feb 13, 2020 · 1 comment
Labels
Share This issue is about sharing things related with study

Comments

@sojeongw
Copy link

sojeongw commented Feb 13, 2020

Topic

[토비의 스프링] 6장. AOP

Detail

이번 주는 주제 자체가 어려워서 토론 내용이 혼돈의 카오스였읍니다.
서기로서의 역할을 충실히 하지 못했음을 반성합니다...쥬르륵

리플렉션

Invoke()

screenshot 2020-02-12 오후 9 44 41

주형
invoke()에서 인자로서 Object proxy를 받고있는데 정작 사용하고 있지는 않다. 무슨 역할을 하고 있는가?

-> 조사해서 알게 되면 issue에 올리기로 합의

리플렉션의 효용성

현식
이번 챕터 예제에서 리플렉션이 너무 오바같다는 생각을 했다. 리플렉션을 사용하기엔 코드가 너무 단순하기 때문이다.
리플렉션은 단점도 많다. 예를 들어 메소드 이름이 바뀌면 대처를 못한다.

프록시와 데코레이터 패턴

주형
특정 기능만 추가할 때는 굳이 프록시를 쓰지 않아도 될 것 같다. 너무 복잡하다.
그냥 데코레이터 클래스 하나를 만든 뒤 @Configuration에서 빈을 등록할 때 원하는 데코레이터를 한번 감싸서 등록하면 주입받아서 쓸 수 있다.
부가 기능을 전반적인 부분에 다 쓰는게 아닌, 그냥 A만 쓰는 상황이라면 필요없다고 생각한다.

근원
나는 그래도 AOP를 써야 한다고 생각한다. 관심사가 분리되어야 하기 때문이다.

주형
그건 맞는데 굳이 '프록시'로 써야하는지 잘 모르겠다. 데코레이터를 프록시가 아니라 코드로 관리하는 게 좋을 것 같다.
AOP의 핵심은 데코레이터가 아닌 것 같다는 말을 하고 싶었다. 부가 기능이 모두에게 해당될 때 의미가 있다는 것이다.


이번 주도 수고 많으셨습니다!

@sojeongw sojeongw added the Share This issue is about sharing things related with study label Feb 13, 2020
@ttkmw
Copy link

ttkmw commented Feb 15, 2020

곧 aop관련 내용을 정리해서 블로그에 올릴 예정입니다. 그 때 공유하겠습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Share This issue is about sharing things related with study
Projects
None yet
Development

No branches or pull requests

2 participants