- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 아까 큰돌님 강의에서 컨트롤러가 메인 로직을 담당한다고 배웠는데, AI 퀴즈에서는 모델이 비즈니스 로직을 담당한다고 하네요..?메인 로직과 비즈니스 로직이 다른건가요? 모델이 데이터를 관리하는 것까지는 맞는 것 같은데 비즈니스 로직도 관리하나요? 그럼 스프링 개발 시 Service 레이어도 Model에 속한다고 봐도 될까요? 항상 강의와 유튜브 잘 보고 있습니다. 감사합니다!

헤더1개 Cpp파일 1개  코드를 여러 개의 파일로 모듈화하는 방법에 대해 질문드립니다.함수 모듈화, 헤더파일 디자인, 파일 구조 설계, 순환참조 방지 등에 대한 지식이 없어서 어떻게 파일을 속성에 따라 나누고, include해야 원래 코드와 동일하게 동작하게 만들 수 있는지 모르겠습니다. gpt 한테물어보니 디자인패턴을 공부하라고 하는데, 디자인 패턴은 이미 파일 구조가 짜여진 내에서 클래스를 세분화하거나 코드 재사용성을 위한 상속에 관한 내용 같았습니다. 위 경우 어떤 내용을 공부하거나 참고하면 좋을까요? 정말 고민되어서 여쭤봅니다. ㅎㅎ

교재 42, 43쪽의 자바스크립트 코드를 실행하려고 하니다음과 같이 떠서요.혹시 어떻게 실행시켜야 하나요?

싱글톤을 정적멤버로 생성하는 경우 싱글톤 인스턴스가 필요없는 경우도 무조건 싱글톤 클래스를 호출해 인스턴스를 만들어서 자원낭비가 일어날 수 있다고 배웠습니다 그런데 제가 좀 더 알아보니 클래스 로딩은 클래스를 실제로 사용하기 전까지는 로딩을 하지 않는다고 하더라고요대신 정적 멤버 중 하나만 불러오더라도 다 불러와진다는 것을 알게됐습니다. 실제로 싱글톤 클래스를 사용하기 전까지 초기화가 되지 않는다는 점과 싱글톤 클래스를 사용하면 싱글톤을 생성하기 위해 사용할 확률이 높기 때문에 자원낭비가 되지 않을 것 같다고 생각했습니다 이 부분이 좀 헤갈리는 것 같아서 질문올립니다!

우선 추천해주신대로 디자인패턴 강의를 아직 수강하지는 않았습니다. (수강 예정입니다!) 이 강의에서 팩토리 메소드 패턴을 보여주셨습니다. 물론 책에서 "팩토리 메소드 방식도 적용할 수 있다"라는 문구때문에 예시를 들어주신 것 같긴한데, 이 강의에서 보여주신 예제만 보면 SpellChecker 클래스의 클라이언트가 Dictionary 인터페이스의 구현체만 주입해줘도 충분할 것 같습니다.그런데 굳이 팩토리를 주입받고 그 팩토리로부터 Dictionary 구현체를 반환받아 자신의 Dictionary 타입의 필드에 할당하는게 조금 와닿지가 않습니다. 최대한 단순하게 예시를 들어주신거라고 이해하고는 있습니다만 궁금해서 질문드립니다. 추가) 강의 끝 부분에 객체를 생성하는 과정이 복잡할 때 사용한다고 하셨는데, 클라이언트에게 복잡한 객체를 생성하는 일을 시키지 않기 위해서...사용하는 것일수도 있겠네요.(자문자답일까요..)

최근에 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 구조를 벗어나기가 힘든 것 같아요)     작은 스타트업에서 주니어 혼자 끙끙 앓고 있어 답답한 마음에 여기에라도 질문을 올려봅니다. 너무 막연한 질문이라, 답변 주시기 어려울 것 같은 부분이 있다면 답변 안 주셔도 괜찮아요. 강의 제공 받는 것만으로도 저에게는 정말 큰 도움이 돼요 (사실 저도 어떻게 질문할지 막막해서 제가 봐도 어렵네요..) 항상 도움 주셔서 감사합니다 영한님 :)