본문으로 건너뛰기

stack — 최근 글

최근
BlogBook Review

컴퓨터 시스템 딥 다이브 - 책 소개

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. 작년에 많은 일들이 있어 고사 했음에도 불구하고 올해 다시 좋은 기회로 한빛미디어의 좋은 책들을 소개할 수 있게 되었다. 양질의 번역서와 국내 좋은 저자들의 IT 지식을 접할 수 있게 도와주시는 한빛미디어에게 감사의 말씀 먼저 드린다. 원제 : Dive Into Systems: A Gentle Introduction to Computer Systems 저자 : Suzanne J. Matthews, Tia Newhall, Kevin C. Webb 출간 : N
FundamentalOOP

오브젝트; 자율적인 객체

객체를 설계할 때 "이 객체가 어떤 데이터를 포함해야 하는가?" 라는 질문은 다음과 같은 두개의 개별적인 질문으로 분리해야 한다. 이 객체가 어떤 데이터를 포함해야 하는가? 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가? DiscountCondition (할인조건) 클래스에 대한 개선 Movie 클래스에 대한 개선 Screening 클래스에 대한 개선 ReservationAgency 클래스에 대한 개선 DiscountCondition 자신의 데이터를 이용해 할인 가능 여부를 스스로 판단하게 되었지만, isDiscoun
EngineeringLinux

암호화 된 사설 SSL 인증서 만들기

그냥 RSA 개인키를 만든다. 그 RSA 개인키를 encryption 한다. 서티 사이닝을 한다 encrypted 된 RSA 개인키로 공개키를 만든다. pem 키 RSA 개인키 생성 RSA 개인키 암호화 아래 두가지 중 택 1 3DES 방식 AES의 경우. (마찬가지) 서티 사이닝 이때 셀프 정보 들어감 암호화된 개인키로 공개키 만들기 이때 또 비밀번호 물어봄 pem 키 생성 까보면 encrypted 랑 아닌거랑 시그니처 차이가 있음 최종 아래와 같은 키 목록 사용 시 복사하는 키 pem 키 RSA 키 (암호화 안된 개인키)
FundamentalOOP

오브젝트; 데이터 중심 설계의 문제

객체지향 설계의 핵심 협력 : 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용 책임 : 객체가 다른 객체와 협력하기 위해 수행하는 행동 역할 : 대체 가능한 책임의 집합 객체지향 설계 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동 객체지향의 설계의 핵심은 책임이다. 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다. 설계 설계는 변경을 위해 존재한다. 훌륭한 설계한 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다. 변경
Java EcoSpring Framework

토비 스프링; 오브젝트와 의존관계 (2)

지난 글에서 DAO 오브젝트 팩토리를 스프링의 Application Context로 변환하는 과정까지 했다. 이 과정에서 @Configuration이라는 어노테이션으로 Application Context가 빈을 만들 수 있게 했다. 그런데 오브젝트 팩토리로 만든 DAO는 여러개 생성이 가능하고 그렇게 되면 동일하지 않게된다. Application Context로 만든 DAO는 동일하다. IoC컨테이너인 Application Context는 Singleton Registry다. 스프링은 빈을 생성할때 기본적으로 Singleton으로
EngineeringLinux

OpenSSL을 컴파일을 통해 버전 업그레이드 하기

패키지 관리자를 통한 바이너리 업데이트가 아니면서 현행 중 가장 stable 버전으로 업데이트 한다. 기존 사용중인 라이브러리를 건드리지 않는다. 시스템에 등록된 OpenSSL을 현행 stable 대체한다. Rocky Linux 또는 RHEL 기반 리눅스 인터넷 연결 root 환경 시스템에 설치된 OpenSSL 버전이 낮으면 높은 버전의 OpenSSL이 필요한 타켓 어플리케이션도 컴파일 해야한다. 그리고 이 경우 컴파일 옵션에서 반드시 libssl의 경로를 별도 지정해야 하는 경우가 있다. 이 경우에는 아래에서 진행되는 심볼릭 링크
FundamentalOOP

오브젝트; 역할, 책임, 협력

객체지향 패러다임 관점의 핵심 역할 Role 책임 Responsibility 협력 Collaboration 협력 : 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용 책임 : 객체가 협력에 참여하기 위해 수행하는 로직 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 구성 객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협락하는 사회적인 존재다. 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 메
FundamentalOOP

오브젝트; 객체지향 프로그래밍

이번 장은 이 책을 읽으면서 이해하게 될 다양한 주제들을 얕은 수준으로 가볍게 살펴보는 것 책의 예제 소개를 위한 요구사항 할인 조건 순서 조건 : 상영 순번으로 할인 여부 결정 기간 조건 : 영화 사영시작 시간으로 할인 여부 결정 할인 정책 : 할인 할 요금 결정 금액 할인 정책 : 정액 할인 비율 할인 정책 : 비율 할인 객체지향 패러다임으로 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 어떤 클래스가 필요한지 고민 하기 전에 어떤 객체들이 필요한지 고민하라 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추