private void print(boolean startFront) {
StringBuilder sb = new StringBuilder().append('[');
if (deque.size() > 0) {
if (startFront) {
sb.append(deque.pollFirst());
while (!deque.isEmpty()) {
sb.append(',').append(deque.pollFirst());
}
} else {
sb.append(deque.pollLast());
while (!deque.isEmpty()) {
sb.append(',').append(deque.pollLast());
}
}
}
System.out.println(sb.append(']'));
}이 쪽이 무조건 낫다
sb.setCharAt(sb.length() - 1, ']');같은 식으로 작성시 꼬일 가능성이 너무너무 커짐
왜 터진지 디버깅도 불가능했음
메멘토 패턴
현재 스냅샷을 만드는 것
중첩 클래스를 만들고, 그 중첩클래스에서 필드에 액세스 해서 바깥 클래스에 있는 데이터를 다 가지고 저장하는 방식이 가능함
중첩 클래스가 없다면 위같은 방식도 가능함
이때 메멘토의 구성을 public으로 열어야 함
이런 방식으로 캡슐화를 시킬 수도 있음
메멘토는 롤백이나 트랜잭션에서 사용됨
해당 객체에 getter, setter를 두기 싫은 경우라면 좋음
캡슐화를 지키고 스냅샷을 저장할 수 있음
오리지네이터의 코드를 단순화 할 수 있음
램이 무거워짐
오리지네이터의 수명 주기를 잘 파악해서 제거해줘야됨
동적 프로그래밍 언어에서 메멘토의 상태가 유지된다고 보장이 안 될 수 있음
실행 취소 구현시 메멘토+ 커맨드가 가능함
반복자를 사용해 롤백 가능
프로토타입이 메멘토의 대체 가능한 부분이 되기도 함
복잡도가 너무 올라가긴 하는데, 구현을 할 때 프로토타입을 이용해서 이를 저장한다면 그 자체만으로도 되게 괜찮을 것 같은 느낌이다
옵저버
pub, sub 구조로 연결됨
구독자가 같은 인터페이스를 가지고, 무조건 인터페이스만으로 통신하는 것이 되게 깔끔함
옵저버가 publisher의 컨텍스트를 어느정도 알 수밖에 없음
addEventListener 과 되게 비슷함
버튼에 구독을 시키고, 누를 때마다 버튼에 등록된 함수를 만드는 것
연쇄 변경이 필요할 때 사용
특정 순간 관찰이 필요할 때 사용
OCP 가 지켜짐
런타임에 객체간의 관계 설정이 가능함
구독자들이 무작위로 알림을 받음
중재자를 옵저버로 하기도 함
상태
class Document is
field state: string
// …
method publish() is
switch (state)
"draft":
state = "moderation"
break
"moderation":
if (currentUser.role == "admin")
state = "published"
break
"published":
// Do nothing.
break
// …익숙한 구조...
그래도 저 코드를 하나의 객체로 묶어버리면 조금 나아진다
저렇게 했을 때 다른 상태로 전이가 가능함.
전략은 다른 상태로 전이가 불가능하지만 상태는 그래도 전이가 가능함
상태 패턴은 현재 상태에 따라 다르게 행동해야 되는 경우가 많은 경우 사용
거대한 조건문들로 오염된 경우 사용
유사한 상태들의 중복코드,조건문 기반 전이가 많은 경우 사용
단일책임
OCP
거대 조건문을 단순화 함
몇 가지 상태만 있는 경우 상태패턴은 과도할 수 잇음
브릿지, 상태, 전략, 어댑터는 모두 유사한 구조로 되어있음
이 부분은 작업을 위임하는 합성을 기반으로 만들어져있음
package refactoring_guru.state.example.states;
import refactoring_guru.state.example.ui.Player;
public class PlayingState extends State {
PlayingState(Player player) {
super(player);
}
@Override
public String onLock() {
player.changeState(new LockedState(player));
player.setCurrentTrackAfterStop();
return "Stop playing";
}
@Override
public String onPlay() {
player.changeState(new ReadyState(player));
return "Paused...";
}
@Override
public String onNext() {
return player.nextTrack();
}
@Override
public String onPrevious() {
return player.previousTrack();
}
}이 부분이 핵심 인듯?
LockedState 로 변경하는 부분이 객체 안에 들어가있음
전략패턴
전략 패턴은 알고리즘들의 패밀리를 정의하고, 각 패밀리를 별도의 클래스에 넣은 후 그들의 객체들을 상호교환할 수 있도록 하는 행동 디자인 패턴입니다.
객체 내에서 알고리즘을 바꾸고 싶은 경우에 사용
일부 행동을 수행하는 방식만이 다를 경우 사용
중요하지 않은 알고리즘 생성을 고립시킴
알고리즘 사이를 변경하는 거대한 조건문이 있는 경우 사용
런타임 내에 알고리즘 변경이 가능함
알고리즘 구현의 세부 사항과 사용 코드를 분리 가능
상속을 합성으로 대체 가능
개방 폐쇄가 가능함
알고리즘이 적다면 너무 복잡해짐
전략간의 차이점을 알 수 있어야 함
익명함수로 거의 대부분이 구현 가능하다는 점을 알아야 함
브리지, 상태, 전략 패턴은 매우 유사한 구조로 되어 있으며, 어댑터 패턴도 이들과 어느 정도 유사한 구조로 되어 있습니다. 위 모든 패턴은 다른 객체에 작업을 위임하는 합성을 기반으로 합니다. 하지만 이 패턴들은 모두 다른 문제들을 해결합니다. 패턴은 특정 방식으로 코드의 구조를 짜는 레시피에 불과하지 않습니다. 왜냐하면 패턴은 해결하는 문제를 다른 개발자들에게 전달할 수도 있기 때문입니다.
커맨드와 전략 패턴은 비슷해 보일 수 있습니다. 왜냐하면 둘 다 어떤 작업으로 객체를 매개변수화하는 데 사용할 수 있기 때문입니다. 그러나 이 둘의 의도는 매우 다릅니다.
당신은 커맨드를 사용하여 모든 작업을 객체로 변환할 수 있습니다. 작업의 매개변수들은 해당 객체의 필드들이 됩니다. 이 변환은 작업의 실행을 연기하고, 해당 작업을 대기열에 넣고, 커맨드들의 기록을 저장한 후 해당 커맨드들을 원격 서비스에 보내는 등의 작업을 가능하게 합니다.
반면에 전략 패턴은 일반적으로 같은 작업을 수행하는 다양한 방법을 설명하므로 단일 콘텍스트 클래스 내에서 이러한 알고리즘들을 교환할 수 있도록 합니다.
데코레이터는 객체의 피부를 변경할 수 있고 전략 패턴은 객체의 내장을 변경할 수 있다고 비유할 수 있습니다.
템플릿 메서드는 상속을 기반으로 합니다. 이 메서드는 자식 클래스들에서 알고리즘의 부분들을 확장하여 변경할 수 있도록 합니다. 전략 패턴은 합성을 기반으로 합니다: 당신은 객체 행동의 일부분들을 이러한 행동에 해당하는 다양한 전략들을 제공하여 변경할 수 있습니다. 템플릿 메서드는 클래스 수준에서 작동하므로 정적입니다. 전략 패턴은은 객체 수준에서 작동하므로 런타임에 행동들을 전환할 수 있도록 합니다.
상태는 전략의 확장으로 간주할 수 있습니다. 두 패턴 모두 합성을 기반으로 합니다. 그들은 어떤 작업을 도우미 객체들에 전달하여 콘텍스트의 행동을 바꿉니다. 전략 패턴은 이러한 객체들을 완전히 독립적으로 만들어 서로를 인식하지 못하도록 만듭니다. 그러나 상태는 구상 상태들 사이의 의존 관계들을 제한하지 않으므로 그들이 콘텍스트의 상태를 마음대로 변경할 수 있도록 합니다.
템플릿 메서드
2가지 유형의 단계
1. 기초 유형의 단계
2. 선택적 단계(필수 오버라이딩)
3. 훅(비어있어도 됨)
클라이언트가 대규모 알고리즘중 일부만을 마음대로 변경할 수 있음
중복 코드를 부모에게 가져올 수 있음
완벽한 자유는 없음
디폴트 단계 구현을 억제해 LSP를 위반할 수 있음
단계가 많아지면 유지가 어려움
팩토리는 템플릿의 특수화
템플릿은 클래스 단위이기에 정적, 전략은 동적
비지터
비지터(방문자) 패턴은 알고리즘들을 그들이 작동하는 객체들로부터 분리할 수 있도록 하는 행동 디자인 패턴입니다.
visitor는 복잡한 자료구조를 원하는 방법으로 순회하길 위해서 하는 방법임
보조행동들의 비즈니스 로직을 정의할 때 사용
일부 클래스에서만 사용되는 경우 추가할 수 있음
개방폐쇄, 단일 책임, 순회도 쉽고
단점은 뭔가 하나가 추가될 때마다 다 업데이트 해야된다는 점이 큼
비공개 필드같은경우 접근이 힘들 수 있음
비지터 패턴은 커맨드 패턴의 강력한 버전으로 취급할 수 있습니다. 비지터 패턴의 객체들은 다른 클래스들의 다양한 객체에 대한 작업을 실행할 수 있습니다.
당신은 비지터 패턴을 사용하여 복합체 패턴 트리 전체를 대상으로 작업을 수행할 수 있습니다.
비지터 패턴과 반복자 패턴을 함께 사용해 복잡한 데이터 구조를 순회하여 해당 구조의 요소들의 클래스들이 모두 다르더라도 이러한 요소들에 대해 어떤 작업을 실행할 수 있습니다.
https://refactoring.guru/ko/design-patterns/visitor
잘 봤습니다
VPC
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html
사용자가 정의한 가상 네트워크로 AWS리소스 시작 가능
네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 데이터 센터에서 운영하는 기존 네트워크와 유사하다
VPC : 가상 데이터센터에서 운영하는 기존 네트워크와 유사함. VPC 이후에 서브넷이 가능함
서브넷 : VPC의 IP 주소 범위 서브넷은 단일 가용 영역에 상주해야 함
서브넷 이후에는 VPC 에 AWS 리소스를 배포할 수 있음
IP 주소 지정 : VPC와 서브넷에 IPv4와 IPv6 주소를 할당 가능. 퍼블릭 IPv4, IPv6 주소를 할당할 수 있습니다
GUA 주소https://m.blog.naver.com/luexr/222055230220
vpc 리소스에 할당할 수 있다
라우팅 : 라우팅 테이블을 사용하여 서브넷 또는 게이트웨이의 트래픽이 전달되는 위치를 결정합니다
게이트웨이는 vpc를 다른 네트워크에 연결
인터넷 게이트웨이를 사용해 vpc를 인터넷에 연결. vpc엔드포인트를 사용해 인터넷 게이트웨이 또는 nat 장치를 사용하지 않고 aws 서비스에 비공개로 연결
피어링 연결 : vpc 피어링 연결을 사용하여 두 vpc 리소스간 트래픽 라우팅
트래픽 미러링 : 네트워크 트래픽 복사. 심증 패킷 검사를 위해 보안 및 모니터링 어플라이언스로 전송
Transit Gateway
중앙 허브 역할을 하는 전송 게이투에이를 사용하여 VPC, VPN 연결 및 AWS Direct Connect 연결 간에 트래픽을 라우팅합니다
VPC 흐름 로그
흐름 로그는 VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡쳐한다
VPN 연결 : AWS Virtual Private Network(AWS VPN) 을 사용해서 온프레미스 네트워크에 VPC를 연결한다
아마존 VPC 시작하기
AWS 계정은 각 AWS 리전에 기본 VPC가 포함됨. 기본 VPC 는 EC2 인스턴스 바로 연결 할 수 있도록 구성되어 있음
필요한 서브넷, IP 주소, 게이트웨이, 라우팅으로 추가 VPC를 생성하도록 할 수 있음
AWS Management Console VPC 에 엑세스시 가능한 웹 인터페이스
AWS CommandLine Interface(AWS CLI) VPC를 포함한 다양한 명령어를 제공함
AWS SDK 언어별 API, 서명 계산, 요청 재시도 처리 및 오류처리 같은 여러가지 연결 세부 정보
쿼리 API HTTPs 요청을 사용하여 호출하는 하위 수준 API 작업 제공
vpc 에 직접적인 엑세스 하는 방법. 애플리케이션에서 요청에 서명할 해시 서명 및 오류 처리 같은 것들을 직접 처리해야함.
AWS VPC Actions 를 참조해야됨
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/how-it-works.html
VPC 작동 방식
VPC 는 다른 가상 네트워크와 논리적으로 분리되어있음
VPC IP 주소 범위 지정, 서브넷과 게이트 웨이 추가, 보안그룹 연결
서브넷은 VPC IP 주소 범위
리소스를 서브넷으로 실행 가능?
서브넷을 인터넷, 다른 vpc, 자체 데이터센터에 연결해 라우팅 테이블을 사용해 서브넷에서 서브넷으로 트래픽 라우팅 가능
기본 VPC일 때 예를 들어 리전의 각 가용 영역에 기본 서브넷, 연결된 인터넷 게이트웨이, 모든 트래픽을 인터넷 게이트웨이로 보내는 기본 라우팅 테이블의 경로, 퍼블릭 IP 주소가 있는 인스턴스에 퍼블릭 DNS 호스트네임을 자동으로 할당하고 Amazon 제공 DNS 서버를 통해 DNS 확인을 활성화하는 DNS 설정이 있습니다
기본 서브넷에서 시작된 인스턴스는 자동 인터넷 엑세스 가능
리전에 VPC가 있고, 서브넷 미지정시 기본 서브넷 중 하나가 됨
자체 VPC 생성 후 필요에 따라 구성 가능. 기본이 아닌 VPC
기본이 아닌 VPC에서 만든 서브넷이나, 기본 VPC에 만든 추가 서브넷은 기본이 아닌 서브넷
IP 주소가 있으면 VPC 내의 리소스가 서로 통신하고, 인터넷과 다른 리소스와 통신 가능
CIDR 표기법을 통해 만듦
10.0.0.0/16
2001:db8:1234:1a00::/56
같은 것들이 가능함
VPC 생성시, VPC에 IPv4 CIDR 블록, IPv6 CIDR 중 하나 이상을 선택해야 됨 둘다 선택시(듀얼 스택)
프라이빗 IPv4 주소는 인터넷 접속 불가능
IPv6 주소는 전역적으로 고유, 프라이빗으로 유지되거나 인터넷으로 접속하도록 구성할 수 있음
이때 IPv4, IPv6은 서로 독립적.
별도의 경로와 보안 그룹 규칙을 추가해야 함
IPv4, IPv6 차이가 있음
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing
링크에서 확인 가능
탄력적 IP 주소나, NAT 게이트웨이, VPC 엔드포인트 같은 경우가 IPv4에서만 됨.
프라이빗 IPv4 주소는 인터넷 접속 불가, VPC에서 인스턴스를 시작할 경우, 서브넷의 IPv4 주소 범위에 속한 주 프라이빗 IP 주소는 인스턴스의 주 네트워크 인터페이스(eth0)에 할당됩니다.
서브넷 범위 안에 private ipv4주소가 나옴
vpc 내부 dns네임이 할당됨
호스트 이름은 ip기반, 리소스 기반 2가지가 가능함
주 private ip가 없다면 서브넷 범위 내에서
보조 프라이빗 ip 주소인 추가 프라이빗 ip주소를 vpc 에서 실행중인 인스턴스에 할당 가능. 보조는 한 네트워크에서 다른 네트워크 인스턴스로 재할당 가능
재시작, 중지될 때 프라이빗 ip주소가 네트워크 인터페이스와 연동됨, 종료시 연동 해제
프라이빗 ip 주소, IPv4 CIDR 범위 내 IP 주소
대부분의 VPC IP 주소 범위는 RFC 프라이빗 IP 주소에 가지만, 공개적으로 라우팅 가능한 CIDR 사용 가능
VPC 주소 범위 상관 없이 공개적 라우팅 가능한 CIDR 블록 포함해 VPC의 CIDR 블록에서 인터넷으로 직접 엑세스는 지원하지 않는다.
인터넷 게이트에이, 가상 프라이빗 게이트웨이, AWS Site to Site VPN, AWS DIrect Connect 같은 것들을 통해서 인터넷 엑세스를 만들어야 함
퍼블릭 IPv4 주소
이 속성이 활성화 된 서브넷에서 인스턴스 시작시 IP 주소는 인스턴스에 대해 생성된 주 네트워크에
ec2
elastic computer cloud
c가2개
on-demand 같은 단기 하는 것들
spot
빅데이터나, 보조 적인 뭔가를 씀
빅데이터 처리가 싸면 좋음
전용 호스트라는 것이 있다
실제로 서버를 가져다 주는 것
기업용
태그
Name : 이름
resource_id : 어떤 프로젝트
resource_position : dev,prod 이렇게 3가지가 있으면 좋음
ebs based : 반 영구적, snapshot 가능, 인스턴스 업그레이드, stop이 가능
instance storage: 휘발성, 바름. stop 불가
