Taking baby-developer steps

객체 지향의 확장 가능하고 재사용성 높은 협력은 다형성 덕이지만, 다형성을 지탱하는 메시지가 존재하기 때문에 가능한 일 이다. 메시지, 객체지향 설계의 중심 객체 지향 애플리케이션의 중심 사상은 연쇄적으로 메시지를 전송하고 수신하는 객체들 사이의 협력 관계를 기반으로 사용자에게 유용한 기능을 제공하는 것이다. 객체 지향 설계는 시스템을 메시지를 주고 받는 동적인 객체들의 집합으로 바라봐야한다.(정적인 클래스들의 집합이 아니다!) 설계 과정에서, 객체들이 주고받는 메시지가 객체들의 윤곽을 결정하게 해야한다. cf > 데이터-주도 설계 메시지가 아닌, 데이터를 중심으로 설계하는 방식. 객체의 내부 구조를 객체 정의의 일부로 만들어 객체의 자율성을 저해한다. 외부에서 객체의 내부 구조 변경까지 관여하기에 객체..

디자인 패턴 공부를 시작하며 이전에 refactoring guru로 디자인 패턴을 공부한 적이 있었다. 귀여운 그림들이 있고 설명이 자세해서 좋은 자료이지만, 사실 그때 나는 클래스와 객체를 동일한 것이라 생각하고 있었기에 디자인 패턴에 대한 근본적인 이해 조차 부족해 제대로 학습하지 못했던것 같다. https://refactoring.guru/design-patterns Design Patterns Design Patterns Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you can customize to solve a particular d..

자바 스프링 부트를 배우기 시작하며, 점프투 스프링부트에서 권장하는 IDE인 STS4를 처음 써보고 있다. 이클립스 기반으로 만들어진 IDE 라고 한다. 그런데, 글씨가 너무 작은데 "control" + "+" (+ "shift") 단축어가 전혀 먹히지 않아서 그냥 쓰고 있었는데, 거슬려서 설정 먼저 하자 하고 구글링을 해봤다. 대부분 window 탭 내의 Preferences 나 Properties 에 들어가라고 나오는데... 내 윈도우 탭에는 그런 메뉴가 없다.. 결론 : STS4를 클릭해 Settings으로 들어가면 된다 다크모드 전환 STS4 > Settings로 들어간 후 뜬 Preferences 창에서 General > Appearance 로 들어가 Enable Theming 에서 Dark로 ..

인터페이스와 구현체에 대한 생각 JPA는 자바 진영에서 ORM(Object-Relational Mapping)의 기술 표준으로 사용하는 인터페이스의 모음이다. 즉, JPA는 인터페이스이므로 이를 구현하는 실제 클래스가 필요하다. JPA를 구현한 대표적 실제 클래스에는 하이버네이트(Hibernate)가 있다. 처음 "JPA는 인터페이스 이므로 이를 구현하는 실제 클래스가 필요하다"는 말이 잘 이해가 되지 않았다. ORM이라고는 Typescript에서 typeORM을 써본 경험밖에 없었다. 그래서 chatGPT에게 JPA를 사용하는 CRUD 예시코드를 부탁했다. 하이버네이트와 이클립스링크를 활용한 JPA CRUD를 보고 나니, 주요 로직 및 코드 구조가 차이가 없었다. 차이라곤 의존성 파일에 Hibernat..

영속성 컨텍스트 - 엔티티를 관리하는 가상의 공간. (Spring Data JPA가 관리하는 엔티티 매니저가 엔티티를 영속성 컨텍스트에 저장한다) - JPA의 중요한 특징 중 하나. - 다음 4가지의 특징을 가지고 있다. 1차 캐시 영속성 컨텍스트는 내부에 1차 캐시를 가지고 있다. 캐시의 키는 엔티티의 @Id 애너테이션이 달린 기본키 역할을 하는 식별자이며 값은 엔터티이다. 엔터티를 조회하면 1차 캐시에서 데이터를 조회하고 값이 있으면 반환한다. 값이 없는 경우엔 데이터베이스에서 조회해 1차 캐시에 저장한 후 반환한다. 1차 캐시를 이용해, 캐시된 데이터는 DB를 거치지 않아 빠르게 데이터를 조회할 수 있다. 쓰기 지연 쓰기 지연(transational write-befind)은 트랜잭션을 커밋하기 전..

