TIL
- 오브젝트 1장
- HTTP 완벽 가이드 1장
1. 오브젝트 1장 : 객체, 설계
1. 제대로 동작하고
2. 변경 사항이 도착했을 때 간단하게 변경 가능해야하며
3. 쉽게 읽고 이해할 수 있는
소프트웨어가 좋은 소프트웨어이다.
데이터와 로직을 분리하고, 데이터를 하나의 수동적인 존재로 둔 후 메인 로직을 따로 처리하는 "절차 지향 프로그래밍"은 변경에 유연하지 않다. 절차 지향을 구현하기 위해선 데이터 간의 연쇄적이고 강력한 의존성이 생기게 되고, 이는 하나의 기능, 데이터, 혹은 객체의 변경이 일어났을 때 의존 관계를 가진 모든 객체들 역시 변경되어야 하기 때문이다.
또한 로직을 처리하는 메인 함수가 각 데이터 객체의 내부 구조와 함수의 기능을 전부 알고 있어야 하므로 개발자가 처음 코드를 봤을 때 한 번에 이해하기 힘들다.
객체 지향 프로그래밍은 객체를 능동적인 존재로 본다. 객체는 자신과 관련된 로직은 자신 안에서 처리하고, 외부에게 필요하지 않는 기능이나 필드의 상세 내용을 공개하지 않는다. 그저 호출된 메소드를 수행하고 결과를 반환할 뿐이다. 이러한 객체지향의 특성을 캡슐화라고 한다.
캡슐화는 변경하기 쉬운 객체를 만든다. 데이터와 로직을 하나의 객체 안으로 묶고 필요한 최소한의 기능만 외부에 공개하면 그 기능을 제외한 클래스의 다른 부분을 변경하더라도 변경사항은 의존성을 가진 다른 객체에 전파되지 않는다.
그리고 로직을 내부에서 처리하면, 객체 자체의 응집도를 높일 수 있고, 객체와 관련된 일은 모두 각 객체가 처리해야하므로 책임을 분산시켜 결합도 역시 낮출 수 있다.
객체의 상세 내용을 내부로 캡슐화하여 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 만든다. 높은 응집도와 낮은 결합도를 가진 객체들이 협력하여 최소한의 의존성을 가지고 프로그램의 기능을 수행한다.
멋있는 말인듯?!
책에 나와있는 극장 예제를 콘서트로 바꿔서 캡슐화가 잘 된 예시 코드를 작성해보았다.
@Getter
public class Ticket {
private long fee;
public Ticket(long fee) {
this.fee = fee;
}
}
@Setter
public class Bag {
private Ticket ticket;
private Invitation invitation;
private Long amount;
public boolean hasInvitation() {
return invitation != null;
}
public void removeInvitation() {
this.invitation = null;
}
public void minusAmount(long fee) {
amount -= fee;
}
}
@RequiredArgsConstructor
public class Fan {
private final Bag bag;
public long buyTicket(Ticket ticket) {
bag.setTicket(ticket);
if (bag.hasInvitation()) {
bag.removeInvitation();
return 0L;
} else {
bag.minusAmount(ticket.getFee());
return ticket.getFee();
}
}
}가방(Bag)의 초대권이 있는지는 가방에서 체크하고, 초대권 여부에 따라 돈을 낼 것인지 초대권을 낼 것인지는 팬(Fan)이 결정한다.
public class TicketOffice {
private long amount;
private List<Ticket> tickets = new ArrayList<>();
public TicketOffice(long amount, Ticket ... tickets) {
this.amount = amount;
}
public Ticket getTicket() {
return tickets.remove(0);
}
public void plusAmount(long amount) {
this.amount += amount;
}
}
@RequiredArgsConstructor
public class TicketSeller {
private final TicketOffice ticketOffice;
public void sellTicketTo(Fan fan) {
ticketOffice.plusAmount(
fan.buyTicket(
ticketOffice.getTicket()));
}
}티켓 판매원 TicketSeller는 입장하고자 하는 Fan 객체에 대해 티켓을 준다. 어떤 매커니즘으로 fan이 티켓 가격을 줄 것인지, 그러니까 초대권이 있을지 없을지는 TicketSeller가 상관할 바가 아니다.
@RequiredArgsConstructor
public class Arena {
private final TicketSeller ticketSeller;
public void enter(Fan fan) {
ticketSeller.sellTicketTo(fan);
}
}그럼 이제, 클라이언트인 Fan과 직접 맞닿아있을 Arena의 enter() 메소드는 이정도로 간단해진다.
2. HTTP 완벽 가이드 1장
# HTTP : 안전한 멀티미디어 배달
사용자들이 네트워크에서 주고받고자 하는 웹 콘텐츠를 일반적으로 "리소스"라고 부른다. 리소스는 HTML/docx/jpg 등의 정적 파일일 수도 있고, 입력이나 요청에 따라 동적 컨텐츠를 생산하는 웹 어플리케이션일 수도 있다.
HTTP는 서버-클라이언트간 신뢰성있는 리소스 교환을 할 수 있게 해준다. 여기서 말하는 "신뢰성 있는"은, 원하는 상대방(클라이언트와 서버 모두)에게 송수신하고자 하는 데이터가 오류나 손실 없이 순서대로 도착하는 것을 뜻한다. 현재 통상적으로 사용되는 버전의 HTTP는 이를 보장하는 TCP 프로토콜을 사용한다.
HTTP는 웹에서 사용되는 리소스에 MIME 타입이라는 데이터 포맷 라벨을 붙인다. MIME 타입은 [주 타입/부 타입] 형태로 나타난다. HTTP 헤더의 Content=Type 항목에 다음과 같은 내용이 들어있던 것을 심심치않게 봤을 것이다. 현재 메세지에 들어있는 데이터의 포맷을 나타내는 MIME타입이었던 것이다.
text/html
text/plain
image/jpg
image/gif# URI
Uniform Resource Identifier의 약자로, 정보 리소스를 식별하거나 고유한 위치를 지정할 때 사용하는 식별자이다. URI에는 URL과 URN이 있다.
- URL : Locator. 미디어의 고유한 주소(위치)를 표시하여 리소스를 구분한다.
- URN : 위치에 영향을 받지 않는 리소스에 대해 유일무이한 이름. 인터넷의 어떤 장소에 보관되어 있어도 같은 이름을 가진다.
HTTP는 URI로 URL을 주로 사용한다.
# HTTP 트랜잭션
HTTP 요청엔 요청 메소드 정보가 있다. 서버의 리소스를 요청하는 GET, 서버에 데이터를 보내는 POST, 서버 리소스를 수정하는 PUT/PATCH, 서버 리소스를 삭제하는 DELETE, 그리고 HTTP의 헤더 부분만 요구하는 HEAD 등의 메소드가 있다.
HTTP 응답엔 응답 상태 코드가 존재한다. 2xx는 문제없이 요청에 대한 응답이 반환되었다는 의미를, 3xx는 현재 요청한 리소스가 다른 곳으로 옮겨졌으니 리다이렉팅 하라는 의미를, 4xx는 사용자의 요청이 잘못되었다는 의미를, 5xx는 서버에 문제가 발생했음을 의미한다.
오늘날의 WAS는 서버의 정적 자원 이외에도 여러가지
# 초간단 HTTP 버전
HTTP/0.9
GET 메소드만 지원, 다양한 MIME타입 미지원 등 심각한 결함을 가지고 있는 초기 프로토콜이다.
HTTP/1.0
처음으로 널리 쓰이기 시작한 프로토콜. HTTP 헤더, 추가 메소드, 멀티미디어 지원 등의 특징이 추가되었다. www가 급성장하던 시기 사용된 덜 안정된 기능의 구현체라고 볼 수 있다.
HTTP/1.0+
1.0에 기능을 추가한 버전. keep-alive, 가상 호스팅, 프록시 지원 등의 기능이 추가되었다.
HTTP/1.1
성능 최적화, 복잡한 웹 어플리케이션 기능을 지원하는 프로토콜이다. 현재 가장 널리 쓰이고 있다.
# 기타
책의 1장 마지막 부분에 간단하게 설명된 웹 구성요소들이다.
- 프록시 : 클라이언트와 서버 사이에 위치한 임시 서버. 클라이언트의 HTTP 요청을 받아 사용자 대신 서버에 요청을 보내거나, 서버와 클라이언트 사이의 필터링 역할을 하기도 한다.
학교 컴퓨터실에서 프록시 서버를 통해 학생들이 학습 외 사이트에 접속하는 것을 차단하는 - 캐시 : 클라이언트들이 자주 날리는 요청 리소스의 사본을 저장해둔 서버. 컴퓨터 공학에서 일반적으로 생각하는 캐시와 같은 기능을 한다.
- 게이트웨이 : HTTP를 다른 프로토콜로 변환시켜주는 서버. 클라이언트가 서버의 FTP에 접근하기 위한 요청을 HTTP로 날리면, 게이트웨이가 HTTP 요청을 FTP 요청으로 바꿔 다시 돌려보내준다.
REFERENCE
오브젝트 - 조영호 : 1장
HTTP 완벽 가이드 : 1장
