Optional

이 글은 스터디 내에서 스프링 입문을 위한 자바 객체 지향의 원리와 이해를 읽고 정리한 글입니다. C++ 언어 - 정말 인간적인 프로그래밍 방법론, 객체 지향 C++는 C에 객체 지향 개념을 도입함으로써 역사에 한 획을 그은 언어가 되었음. 자바 - 진정한 객체 지향 언어 자바에서는 클래스를 떠나 존재할 수 있는 것이 아무것도 없음. 자바와 C#은 가상 머신(Virtual Machine)을 지원함. -> Write Once Use Anywhere 자바의 경우 단 하나의 컴파일러만 필요하고, 기종별 JRE 세팅 필요 UML을 대하는 자세 UML은 의사소통의 도구이며, 표기 방법론일 뿐이다. CBD(Component Based Development) 컴포넌트 기반 개발: 애플리케이션을 통째로 개발하지 말고,..

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다. 추상화 기법 분류와 인스턴스화: 분류는 객체의 구체적인 세부 사항을 숨기고 인스턴스 간에 공유하는 공통적인 특성을 기반으로 범주를 형성하는 과정, 분류의 역은 범주로부터 객체를 생성하는 인스턴스화 일반화와 특수화: 일반화는 범주 사이의 차이를 숨기고 범주 간에 공유하는 공통적인 특성 강조, 일반화의 역은 특수화 집합과 분해: 집합은 부분과 관련된 세부 사항을 숨기고 부분을 사용해서 전체를 형성하는 과정, 집합의 반대 과정은 전체를 부분으로 분리하는 분해 과정 개념과 범주 객체를 분류하고 범주로 묶는 것은 공통의 개념을 적용하는 것을 의미한다. 세상에 존재하는 객체에 개념을 적용하는 과정을 ..

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다. ​ 개념 관점: 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 명세 관점: 인터페이스와 구현을 분리해야 한다. 구현 관점: 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다. 포함 관계 또는 합성 관계: 예시) 메뉴판 타입과 메뉴 항목 타입 간의 관계 연관 관계: 한 타입의 인스턴스가 다른 타입의 인스턴스를 포함하지는 않지만, 서로 알고 있어야 할 경우 도메인 모델: 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델 인터페이스 정리하기 객체가 수신한 메시지가 객체의 인터페이스를 결정한다. 객체가 어떤 메시지를 수신할 수 있다는 것은 그..

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다. 자율적인 책임 적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 낳는다. 객체가 자율적이기 위해서는 객체에게 할당하는 책임의 수준 역시 자율적이어야 함. 너무 추상적인 책임 책임은 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이어야 한다. 어떻게가 아니라 무엇을 자율적인 책임의 특징은 어떻게 해야 하는가가 아니라 무엇을 해야 하는가를 설명한다는 것. 메시지 하나의 객체는 메시지를 전송함으써 다른 객체에 접근한다. 메시지: 메시지 이름, 인자의 조합 메시지 전송: 수신자, 메시지 이름, 인자의 조합 객체가 제공하는 메시지는 외부의 다른 ..

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다. 객체지향 설계의 전체적인 품질을 결정하는 것은 개별 객체의 품질이 아니라 여러 객체들이 모여 이뤄내는 협력의 품질이다. 협력 협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다 책임 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나 적절한 행동을 할 의무가 있는 경우 객체가 책임을 가진다고 말한다. 책임의 분류 객체의 책임은 객체가 무엇을 알고 있는가와 무엇을 할 수 있는가로 구성된다. 메시지 전송 : 객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것 책임이란 객체가 협력하기 위해 수행하는 행위를 상위 수준에서 개략적으로 서술 -> 책임 결정후 실제 메시지로 변환할 때는..

필드 주입의 단점 1. 의존성을 추가하기가 쉽지만 단일 책임 원칙을 위반하지 않도록 주의해야 함. 많은 의존성이 생기면 클래스에 대한 책임이 커지므로 리팩터링 시에 관심사를 분리하기 어려움. 2. 의존성 주입의 책임은 스프링의 컨테이너에게 있지만, 필드 주입을 사용하면 어떤 타입의 의존성이 실제로 필요한지 의존성이 필수인지 여부가 명확하지 않을 수 있음. 3. 필드 주입은 final 필드에 사용할 수 없음. 4. 필드 주입은 의존성을 수동으로 주입해야 하므로 테스트 코드를 작성하기 어려움. @Component를 사용하면 기본적으로 @Service와 동일한 효과 가능 둘 중 어떤 어노테이션이라도 적용한 클래스는 애너테이션 기반 구성의 자동 검출과 클래스 경로 스캐닝의 대상이 됨 @Service는 @Comp..