메서드 객체가 수신한 요청을 처리하기 위해 내부적으로 선택하는 방법을 "메서드"라고한다. 수신한 메시지를 처리할 수 있는지 여부를 확인 한 객체가, 책임을 다하기 위해 메서드를 선택한다. 객체지향 프로그래밍 언어에서 메서드는, 클래스 내 포함된 함수 또는 프로시저를 통해 구현된다. 절차적언어(예를 들어 C)는 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하지만, 객체지향 프로그래밍 언어는 그렇지 않다. 다형성 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미한다. 메시지는 "무엇"이 실행될지는 명시하지만 "어떻게"실행 할지는 수신자가 결정한다. 즉 동일한 메시지도 서로 다른 방식의 메서드를 이용해 처리할 수 있다. 서로 다른 객체들이 다형성을 만족 시킨다는 것은, 그들..

메시지 - 이번 포스팅은 C++, 자바, C# 등의 언어에서 사용되는 메시지 전송 문법을 사용해 예시를 보인다. 중요한 것은 메시지 전송 문법이 아니라, 메시지 전송을 구성하는 요소이다. 커피 주문을 위한 협력을 떠올려보자. 캐셔가 바리스타에게 "커피를 만들어라"라는 메시지를 전송한다. "커피를 만들어라" 부분을 메시지 이름(message name)이라고 한다. 메시지 전송 시 추가적인 정보가 필요한 경우 메시지의 인자(argument)를 통해 추가 정보를 제공할 수 있다. 커피를 만들어라(카페라떼, 한잔) 메시지 전송은 수신자와 메시지(메시지 이름 + 인자)의 조합이다. 캐셔가 바리스타에게 요청을 하기 위해서는 누구에게 전송을 해야하는지 알아야한다. 바리스타 역할을 맡은 박고슴씨에게 전송하고 싶다면 다..

"명확하게 정의된 역할과 책임을 지닌 객체들을 상호 협력하게 하라" 자율적인 객체 -> 책임의 수준 역시 자율적 스스로의 의지와 판단에 따라 각자 맡은 책임(요청을 처리하기 위해 객체가 수행하는 행동)을 수행하는 객체를 자율적인 객체라 한다. 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야한다. 예를 들어, 앞서 커피 주문에 협력하는 예시에서, 커피를 만드는 역할을 바리스타 객체의 경우 "카페라떼 한잔"을 요청 받았을 때, "에티오피아 원두 30g을 갈아라" "원두에서 2개의 샷을 추출해라" "90도씨로 우유 200ml을 2분간 스팀하라"라는 요청을 받았을 때 보다 커피 제작 방식을 자율적으로 선택할 수 있다. 너무 추상적인 책임 그러나 과도하게 포괄적이고 추상적인 책임 역시 ..

역할, 책임, 협력의 관점에서 애플리케이션을 설계하는 3가지의 유용한 기법이 있다. 책임-주도 설계 -> 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차를 제시 디자인 패턴 -> 책임-주도 설계의 결과를 표현 테스트-주도 개발 -> 설계를 테스트하는 좋은 도구 책임-주도 설계 - 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션을 설계 객체지향 시스템의 목적은 1. 사용자의 요구를 만족 시킬 수 있는 기능을 제공하고 2. 이해하기 쉽고, 단순, 유연한 상호작용을 제공하는 객체들의 공동체를 구축 하는 것이다. 가장 핵심은 역시나 "올바른 책임"을 "올바른 객체"에게 할당하는 것이다. 객체지향 언어 사용, UML 같은 모델링 언어로 설계의 밑그림을 그리는 것이 객체..

객체 지향 입문자들은 데이터나 클래스를 중심으로 애플리케이션을 설계한다. 이는 협력이라는 문맥을 고려하지 않고 각 객체를 독립적으로 생각하기 때문이다. 그러나 다음을 명심해야한다. 객체가 존재하는 이유는 행동을 통해 협력에 참여하기 위함이다. 객체에서 중요한 것은 데이터보단 객체의 행동, 즉 책임이다. 객체지향은 클래스를 어떻게 구현할 것인가가 핵심이 아니다. 중요한 것은 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지를 결정하는 것이다. 잘못된 객체지향설계의 예를 살펴보자. "토끼"의 인스턴스 모델링을 할 때 흰털에 빨간 눈, 귀여운 자태를 생각하고 그 모습을 기반으로 클래스를 개발 했다. 그러나 이 전형적인 토끼의 모습으로 소프트웨어 객체를 창조하는 것은 도움이 되지 않는다. "토끼"가 참여할 ..