Books
-
[Real MySQL] 4장 아키텍처Books/Real MySQL 8.0 2024. 11. 9. 02:12
MySQL 엔진 아키텍처MySQL 서버는 사람의 머리 역할을 담당하는 MySQL 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구분MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분그리고 이 둘을 모두 합쳐서 MySQL 또는 MySQL 서버라고 표현MySQL 엔진클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러, SQL 파서, 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행 가능스토리지 엔진MySQL 엔진: 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행스토리지 엔진: 실제 데이터를 디스크 스토리지에 저장하거나..
-
가상 면접 사례로 배우는 대규모 시스템 설계 기초Books/가상 면접 사례로 배우는 대규모 시스템 설계 기초 (1,2) 2024. 11. 4. 20:21
Chapter 1장사용자 수에 따른 규모 확장성수백만 사용자를 지원하는 시스템을 설계하는 것은 도전적인 과제이며, 지속적인 개량과 끝없는 개선이 요구되는 여정단일 서버웹 앱, 데이터베이스, 캐시 등이 전부 서버 한 대에서 실행되는 시스템사용자의 요청이 처리되는 과정사용자는 도메인 이름(api.mysite.com)을 이용하여 웹사이트에 접속한다. 이 접속을 위해서는 도메인 이름을 도메인 이름 서비스(DNS)에 질의하여 IP주소로 변환하는 과정이 필요하다. DNS는 보통 제3 사업자 (third party)가 제공하는 유료 서비스를 이용하게 되므로, 우리 시스템의 일부는 아니다.DNS 조회 결과로 IP주소가 반환된다.해당 IP주소로 HTTP(HyperText Transfer Protocol) 요청이 전달된다..
-
아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라Books/이펙티브 자바 2023. 4. 23. 17:44
생성자에 매개변수가 많다면 빌더를 고려하라 정적 팩터리와 생성자에는 똑같은 제약이 하나 있다. 선택적 매개변수가 많을 때 적절히 대응하기 어렵다는 점이다. 예를 들어 식품 포장의 영양정보를 표현하는 클래스를 생각해보자. 영양 정보는 1회 내용량, 총 n회 제공량, 1회 제공량당 칼로리같은 필수 항목 몇 개와 총 지방, 트랜스지방, 포화지방, 콜레스테롤, 나트륨 등 총 20개가 넘는 선택 항목으로 이뤄진다. 그런데 대부분 제품은 이 선택 항목 중 대다수의 값이 0이다. 점층적 패턴 프로그래머들은 이럴 때 점층적 생성자 패턴을 즐겨 사용했다. 필수 매개변수만 받는 생성자, 필수 매개변수와 선택 매개변수 1개를 받는 생성자, 선택 매개변수를 2개까지 받는 생성자, ... 형태로 선택 매개변수를 전부 다 받는 ..
-
아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라Books/이펙티브 자바 2023. 4. 13. 23:14
클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자다. 하지만 모든 프로그래머가 꼭 알아둬야 할 기법이 하나 더 있다. 클래스는 생성자와 별도로 정적 팩터리 메서드(static factory method)를 제공할 수 있다. 그 클래스의 인스턴스를 반환하는 단순한 정적 메서드말이다. public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE; } 이 방식에는 장점과 단점이 모두 존재한다. 장점 1. 이름을 가질 수 있다. 하나의 시그니처로는 생성자를 하나만 만들 수 있다. 입력 매개변수들의 순서를 다르게 한 생성자를 새로 추가하는 방식으로 이 제한을 피해볼 수도 있지만 좋지 않은 발상이다. 이름..
-
[Book] 객체지향의 사실과 오해 - 최종편 (부록)Books/객체지향의 사실과 오해 2023. 4. 12. 17:02
추상화 기법 추상화는 도메인의 복잡성을 단순화하고 직관적인 멘탈 모델을 만드는 데 사용할 수 있는 가장 기본적인 인지 수단이다. 특성을 공유하는 객체들을 동일한 타입으로 분류하는 것은 객체지향 패러다임에서 사용하는 추상화 기법의 한 예다. 중요한 추상화 기법의 종류 분류와 인스턴스화 분류는 객체의 구체적인 세부 사항을 숨기고 인스턴스 간에 공유하는 공통적인 특성을 기반으로 범주를 형성하는 과정 분류의 역은 범주로부터 객체를 생성하는 인스턴스화 과정이다. 일반화와 특수화 일반화는 범주 사이의 차이를 숨기고 범주 간에 공유하는 공통적인 특성을 강조 일반화의 역을 특수화라고 한다. 집합과 분해 집합은 부분과 관련된 세부 사항을 숨기고, 부분을 사용해서 전체를 형성하는 과정을 가리킨다. 집합의 반대 과정은 전체..
-
[Book] 객체지향의 사실과 오해 - 7장. 함께 모으기Books/객체지향의 사실과 오해 2023. 4. 4. 18:28
마틴 파울러는 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점에 관해 설명한다. 파울러는 세 가지 관점을 각각 개념 관점, 명세 관점, 구현 관점이라고 부른다. 개념 관점(Conceptual Perspective)에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 도메인: 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말함 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발된다. 명세 관점(Specification Perspective)은 도메인의 개념이 아니라 실제로 소프트웨어 안에서 살아 숨쉬는 객체들의 책임에 초점을 맞추게 된다. 즉 객체의 인터페이스를 바라보게 된다. 명세 관점에서 프로그래머는 객체가 협력을 위해 '무엇'을 할 수 있는가에 초점을 맞춤 인터페이..
-
[Book] 객체지향의 사실과 오해 - 6장. 객체 지도Books/객체지향의 사실과 오해 2023. 4. 4. 18:18
객체 지도 지도는 실세계의 지형을 기반으로 만들어진 추상화된 모델 지도 은유의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라 기능 설계 대 구조 설계 모든 소프트웨어 제품의 설계에는 두 가지 측면이 존해한다. 하나는 기능(function) 측면의 설계이고 다른 하나는 구조(structure) 측면의 설계이다. 기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다. 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다. 좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다. 지도 은유를 통해 살펴본 것처럼..
-
[Book] 객체지향의 사실과 오해 - 5장. 책임과 메시지Books/객체지향의 사실과 오해 2023. 4. 4. 13:29
자율적인 책임 설계의 품질을 좌우하는 책임 객체지향 공동체를 구성하는 기본 단위는 '자율적'인 객체 객체들은 애플리케이션의 기능을 구현하기 위해 협력하고 협력 과정에서 각자 맡은 바 책임을 다하기 위해 자율적으로 판단하고 행동함 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로부터 요청을 수신했기 때문 요청을 처리하기 위해 객체가 수행하는 행동을 책임이라고 한다. 따라서 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체를 의미 자신의 의지에 따라 증언할 수 있는 자유 객체가 책임을 자율적으로 수행하기 위해서는 객체에게 할당되는 책임이 자율적이어야 한다. 재판 과정을 예시로 들면 판사는 목격자에게 '증언하라'는 요청을 전송한다. 요청은 수신자의 책임을 암시하므로 목격자는 재판이..