homebrew computer club

프로세스 프로세스는 ‘실행 중’인 프로그램 프로그램이 실행될 때 프로세스가 생성되고 PID를 부여받음. 프로세스를 생성하는 주체는 사용자가 될 수도 있고, 시스템이 될 수 있다. 프로그램과 프로세스는 동작을 하고 있는지, 하지 않고 있는지로 구분할 수 있다. 운영체제로부터 자원을 할당 받아 동작한다. 자원: CPU, Memory, IO, File 동작: CPU가 프로세스의 명령을 실행 사용자 및 시스템 프로세스가 존재 프로세스와 운영체제 프로세스 관리자 역할 프로세스를 생성 및 삭제 프로세스 실행(CPU 할당)을 위한 스케줄 결정 프로세스의 상태를 관리하며 상태 전이를 처리 프로세스의 상태 5-상태 모델(다섯 가지로 상태를 구분한 모델) 생성 처음 작업이 시스템에 주어진 상태. 즉, 프로그램을 이제 막 ..

논리적 모델링 단계 DBMS에서 사용하는 데이터 모델에 맞추어 데이터를 표현하는 과정 즉, ERD를 어떻게 RDBMS에 어떻게 담을 것인가 논의하는 과정 데이터 정의 언어 DDL로 기술된 개념 스키마 생성 관계형 모델(relation model) 1969년 에드가 F.코드에 의해 제안 릴레이션으로 데이터를 표현하는 모델 데이터 표현이 단순하고 직관적인 구조화 모델 현재 대다수 DBMS의 기초 Oracle, DB2, PostgresSQL, MySQL, MSSQL 등 릴레이션 구성 관계형 모델에서 표와 유사하게 2차원 구조로 데이터를 표현하는 구조를 릴레이션이라고 함. 스프레드 시트와 유사한 구조다. 관계형 모델은 위와 같은 표 형태로 구조화하고 저장하는 모델을 뜻한다. 일상생활에서 데이터를 저장하기 위해 ..

필요성 비즈니스적 관점 어떤 데이터를 저장해야 하는가? 어떤 데이터를 집어넣고, 집어넣지 않을지 결정하기 위해 비즈니스적 관점이 필요하다. 프로그래머의 관점 어떻게 데이터를 결정하는가? 어떤 데이터를 저장할 것인지 결정했으면, 그것을 어떻게 저장할지에 대한 관점이 필요하다. 모델링 단계 사용자 요구사항 분석 개념적 데이터 모델링 요구사항의 해석 오류를 방지 실세계 데이터를 개념적으로 일반화시켜 데이터 구조, 데이터 타입, 속성, 관계, 제약 조건 등을 이끌어내는 과정 논리적 데이터 모델링 → 개념 스키마 특정 DBMS의 구현 모델에 맞춰 데이터를 표현하는 과정 데이터 정의 언어(DDL)로 기술된 개념 스키마 생성 물리적 데이터 모델링 데이터베이스 파일 내부 저장구조, 파일 구성, 인덱스, 접근 경로 등을..

