질문에 앞서 해당 질문은 'CentOS 7.* 서버쪽으로 배포를 해보던 중에 질문드립니다.' 질문과 연관됩니다. 안녕하세요.  이번 강의를 통해 만들어본 프로젝트를 운영환경쪽으로 배포해 보고자 합니다.운영환경 서버 S/W 정보는 아래와 같습니다. [서버 S/W 정보] 1. OS: CentOS 7.9 2. Language: PHP 7.3.27 3. Database: MariaDB 10.4.17 4. Web Server: Apache 2.4 (기본적인 APM 구성을 따르고 있습니다.)   현재 아파치 웹 서버의 가상호스트(VirtualHost) 설정을 통해 부여된 도메인으로 접근이 가능하도록 설정해 놓은 상황입니다. 하지만 사이트 접근 시 500 Error 페이지로 전환됨에 따라 PHP error log를 확인해 본 결과 아래와 같은 에러 메시지가 출력되고 있는 상황이었습니다. PHP Parse error:  syntax error, unexpected '=>' (T_DOUBLE_ARROW), expecting ')' in {DOCUMENT ROOT}/vendor/painkill2r/inflearn-lecture-lib/src/Application.php on line 27 소스코드를 확인해 보니 Arrow Function에서 문제가 발생하는 것 같아서 문법 지원 버전을 확인해보니 PHP 7.4부터 지원되는 문법으로 확인이 되어 운영환경은 PHP 7.3을 사용하고 있기 때문에 에러 페이지로 전환되는 것으로 원인 파악이 되었는데요. 이런 경우 PHP 버전 업데이트를 하지 않고서는 해결이 불가능한 문제인지 아니면 다른 문법으로 변경을 해서라도 접속이 되게 할 수 있는지 첨언 부탁드립니다.감사합니다.

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

선생님 SOLID 객체지향을 공부하다가 궁금한게 있어서 질문드립니다. S. 단일책임의 원칙에서 객체는 하나의 책임만 갖고있어야한다고 했는데 간단한 MVC 패턴의 웹서비스를 생각해보면(입문편에서 만들어본 회원가입예제처럼) DAO나 Repository 객체가 비지니스 로직의 메세지를 받고 DB와 소통한다는 책임을 갖지만 달리 보자면 CRUD에 대한 모든 메소드를 다 갖고있는만큼 여러 책임을 갖고있는것 아닌가요? 이런게 강의에서 말씀하신 단하나의 책임이란 개념의 모호함인가요?

AppConfig가 DIP와 OCP를 해결하기 위하여 MemberServiceImpl 과 OrderServiceImpl에 'new MemoryMemberRepository' 를 주입하는 역할을 하잖아요? 근데 리팩토링 하기전에는 orderService() 와 memberService() 에서 'new MemoryMemberRepository' 를 각각 따로 생성하는걸 중복이라고 보고 이를 해결하기 위해서 리팩토링하여 memberRpository() 를 만들어 한번만 생성하도록 하여 중복을 막으신거라고 이해해도 괜찮은가요??