sung.hyun.1204 sung.hyun.1204

1. 무조건 lazy, 무조건 eager : 그런거는 없어, 경계를 잡는 방법의 차이다. 2. 연관관계를 끊자.  연관관계란 , 다른 객체를 탐색을 하는 경로로  디비 트랜잭션의 락을 전부 거는 상황이 나올수 있다.연관관계를 끊는 방법으로 객체의 다른 도메인의 속하는 객체의 id 를 넣고, 레포지토리에서 검색을 하자.레포지토리는 연관 관계를 정의하는 메서드로 이루어져 있어야 한다. 3. 도메인 에그리거트, 루트 를 생각하자.같이 생성이되는지, 같은 제약사항이 걸리는지 파악을 해야한다.같은 제약사항이 걸린다면  , 연관관계를 걸되, 다르면 그룹을 분리해서 id 로 참조하게 하여 데이터베이스 경합이 발생하는 성능 이슈를 최소화 해야한다. -> DDD  의 컨택스트를 잡는 기준이 될 수 도 있다.  왜 설계를..

- 이 글은 책 오브젝트 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 객체지향 설계 두 가지 방식 상태 중심 : 구현이 불안정하기 때문에 객체의 상태가 인터페이스에 스며드는 변경에 취약한 코드가 생길 수 있다. 예시 ) 필요한 기능을 만들기 위하여 데이터를 우선적으로 생각하여 클라스를 만든후 접근 제어자를 넣어준후 중앙에서 통재하는 클라스에서 모든 객체의 상태를 호출하여 원하는 결과를 만드는 방식. 책에서는 데이터를 가지는 구현채들이 get ,set 이외의 로직이 없다. 작년 겨울에 짰던 코드: MVC 패턴을 생각 했지만 내부의 BL 이 없다. public class Player { private Exception exception; private List playerNumbers; pub..

수정 : 23년 4월 8일 "객체지향"이란 공통된 로직 ,공통된 데이터를 하나로 묶어서 하나로 관리를 하는 것 이다." 라는 답변은 22년 9월 , 객체지향의 사실과 오해 및 오브젝트 를 읽기전, 우아한 테크 코스 프리코스 참여 전에 생각한 답변이다. OOP : 객체 지향 프로그래밍 이다. 객체라는 말이 오해를 만든다고 포* 선생님은 "개체" 라고 부르신다. 공통된 로직 ,공통된 데이터를 하나로 묶어서 하나로 관리를 하는 것 은 객체지향이 아니라 캡슐화 이다. 객체지향 프로그래밍을 한다라는 것은 , 객체들이 메시지를 통하여 외부의 요청에 대하여 객체간 서로 상호작용을 하여 원하는 목적을 이루게 하는 프로그래밍을 하는 관점을 가지는 프로그래밍을 하자라는 페러다임이라고 이해를 하자. 왜 관점인가 ? 컴퓨터 ..

오브젝트 챕터 3의 내용은 책 객체지향의 사실과 오해 내내 했던 이야기이다. 협력(collaboration) ,책임(responsibility),역할(Role) 이라는 단어를 안다면 하단의 Solid 원칙을 다시한번 정리한 부분만 보고 넘어가도 충분하다. Point RDD : Responsibility Driven design 하자 , 상태보단 행위 이며 메시지가 객체를 선택하자 추상 클라스와 인터페이스 잘쓰자 협력 (collaboration) : 객체들끼리 어떠한 기능을 수행하기 위하여 하는 상호작용 책임(responsibility) : 협력에 참여하기 위해 객체가 수행하는 행동 . 역할(Role) : 어떤 특정한 협력 안에서 수행하는 책임의 집합. ~ DIP 한종류의 객체만 협력에 참여를 하는 상황이..

- 이 글은 객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 글은 4월 초에 완성합니다. chpt 5 책임과 메시지 chpt 5 point : 메시지가 인터페이스를 결정한다. 메시지를 중심으로 생각을 하자. 인터페이스를 통해서만 다른 객체의 메시지를 보내고 , 메시지를 통해서만 다른 객체의 정보를 받을 수 있다. ISP 예시 : 인터페이스를 나누는 케이스 King. → message(증언하라) → Alice King. → message(증언하라= message name ) → Alice 자신의 의지에 따라 증언 할 수 있는자유 왕의 증언하라 라는 메시지 vs 목격했던 장면을 떠올려라 메시지 class A a = new A() ; → a.speakInCoart() →a.s..

- 이 글은 객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 글은 4월 초에 완성합니다. chpt 3 타입과 추상 리스코프 치환 원칙을 먼저 설명한다. “서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다." 로버트 C. 마틴 조용호 님의 블로그 주소이다 : http://aeternum.egloos.com/ 토비님의 유투브에 나온 인터뷰에서 가져왔다. : https://www.youtube.com/watch?v=8OclN9kZTE4 책은 나오는 것 까지 7년이 걸렷다고 한다, 추상화를 통해 복잡성을 극복한다. 복잡한 런던 지하철의 초기 지도는 실측을 기반으로 사용자에게 정보를 제공하였지만, 복잡했다. 오늘날의 지하철은 역간의 거리와 상관 ..

합성을 이해 하고 , 상속은 인터페이스 상속을 위해 사용되어야 한다. (마지막 수정일 : 23/03/25) 이글은 오브젝트 2장과 각종 블로그의 정리글 + 인프런 김영한님의 스프링 핵심 원리의 내용을 다루며 글 말에는 어떻게 프로젝트의 적용을 했는지 서술 한다. 오브젝트 2장에서 다룬 개념을 먼저 보자, 전반적인 이해를 위해서는 객체 지향의 사실과 오해의 내용을 읽었으면 한다. [다형성] 메시지와 메서드는 다른 개념이다. 하나의 객체는 동일한 메시지를 전송하지만 실제로 어떤 메서드가 실행될 것인지는 메시지를 수신하는 객체의 클래스가 무엇이냐에 따라 달라지며 이를 다형성이라 한다. [코드의 의존성과 실행 시점의 의존성은 다를 수 있다] - Lazy Binding ,Dynamic Binding public ..

- 이 글은 객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다. 글은 4월 초에 완성합니다. chpt 1 : 협력하는 객체들의 공동체 협력하는 사람들 역할 책임 협력 협력 속에 사는 객체 객체는 상태와 행위를 갖는다. class A { int a public addA(){ } } 객체지향의 목표: 실세계를 모방하는 것이 아니다. : 오히려 세계를 창조하는 것이다. 객체지향의 본질 : 클라스가 본질이 아니다. 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다. 역할, 책임, 협력에 집중하자. 정통적인 객체 지향의 설계의 핵심 사상 : 완전 연결성 실세계의 사물을 기반으로 소프트웨어 객체를 식별하고 구현까지 이어간다. 역할 : 역할은 대체 가..