다음과 같은 제네릭 클래스가 있다. class Cup 위 코드에서 타입 파라미터 T 는 variance 한정자(out 또는 in )가 없다. 이럴 때는 기본적으로 invariant(불공변성)이다. invariant라는 건 제네릭 타입으로 만들어지는 타입들이 서로 관련성이 없다는 뜻. 말하자면 Cup 과 Cup , Cup 은 전혀 관계없다. 불공변성 관계 fun main() { val anys: Cup = Cup //Error: Type mistach val nothings: Cup = cup() // Error } 만약 어떤 관련성을 원한다면 out 또는 in 이라는 variance 한정자를 붙인다. out 은 타입 파라미터를 covariant(공변성)로 만든다. 이는 A가 B의 서브타입일 때 Cup 가..

Job의 라이프사이클을 이해하는 것은 잡을 구조화하고 실행 시에 발생하는 상황을 이해하는 데 중요하다. 잡을 정의할 때 실제로 하는 일은 잡과 관련된 청사진을 제공하는 것이다. 자바 클래스 코드 작성이 JVM에서 인스턴스를 생성하는 청사진을 정의하는 일인 것처럼 잡을 정의하는 것은 스프링 배치가 잡의 인스턴스를 생성하는데 필요한 일종의 청사진이다. 잡 실행은 job runner에서 시작한다. job runner는 잡 이름과 여러 파라미터를 받아들여 잡을 실행시킨다. 스프링 배치는 두 가지 잡 러너를 제공한다. CommandLineJobRunner: 이 잡 러너는 스크립트를 이용하거나 명령행에서 직접 잡을 실행할 때 사용한다. CommandLineRunner는 스프링을 부트스트랩하고, 전달받은 파라미터를 ..

배치 프로그램 정해진 시간에 일괄 작업을 처리한다(대체로 대용량) 배치 프로그램은 보이지는 않지만 늘 존재한다. 서비스 운영 관점에서 주기적으로 작업을 처리하려면 배치 프로그램을 사용해야 한다. 배치 프로그램이 필요한 상황 필요한 데이터를 모아서 처리해야 할 때 ex. 월별 거래 명세서 생성 일부러 지연시켜 처리할 때 ex.주문한 상품을 바로 배송처리 하지 않고 일정 시간 뒤 처리 자원을 효율적으로 활용하기 위해 트래픽이 적은 시간 대에 서버 리소스를 활용 데이터 처리 배치 프로그램 사용 예시 각 서비스의 데이터를 데이터 웨어하우스에 저장할 때 ETL(Extract-Transform-Load, 추출 - 변환 - 저장) 아마존에서 연관 상품을 추천하는 것처럼 데이터 모델을 만들 때 유저 리텐션, 액티브 상..

한 번도 취업을 해야겠다는 생각을 해본 적이 없었다. 내가 취업을 할 수 있을 거라는 생각도 못했다. 대한민국에서 고졸로 살아가는 일은 만만치 않은 일이고 취업 시장에 대해서는 깔끔하게 포기했었다. 아무도 가격을 매기지 않았지만 나 스스로 이 시장에서 내 가격표는 0원이라고 생각했다. 어쨌거나 그런 생각은 프로그래밍을 공부하면서도 이어졌다. 나름대로 2020년을 치열하게 보냈지만, 내가 정말로 돈을 받고 일하는 개발자가 될 수 있을까 계속해서 의심했다. 2020년 회고 마지막 문장에 “내년 오늘은 개발자로서의 첫 회고를 쓸 수 있었으면 좋겠다”고 썼다. 작년 오늘 내가 바랐던 대로 나는 개발자로서 회고를 쓴다. 1, 2월에는 포트폴리오로 사용할 마지막 프로젝트를 진행했다. 처음으로 도메인을 달고 이게 내..

테스트 대상이 되는 오브젝트 기능만을 충실하게 수행하면서 빠르게 자주 테스트를 실행할 수 있도록 사용하는 오브젝트를 통틀어서 테스트 대역test double이라고 한다. 이를테면 회원가입 비즈니스 로직에 회원가입을 축하한다는 메일을 보내는 로직이 포함되어 있다고 가정하자. UserService class UserService( private val mailSender: MailSender ) { fun signUp(user: User) { //가입 로직 //... //회원가입 메일 전송 val mailMessage = SimpleMailMessage() mailMessage.setTo(user.email) mailMessage.setFrom("useradmin@ksug.org") mailMessage.s..

캡슐화를 위반한 설계를 구성하는 요소들이 높은 응집도와 낮은 결합도를 가질 확률은 극히 낮다. 따라서 캡슐화를 위반한 설계는 변경에 취약할 수밖에 없다. 데이터 중심 설계가 변경에 취약한 이유는 두 가지다. 너무 이른 시기에 데이터에 관해 결정하도록 강요한다. 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다. 데이터 중심 설계는 객체의 행동보다 상태에 초점을 맞춘다 데이터 중심 설계를 시작할 때 던지는 첫 번째 질문은 "이 객체가 포함해야 하는 데이터가 무엇인가?"이다. 데이터는 구현의 일부다. 데이터 주도 설계에서는 설계를 시작하는 처음부터 데이터를 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞추게 된다. 데이터 중심 설계에 익숙한 개발자는 일반적으로 데이..

'상태'와 '행동'을 하나의 객체로 모으는 이유는 객체 내부 구현을 외부로부터 감추기 위해서다. 여기서 구현이란, 나중에 변경될 가능성이 높은 어떤 것을 가리킨다. 객체지향이 강력한 이유는 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치를 제공하기 때문이다. 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고, 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다. 변경될 가능성이 높은 부분을 구현이라고 부르고, 상대적으로 안정적인 부분을 인터페이스라고 부른다. 객체 설계는 변경 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스만 의존하도록 해야 한다. 이것이 캡슐화다. 캡슐화의 정도가 응집도와 결합도에 영향..

@ParameterlizedTest 는 인자를 받아서 여러 번 테스트를 실행한다. 테스트를 진행하다 보면 거의 같고 약간만 다른 테스트 케이스를 만날 수 있다. 이를 테면 어떤 주차장에 방문 예약하는 테스트를 만든다고 가정하면 아래와 같은 예외 케이스들이 나온다. 핸드폰 번호가 없으면 BadRequestException 이 발생한다. 날짜가 잘못되면 BadRequestException 이 발생한다. 차량번호가 잘못되면 BadRequestException 비활성화된 주차장이라면 ForbbidenException 이런 예외들이 발생할 수 있다. 이걸 하나씩 테스트하면 테스트 코드가 거의 중복된다. @Test fun `방문차량 예약 시 주차장이 비활성화 상태면 ForbbidenException이 발생한다`()..

스레드를 직접 만들어서 실행할 때 보통 Tread 클래스를 서브클래싱하거나 Runnable 인터페이스를 구현한다. 자바 네트워크 프로그래밍 3장 '스레드'를 보면 일반적으로 Thread 를 서브클래싱하는 것보다 Runnable 인터페이스를 구현하는 것을 더 선호해야 할 이유는 없고, 반대의 경우도 마찬가지라고 한다. 하지만 Thread 가 하는 일이 정말로 Thread 가 아니기 때문에 객체지향의 관점에서 보자면 Runnable 을 구현하는 게 맞다고 한다. Thread 가 하는 일이 실제로 Thread 가 아니라는 말은 무슨 말인지 잘 이해 못했다. 어쨌든 Thread 를 확장하는 것보다 Runnable 을 구현해야 하는 게 맞는 것 같다. Java는 다중 상속을 지원하지 않고 Thread 가 아닌 다..

1. 동작 파라미터화 동작 파라미터화(behavior parameterization)란 아직은 어떻게 실행할지 결정하지 않은 코드 블록을 의미한다. 이 코드 블록은 나중에 프로그램에서 호출한다. 즉, 코드 블록의 실행을 나중으로 미룬다. 예를 들어 나중에 실행될 메서드 인수로 코드 블록을 전달할 수 있다. 결과적으로 코드 블록에 따라 메서드의 동작이 파라미터화된다. 예를 들어 컬렉션을 처리할 때 다음과 같은 메서드를 구현한다고 가정하자. 리스트의 모든 요소에 대해 '어떤 동작'을 수행할 수 있음 리스트 관련 작업을 끝낸 다음, '어떤 다른 동작'을 수행할 수 있음 에러가 발생하면 '정해진 어떤 다른 동작'을 수행할 수 있음 동작 파라미터화로 이처럼 다양한 기능을 수행할 수 있다. 1.1 변화하는 요구사항..

프로퍼티 선언 Declaring properties Kotlin 클래스에서 프로퍼티를 만드는 키워드는 두 가지다. var : mutable val : immutable Getter and Setter 프로퍼티 선언 문법은 다음과 같다. 코틀린은 getter/setter 기본 구현을 제공한다. var [: ] [=

의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상abstraction에 의존하며 구체concretion에는 의존하지 않는 시스템이다. 자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에 절대로 의존하지 말아야 한다. Ruby나 Python 같은 동적 타입 언어에도 이 규칙이 동일하게 적용된다. 소스 코드 의존 관계에서 구체 모듈은 참조하면 안 된다. 하지만 이들 언어의 경우 구체 모듈이 무엇인지 정의하기 다소 어렵다. 호출할 함수가 구현된 모듈이라면 참조하지 않기가 특히 어렵다. 규칙으로서 DIP는 비현실적이다. 소프트웨어 시스템이라면 구체적..

인터페이스 분리 원칙은 사진1에서 보는 다이어그램에서 그 이름이 유래했다. 사진1에 기술된 상황에서, 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을, User2는 op2만을, User3은 op3만을 사용한다. 그리고 OPS가 정적 타입언어로 작성된 클래스라고 가정하자. 이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스코드는 이 두 메서드에 의존하게 된다. 이런 의존성으로 인해 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 (사실 User1과 관련된 전혀 변경되지 않았음에도 불구하고) 컴파일한 후에 다시 배포해야 한다. 이런 문제는 그림2에서 보는 것처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. 이번에..

1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다. S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고 T 타입으 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 리스코프 치환 원칙으로 알려진 이 개념을 이해하기 위한 몇 가지 예제가 있다. 상속을 사용하도록 가이드 사진1과 같이 License라는 클래스가 있다고 가정하자. 이 클래스는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출한다. License에는 PersonalLicense와 BusinessLicense라는 두 가지 하위 타입이 존재한다. 이들 두 하위타입은 서로 다른 알고리즘을 이용해서 라이선스 비용을..

소프트웨어 개체artifact는 확장에 열려있어야 하고 변경에 닫혀 있어야 한다. 다시 말해 소프트웨어 개체의 행위는 확장 가능해야 하지만, 이때 개체를 변경해서는 안 된다. 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이것 때문이다. 소프트웨어 설계를 공부하기 시작한 지 얼마 안 된 사람들은 OCP를 클래스와 모듈을 설계할 때 도움되는 원칙이라고 안다. 하지만 아키텍처 컴포넌트 수준에서 OCP를 고려할 때 훨씬 중요한 의미를 가진다. 사고 실험 재무제표를 웹페이지로 보여주는 시스템이 있다고 생각하자. 웹 페이지에 표시되는 데이터는 스크롤할 수 있고, 음수는 빨간색으로 출력한다. 이제 이해관계자가 동일한 정보를 보고서 형태로 변환해서 흑백 프린터로 출력해 달라고 요청했다고 하자. 이 보고서에..

SRP: 단일 책임 원칙 단일 책임 원칙은 그 이름처럼, 모든 모듈이 단 하나의 일만 해야 한다는 의미가 아니다. 단 하나의 일만 해야 한다는 원칙은 함수에게 부여되는 원칙이다. 이 원칙은 커다란 함수를 작은 함수로 리팩터링하는 저수준에서 사용된다. 그렇다고 이 원칙이 SRP는 아니다. 역사적으로 SRP는 아래와 같이 정의되어 왔다. "단일 모듈은 변경 이유가 하나, 오직 하나뿐이어야 한다." 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 '변경의 이유'란 바로 이들 사용자와 이해관계자를 가리킨다. 사실 이 원칙은 아래와 같이 바꿔 말할 수도 있다. "하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다." 여기사 '사용자'와 '이해관계자'는 (..

클래스와 멤버의 접근 권한을 최소화하라 어설프게 설계도니 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모두 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서 다른 컴포넌트와 소통하고 서로의 내부 방식은 전혀 개의치 않는다. 소위 캡슐화라고 부르는 이 개념은 소프트웨어 설계의 근간이 되는 원다. 캡슐화의 장점 중 대부분은 시스템 컴포넌트를 독립적으로 만들어서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 하는 것과 연관이 있다. 컴포넌트를 병렬로 개발하는 것이 가능하므로 개발 속도 향상 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌..

파일업로드 시 input태그 FileList 동적으로 변경하기 파일업로드 기능을 구현하면서 겪은 문제. 사용자가 파일을 업로드하면 미리보기 형식으로 자신이 어떤 파일을 올렸는지 확인할 수 있어야 한다. 혹여 잘못 올린 파일이 있다면 해당 파일만 따로 삭제할 수 있어야 한다. 예시 : 이때 X버튼을 눌러서 화면에서 파일을 지워줘도 File Input Tag에는 그대로 해당 파일이 남아있다. 예시: 업로드한 파일 8개 중 7개를 지웠는데 화면에서는 삭제됐지만, Input창에는 그대로 남아있다. File Input 내부적으로 files라는 FileList를 가지고 있다. 문제는 FileList의 값을 바꿀 수 없기 때문에 삭제된 파일을 input tag에 반영할 수 없다는 것이다. files의 값을 변경하려고..

Transaction 트랜잭션은 DBMS에서 데이터를 다루는 논리적인 작업 단위다. 트랜잭션은 전부 수행되거나, 전부 수행되지 말아야 한다.(All or Nothing) 트랜잭션의 동작 원리 A계좌의 값을 데이터베이스에서 메모리 버퍼로 읽어온다. B계좌의 값을 데이터베이스에서 메모리 버퍼로 읽어온다. A계좌에서 10000원을 인출한 값을 저장. B계좌에서 10000원을 입금한 값을 저장. A계좌의 값을 메모리 버퍼에서 데이터베이스에 기록 B계좌의 값을 메모리 버퍼에서 데이터베이스에 기록 이런 작업이 있다고 했을 때, 트랜잭션의 수행 과정은 두 가지 방법으로 나눌 수 있다. 이 두 가지 방법은 커밋이 어느 위치에 들어가느냐에 따라 달라진다. A. 4번 작업을 마치고 커밋한다. B. 6번 작업을 마치고 커밋..

Flyway Flyway는 데이터베이스 마이그레이션 툴이다. 여기서 마이그레이션이란, 스키마의 버전을 관리한다고 이해할 수 있다. 왜 버전을 관리해야 할까? 수많은 이유가 있을 것이다. 개발 환경에서 스키마를 변경하고 운영환경에 적용하지 않는 실수를 막는다거나, 이전 버전으로 rollback이 필요할 수도 있다. Flyway의 작동방식 flyway는 지정된 schema history table을 찾는다. 이제 막 flyway를 적용해서 아직 스키마 히스토리 테이블이 존재하지 않는다면 새롭게 생성한다. 여기서 schema history table이란 말 그대로 flyway가 스키마의 버전을 관리하는 테이블을 말한다. 히스토리를 관리하는 테이블이 생성되면, Flyway는 마이그레이션을 위해 classpath..

Kotlin ? keyword Java에서는 객체의 메서드를 호출할 때 NP가 발생할 수 있으므로 메서드 호출 전 null체크가 필요하다. if(foo != null) foo.bar 코틀린은 안전한 null 체크를 위한 ?연산자를 제공한다. foo?.bar() //null이라면 null, null아니라면 결과 값이 출력된다. 하지만 역시 안전한 호출의 결과 타입도 null이 될 수 있으므로 유의해야 한다. 이를 테면 String.toUpperCase의 결과는 String을 반환한다. 반면 String?.toUpperCase식의 결과 타입은 String?이 된다. ?연산자를 연속해서 사용하는 것도 가능하다. class Address(val streetAddress: String, val zipCode: I..

@ControllerAdvice를 사용하여 예외처리 로직 분리하기 과제 프로젝트를 개선하면서 받은 피드백 중 하나는 @ControllerAdvice를 통해 예외 처리 로직을 분리하라는 것이었습니다. 아래 코드를 보면 예외를 잡고 발생하는 예외마다 다른 Http Status code를 반환했습니다. 예시 코드 @PostMapping fun requestApartmentToBeMoved(@RequestBody apartmentRequest: ApartmentRequest, httpSession: HttpSession) : ResponseEntity { logger.info("apartmentRequest:{}", apartmentRequest) z try { val apartment = apartmentVi..

Web이란? 웹은 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간이다. 웹의 용도는 다양하게 나눌 수 있다. Web site(google, naver, ...) User Interface(Browser) API(ex.Open API) 이 세 가지 정도가 가장 흔하게 접할 수 있는 웹의 형태다. 웹의 기반 HTTP HTML을 주고 받기 위한 규약 URI 리소스 식별자다 HTML XML을 바탕으로 한 범용 문서 포맷. 브라우저는 HTML을 사용자가 알아볼 수 있는 형태로 표현하는 도구다. REST Client, Server 클라이언트와 서버가 서로 독립적으로 분리되어야 한다. Stateless 요청에 대해 클라이언트의 상태가 서버에 저장하지 않는다. Cache 클라이언트..

'The Object-Relational Impedance Mismatch'는 객체 모델을 관계형 모델에 저장할 때 발생하는 문제, 즉 패러다임의 불일치에서 오는 문제를 말한다. 이 문제를 해결하는 게 ORM의 과제다. Persistence Persistence란 애플리케이션의 데이터가 애플리케이션 프로세스 범위를 넘어서 지속되는 것을 말한다. Java용어로 치자면 객체의 상태거 JVM범위를 넘어서 유지되는 것이라고 생각하면 된다. 객체 모델 & 관계형 모델 RDBMS는 데이터를 테이블 형식으로 표현한다. 반면 자바 같은 객체지향 모델은 객체 그래프로 데이터를 표현한다. 따라서 객체를 테이블 형식으로 저장하면 다섯 가지 불일치 문제가 발생한다. 1.세분성(Granularity) 데이터베이스의 테이블 수보..

이 글은 코드스피츠 채널에 올라온 영상을 보고 정리한 내용입니다. 프로그램 정확히 말하면 프로그램은 코드가 아니다. 실행 파일(.exe등)은 디스크에 저장되어 있는 파일일 뿐이다. 파일을 실행해서 OS가 명령과 값의 형태로 메모리에 적재한 상태가 프로그램이다. 메모리에 적재된 명령을 순차적으로 실행하고 나면 프로그램은 종료된다. 명령은 실행되기 위해 CPU로 올라온다. 보통 명령은 메모리를 이용해서 실행된다. CPU의 연산유닛은 제어 정보를 참고해서 메모리에 있는 값을 데이터유닛으로 불러온다. 연산유닛에서 어떤 연산할 때는 메모리에서 불러온 값과 명령을 사용해서 프로그램을 실행하고, 그 결과가 다시 메모리로 전파된다. 메모리에 명령과 값을 적재하는 과정을 로딩이라고 부른다. 명령(instruction)을..

역할, 책임, 협력 객체지향 패러다임의 핵심은 역할, 책임, 협력이다. 이것이 구현보다 중요하다. 다시 영화 예매 시스템을 보자. 위 표를 보면 알 수 있듯이 객체지향 원칙을 따르는 애플리케이션은 어떤 하나의 객체가 통제하지 않는다. 다양한 객체들이 자신의 일을 수행하면서 애플리케이션의 전체 기능을 완성한다. 여기서 중요한 점은 객체들이 '메세지'를 통해 상호작용한다는 것인데, 이것을'협력'이라고 한다. '책임'은 협력에 참여하기 위해 수행하는 로직이다. 객체가 가진 책임들이 모여 그 객체가 수행하는 '역할'을 구성한다. 협력 협력은 객체가 다른 객체에게 도움을 요청할 때 시작된다. 이것을 메세지 전송이라고 하는데, 객체가 협력할 때 사용하는 유일한 방법이다. 객체는 다른 객체의 내부 구현에 접근할 수 ..

02 객치지향 프로그래밍_영화 예매 시스템 만들기 요구사항 2장에서는 영화 예매 시스템을 만든다. 주의할 점은 '영화'와 '상영'을 구분해야 한다. 관객은 영화를 예매하는 것이 아니라 상영을 예매한다. 특정한 조건을 만족하는 예매자는 할인을 받을 수 있다. 하나는 할인 조건이라고 부르고 하나는 할인 정책이라고 부른다. 할인 조건 순서조건 (예를 들어) 매일 10번째로 상영되는 영화를 예매하는 사용자들에게 할인 혜택을 제공한다. 기간 조건 특정 상영 시간대의 영화(상영)를 예매하는 사용자들에게 할인혜택 제공 할인 정책 금액 할인 비율 할인 영화별로 하나의 할인 정책만 할당할 수 있다. 할인 조건은 다수의 할인 조건을 함께 지정할 수 있다. 객체지향 프로그래밍 객체지향 프로그래밍을 하려면 이 두 가지에 집중..