묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결이펙티브 자바 완벽 공략 1부
굳이 팩토리 메소드 패턴을 쓰는 이유가 뭔가요??
우선 추천해주신대로 디자인패턴 강의를 아직 수강하지는 않았습니다. (수강 예정입니다!) 이 강의에서 팩토리 메소드 패턴을 보여주셨습니다. 물론 책에서 "팩토리 메소드 방식도 적용할 수 있다"라는 문구때문에 예시를 들어주신 것 같긴한데, 이 강의에서 보여주신 예제만 보면 SpellChecker 클래스의 클라이언트가 Dictionary 인터페이스의 구현체만 주입해줘도 충분할 것 같습니다.그런데 굳이 팩토리를 주입받고 그 팩토리로부터 Dictionary 구현체를 반환받아 자신의 Dictionary 타입의 필드에 할당하는게 조금 와닿지가 않습니다. 최대한 단순하게 예시를 들어주신거라고 이해하고는 있습니다만 궁금해서 질문드립니다. 추가) 강의 끝 부분에 객체를 생성하는 과정이 복잡할 때 사용한다고 하셨는데, 클라이언트에게 복잡한 객체를 생성하는 일을 시키지 않기 위해서...사용하는 것일수도 있겠네요.(자문자답일까요..)
-
미해결코딩으로 학습하는 GoF의 디자인 패턴
그토록 기다리던 강의!
최근에 Gof의 디자인패턴을 읽으면서 드는 소감은 '20년전 책이라 당시 언어로 작성된 예제를 이해하기 힘들다' 였습니다. 매번 구글링하면서 찾아보고 비교하기도 했지만, 여러가지 디자인패턴에 대한 이해와 궁금증을 해소하기엔 부족했습니다. 이제야 부족함을 채울 수 있겠습니다. 감사합니다!
-
미해결스프링 핵심 원리 - 기본편
스프링에서 디자인패턴 적용
안녕하세요? 영한님 강의를 너무나도 잘 듣고, 실무에 적극 활요하며 성장 중인 주니어 개발자입니다. 먼저, 항상 좋은 강의 제공해주셔서 감사합니다. (벌써 3번째 듣는중인 강의입니다!) 다름이 아니라, 최근에 영한님께서 추천해주신 객체지향의 사실과 오해라는 책과, 오브젝트라는 책을 정독했어요. SOLID원칙에 조금 더 자세하고 정확하게 대해서 알게 되었고, 객체를 설계하는 법, 책임주도 설계 등 다양한 객체지향 원칙들을 배우고 학습하였는데 이를 실무에 어떻게 적용해나가야 할지 궁금합니다. Q1. 강의 중 [조회한 빈이 모두 필요할 때, List, Map] 에 나온 내용과 같이, 하위의 구체 타입 클래스들을 모두 Spring Bean으로 등록시키고 애플리케이션 컨텍스트가 실행되는 시점에 의존관계를 맺어주고, 필요한 상황에 따라서 필요한 Bean을 찾아서 알고리즘을 수행하면 되는 걸까요? 강의에서 말씀해주셨던 Strategy 패턴과 같이 다른 디자인 패턴들도 비슷한 방식으로 적용해나가면 될지?에 대한 궁금증이었습니다. Q2. 그렇게 된다면, 특정한 인터페이스를 설계하고 그 인터페이스를 구현하는 객체들은 모두 Spring Bean으로 등록되어야 할 것 같은데 방식이 맞을까요? Q3. 그리고 외부에서 어딘가 협력하는 객체의 구체 타입에 대한 정보를 알고 있고 전달해주어야 하는데, 예를 들어 강의에 나온 것처럼 파라미터에 구체 타입에 대한 문자를 받고 진행한다면 컨트롤러 레이어에서 해당 문자를 전달 해주면 컨트롤러 계층은 호출하는 서비스 계층이 어떤 클래스들과 협력하는지에 대한 정보를 알아야 하므로, 이는 캡슐화가 위반되는 것이 아닌가 싶기도 합니다. 왜 이렇게 생각했는지 말씀드리자면 1) 컨트롤러 계층에서는 Serivce 클래스가 누구와 의존하고 있는지 알아야 합니다. 2) Service 클래스가 의존하는 대상이 추상화여도 그 추상화의 구체 인스턴스의 종류들에 대해서 알고 있어야 합니다. (그래야 원하는 알고리즘을 수행 가능) 3) 캡슐화는 단순히 객체의 내부 상태를 숨기는 것 이상의 의미를 가진다고 생각합니다. 만약 구체 인스턴스의 종류가 삭제된다면 분명 컨트롤러 레이어에서도 변경에 대한 여파가 있을 것 같다는 생각이었습니다. 4) 이를 무시하고도 실무에서는 보통 이런식으로 구현을 많이 하는 편일까요? Q4. 제가 너무 Controller - Service - Repository의 일반적인 MVC 레이어에서 벗어나지 못하는 것이라고 생각이 들기도 했습니다. 일반적으로 대규모 서비스를 운영하는 회사에서도 한 마이크로 서비스 내에서 Controller-Service-Repository 구조를 가져가는지 궁금합니다. 네이밍을 조금 다르게 한다던지, 패키지 구조가 조금 다르다던지.. 그런 내용들이 있을까요? (현재 프로젝트 구조는 멀티 모듈화 시켜서 협력 패턴이 최대한 다른 컨텍스트에서도 재사용 될 수 있도록 프레임워크/라이브러리화 시키면서 설계해보려고 노력 중입니다. 그래도 애플리케이션 모듈은 C-S-R 구조를 벗어나기가 힘든 것 같아요) 작은 스타트업에서 주니어 혼자 끙끙 앓고 있어 답답한 마음에 여기에라도 질문을 올려봅니다. 너무 막연한 질문이라, 답변 주시기 어려울 것 같은 부분이 있다면 답변 안 주셔도 괜찮아요. 강의 제공 받는 것만으로도 저에게는 정말 큰 도움이 돼요 (사실 저도 어떻게 질문할지 막막해서 제가 봐도 어렵네요..) 항상 도움 주셔서 감사합니다 영한님 :)