따봉도치야 고마워

팩토리 패턴 팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 함. 클래스의 인스턴스를 만드는 일을 서브 클래스에 맡김 모든 팩토리 패턴에서는 객체 생성을 캡슐화한다. 팩토리 메소드 패턴에서는 서브클래스에서 어떤 클래스를 만들지 결정하게 함으로 객체 생성을 캡슐화한다. Creator 클래스 : 생산자 클래스, 팩토리 메소드를 정의/구현한다. ex) PizzaStore(추상), NYPizzaStore(구상) Product 클래스 : 팩토리 메소드에서 생산하는 제품 추상 팩토리 패턴에서는 인터페이스를 이용해 서로 연관/의존하는 객체를 구상 클래스를 지정하지 않고도 생성할 수 있음 클라이언트에서 추상 인터페이스를 통해 일련의 제품을..

데코레이터 패턴 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해 기능을 유연하게 확장하는 방법을 제공한다. 데코레이터의 수퍼클래스 == 자신이 장식하고 있는 객체의 수퍼클래스 -> 원래 객체가 들어갈 자리에 데코레이터 객체를 넣어도 상관 없음 한 객체를 여러개의 데코레이터로 감쌀 수 있음 데코레이터는 자신이 장식하는 객체에게 어떤 행동을 위임하는 것 외에 원하는 추가 작업을 수행 가능 객체는 언제든 감쌀 수 있기 때문에 실행중에 마음대로 적용 가능 장단점? 장점 : 하나의 객체에 추가해야될 기능들이 다양하고 일정하지 않을 때 효율적 단점 : 데코레이터 클래스가 너무 많아져 코드가 복잡해질 수도 스타버즈 예제 - 상속을 사용하면 서브 클래스가 매우 많아지거나, 일부 서..

옵저버 패턴(Observer Pattern) 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고, 자동으로 내용이 갱신되는 방식 일대다 의존성을 정의 Subject와 Observer 인터페이스를 각각 구현 - WeatherData(Subject), Displays(Observer) Subject엔 옵저버 등록, 삭제, 알림 메소드 필요 옵저버는 update() 메소드 구현. - update(온,습,압) + 옵저버한테 연락이 가는 순서에 의존해서 코딩하면 안 됨. 자바 내장 옵저버 패턴 - 푸시 방식뿐만 아니라 풀 방식으로 갱신 가능 - Subject가 아니라 Observable 클래스 상속받아 사용 - WeatherData(extends Observable) - 옵저버 객체에선 위 ..

디자인 패턴 소개 모든 패턴은 '시스템의 일부를 다른 부분과 독립적으로 변화시킬 수 있는' 방법을 제공하기 위한 것 디자인 원칙 애플리케이션에서 달라지는 부분을 찾고, 달라지지 않는 부분으로부터 분리한다. 구현이 아닌 인터페이스에 맞춰 프로그래밍한다. //여기서 인터페이스는 중의적 의미로 '상위 형식'을 의미함 상속보다는 구성을 활용한다. 스트래티지 패턴(Strategy Pattern) : SimUDuck 예제 - fly(), quack() 메소드를 슈퍼 클래스에 정의 시 : 해당 기능이 없어야 하는 서브 클래스는 매번 재정의 해줘야 함 - flyable, quackable 인터페이스를 서브 클래스에서 구현하도록 하면 : 코드 중복 발생 *패턴 적용 - 슈퍼 클래스에선 FlyBehavior, QuackB..

버블링과 캡쳐링, 이벤트 전파? 중첩된 요소에서 이벤트가 발생할 때, HTML DOM API 의 이벤트 전파(Event Propagation) 순서 차이 1) 버블링 : 이벤트 발생 요소 -> 부모 2) 캡쳐링 : 부모 -> 이벤트 발생 요소 ex) FORM > DIV > P 순의 중첩된 형태일 때, P 태그 선택 시 버블링 : P -> DIV -> FORM -> ... -> DOCUMENT 순으로 각 객체의 이벤트 핸들러 동작 캡쳐링 : 위와 반대 - 캡쳐링은 거의 사용하지 않는다. - 사용하고 싶다면 addEventListener 의 3번째 인자인 useCapture 를 true로 설정해주면 된다. 참고 : ko.javascript.info/bubbling-and-capturing

foreach - 배열 원소들을 반복하며 특정 액션 수행 - 값을 리턴하지 않아 단순 반복에 쓰임. (내부에서 배열을 만드는 것도 되지만, 그럴 땐 보통 map 사용) map -배열 원소들을 반복하며 값을 변경해 리턴. 즉 새로운 배열 생성 -보통 배열 전체 값을 변경할 때 사용 filter -배열 원소들을 반복하며 조건에 true면 원소를 남기고, flase면 삭제. 새로운 배열 생성 -배열 값 중 의미 없는 값 버릴 때 사용. 말 그대로 필터링 + 빈 배열 요소를 반환하지 않음 reduce -배열 원소들을 반복하며 값을 조합해 하나의 결과 값 리턴 ex.sum, avg some - 배열 원소 중 하나라도 조건을 만족하면 true, 아니면 false 반환 - 배열에서 특정 값 검사 or 특정상황에서 멈..

물론 둘 다 짧은 기간밖에 경험해보지 못했고, 디테일한 구조에 대해선 잘 모른다. 하지만 배우면서 느꼈던 것에 대해 정리해보고자 한당. 1. 데이터 처리 구조 - MMORPG의 경우 '접속만 되어있어도' 지속적인 데이터의 업데이트가 필요했기 때문에 특정 이벤트 발생 시 업데이트되는 데이터가 굉장히 많았고 빈도도 높았음. - 특히 특정 컨텐츠 이용 시, 작은 작업 단위 하나하나에도 데이터의 동기화가 필요했음 - 스포츠 게임의 경우, 게임 플레이 중이 아니면 데이터의 업데이트가 비교적 덜 중요하게 느껴짐 - 데이터 처리 구조도 매번 새 데이터를 가져오는게 아니라 거의 한 번에 모든 데이터를 가져와 캐싱 후 필요할 때 사용하는 느낌? - 물론 여기도 특정 이벤트 발생 시, 업데이트가 일어나겠지만 MMORPG의..

IPv6 IPv4의 문제 - 1981년부터 IPv4가 사용되었고, 점차 주소가 부족하게 됨 - IPv4는 2^32 만큼의 주소 사용 가능한데 (43억개) 실질 적으로 쓸 수 있는건 약 2억 5천만개 정도 - 또한 복잡한 헤더, 보안 기능 등등 여러가지 단점들이 있었음 -> 주소 부족을 해결하기 위해 NAT, 서브네팅, DHCP, CIDR(Classless Inter Domain Routing) 등 다양한 솔루션을 내놓았지만, 점점 더 복잡해지는 구성과, End to End 지원이라는 문제에 부딪혔음 IPv6의 탄생 - 1990년에 IETF에선 94년도쯤 클래스 B주소가 고갈될 것이라고 예상 - 1991년 11월 IETF는 산타페에서 열린 미팅에서 이 문제를 해결하기 위해 ROAD(Routing and A..