일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- nestjs스터디
- 스프링 공부
- JPA
- JPA스터디
- 스프링공부
- Kafka
- 스프링부트공부
- 스프링부트
- 플러터 개발
- 스프링
- 자바공부
- nestjs공부
- 기술공부
- JPA 공부
- querydsl
- 자료구조공부
- nestjs
- 기술면접공부
- DDD
- 알고리즘공부
- 플러터 공부
- 카프카
- K8S
- Flutter
- JPA예제
- 코테준비
- JPA공부
- 프로그래머스
- 코테공부
- Axon framework
- Today
- Total
DevBoi
잡다하지만 필요한 개발지식 12 본문
1. Filter와 Interceptor
filter 와 interceptor 의 실행시점은 다르다.
- filter 는 web application 에서 동작을 하고
- interceptor는 spring 의 context에 등록을 한다.
이말은 즉, filter는 dispatcher servlet 이전에 실행이되고, interceptor는 dispatcher servlet 이후에, 실행이되는 시점을 가진다.
Filter 에서 예외가 발생하면 Web Application 에서 처리를 해야한다.
<error-page>선언 이나, Filter내에서 예외를 잡아, request.getRequestDispatcher 으로 핑퐁하듯이 예외를 처리한다.
Interception 에서 예외 발생시에는, ExceptionHandler 나, ServletDispathcer 내에서 처리를 해야한다.
Filter는 Servlet 처리 전후, Interception 는, Handler 실행하기 전,후 View를 랜더링한 후 등, Servlet 내 메서드의 실행시점을 다르게 설정할수 있다.
2. JAVA 의 디자인 패턴
- 스트래티지 패턴
여러 알고리즘을 하나의 추상적인 interface를 만들어서, 서로 교환 가능하도록 하는 패턴
이런 방식으로, 예를 들면, 한개의 캐릭터가 사용하는 무기에 따라, 각 다른 메소드를 위임할수 있다.
예를 들면, 클라이언트의 strategy를 선언한 이후에, 이 클라이언트의 Strategy 의 값을 A로 set했다고 하자,
그러면, 해당 Abstract 메소드를 호출하게되면, A의 메소드가 실행이되게 위임을 해주는 방식의 디자인 패턴이다.
-장점 : 확장성, 동일한 위임받을 Stragtgy 를 하나 생성하면 추가가 가능하다 ex, StrategyD 를 생성
2. 싱글턴 패턴
- 전역 변수를 사용하지 않고, 객체를 하나만 생성하도록 하며, 생성된 객체는 어디에서든지 참조할 수 있도록 하는 패턴
ex. 관리자나 manager 에 대한 new를 한뒤에, 해당 manager를 여기저기서 쓰기!
문제점 : 다중 스레드에서, 해당 Manager에 대한 생성이되기전에, get을하여, 문제가 발생될수 있다.
해결방법 :
1.정적 변수에 인스턴스를 만들어서 바로 초기화 하는 방법
이렇게 하게되면, static 변수로 선언이 되기때문에, 객체가 생성전에, 메모리에 로딩될때 만들어져 초기화가 한번만 실행된다.
프로그램 시작~ 종료까지 없어지지않고 메모리에 계속 상주, 모든 클래스에서 이걸 사용할수 있다.
2.인스턴스를 만드는 메서드를 임계 구역으로 변경
다중 스레드 환경에서, 동시에 여러 스레드가 getPrinter메서드를 소유하는 객체에 접근하는 것을 방지한다.
공유 변수에 접근하는 부분을 임계 구역으로 변경
synchronized를 사용해서, 임계구역으로 통제한다. 이때는, 속도가 느려질수 있다.
3. 템플릿 패턴
템플릿 메서드 패턴이란, 어떤 작업을 처리하는 일부분을 서브클래스로 캡슐화,
전체일을 수행하는 구조는 바꾸지 않고, 특정 단계에서 수행하는 내역을 바꾼다.
특정 동작을 하는 하위 클래스들을 조합하여, 하나의 템플릿으로 만들고, 각각의 단계를 수행하는 서브클래스들의 조합으로, 하나의 클래스를 생성한다.
코드의 중복을 줄이고, 재사용성을 높여준다. 또한, 여러개의 클래스에서 동시 사용에 대한 확장성을 위해,
해당 템플릿을 사용하는 class들은, 상속관계를 가지게 하는것이 좋다.
4. 옵저버 패턴
한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록, 1:N 관계를 구성하는 패턴
데이터 변경이 발생했을 경우, 상대 클래스, 객체에 의존하지 않으면서, 데이터 변경을 통보할때 유리하다.
구성요소
-
Observer
- 데이터의 변경을 통보받는 인터페이스
- Observer 인터페이스의 update 메서드를 호출함으로써, 데이터변경을 통보한다.
- ConcreteSubject 의 데이터 변경을 ConcreteObserver에 통보한다.
Subject
- ConcreteObserver 객체를 관리하는 요소,
- interface를 통해서, ConcreteObserver를 관리하기때문에, 변화에 독립적일수 있다.
ConcreteSubject
- 변경 관리 대상이 되는 데이터가 있는 클래스
- 데이터 변경을 위한 메서드인 setState가있다.
- setState 메서드에서는 자신의 데이터인, subjectState를 변경하고
Subject의 notifyObjeservers메서드를 호출, 객체. 변경을 통보한다.
ConcreteObserver
- ConcreteSubject의 변경을 통보받는, 클래스,
- Observer 인터페이스의 update메서드를 구현함으로써 변경을 통보받는다.
- 변경된 데이터는 getState메서드 호출, 변경조회를 한다.
커맨드 패턴
- 실행될 기능을 캡슐화 하여, 주어진 여러기능을 실행할수 있는, 재사용성이 높은 클래스를 설계
한가지 인터페이스를 두고, 이를 구현하는 구현체들에서 해당 구현체를 사용,
여러 기능을 가진 Command들을 사용하고싶을때에는, 각각 따로 impl을 해서,
특정, 객체에 set으로 생성자를 세팅해주면, 된다.
이런식으로 설계를 하게되면, 2가지에 대한 command를 왔다갔다 하면서, 변경 및 사용이 가능하게 된다.
7.Angular js, Vue 차이
이건 사실 그냥 프론트에대한 지식을 이제 조금 더 쌓고 싶어서, 넣은것이다.
한번 공부해보자.
프론트쪽 자바스크립트에 대한 프레임워크, react,vue,angular에 대해서 공부해보자.
1. Angular
Angular는 app개발에 필요한 모든것을 제공, 러닝커브가 심하다,
TypeScript, MVC 외에도, Angular 내부의 동작 메커니즘, 제공하는 기술들을 알아야한다.
TypeScript 기반이고, 체계적이고 잘 정리되어있는 문서와 튜토리얼들이 있다.
스트림을 통한 비동기처리 방식 지원, 빠르고, 효율적으로 랜더링 되게 설계되어있다.
양방향 바인딩 방식 제공, 구글에서 개발 운영 중이다.
컴포넌트를 재사용한다.
즉!
(기능이 풍부, 규모가 큰 애플리케이션 개발할때, 믿을수있고 확장 가능한 프레임워크가 필요할때)
채팅앱이나 메시징 앱과 같은 실시간 애플리케이션을 개발할때,
장기 프로젝트이며, 투자규모도 상당한 네이티브앱이나 하이브리드 앱 웹앱을 개발할때)
2.Vue
Vue는 Angular나 React보다 상대적으로 배우기 쉽다.
Componenet와 같은 기능들을 채택하여, 사용 하기 때문에, 다른 프레임워크로 부터 Vue 이동이 쉽다.
또한, 가볍다.
Single file Component 를 지원한다. html,css script 가 하나로 묶여서 컴포넌트 단위로 직관적인 구성이 가능하다.
유지보수에 큰 도움이된다.
뷰는 typescript를 사용하지 않고, 템플릿을 사용해 뷰와 모델을 연결한다.
시장 진입 단계에서 필요한 프레임워크를 선택할때,
작고 가벼운 애플리케이션 개발할때
기업단위가 아닐때 사용한다.
뭔가 두가지에대한 차이를 이렇게 공부를 하는 것보다. 그냥 하나씩 파보는게 좋을것같다.
파보기 전에, 맛보기로 정리해본걸로치자
(앵귤러 부터해봐야지 ㅋ)
'[Computer Science]' 카테고리의 다른 글
잡다하지만 필요한 개발지식 14 (0) | 2021.08.12 |
---|---|
잡다하지만 필요한 개발지식 13 (0) | 2021.08.11 |
잡다하지만 필요한 개발지식 11 (0) | 2021.07.30 |
필요한 잡다한 개발지식 10 (0) | 2021.07.29 |
잡다한 기술 지식 10 (0) | 2021.07.28 |