head and first :factory Pattern

1. OOP의 5요소(SOLID)

•  단일 책임의 원칙(Single Resposiblility principle )
• 객체는 단 하나의 책임만 가지고 있어야한다.
• 클래스의 단일책임
• 리스코브 치환의 원칙
• 특정 클래스의 속성의 변경없이 , 기반클래스의(부모클래스) 객체가 서브클래스(자식클래스)의 객체로 변환될 수 있어야한다. 
• 인터페이스 분리의 원칙(Interface segregation principle)
• 어떤 클래스가 다른클래스에 종속될때 최소한의 인터페이스로 사용하여야한다
• 인터페이스의 단일책임
• 클래스 상속관계의 인터페이스 분리
• 객체 기능의 인터페이스 분리
• 의존 역전의 원칙(Dependancy Inversion Principle)
• 하위 모듈의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는 의미역전 실질적으로 그렇지 않지만, 느슨한 결합을 일컫는 말  
• 개방폐쇄의 원칙 (OCP)
• 객체는 개방에는 열려있고 수정에는 닫혀있어야한다.

2. 추상 팩토리 패턴 

• 팩토리: 객체생성을 담당하는 추상 클래스   
• 관련된 객체 생성의 인터페이스를 제공하되, 생성되는 객체의 구체적인 클래스는 알 알 필요가 없다는 것이다.  

피자스토어에서 여러개의 피자를 구성하는 것을 예로 들어 설명한다.  [그림1]에서 볼 수 있듯이 피자가게에서는 다양한 피자(치즈피자 ,페퍼로니 피자)등을 만들수 있다.  

• NaivePizzaStore 은 NaivePizza를 사용하게 되며, 전적으로 NaivePizza가 상속하는 자시클래스생성에 의존적이게 된다. 의존성은 NaivePizzaStore의 확장성과 수정을 요구하게 되는 상황에 이르게 된다. 

[그림1]  

[그림1]의 의존성을 낮추기 위해서는 , NaviePizzaStore에 하나의 클래스를 연관시켜 피자가게와 피자객체의 의존성을 낮출 수 있다. [그림2]에서 그 의존성 낮춘예로 수정할 수 있다.

• 피자의 객체의 생성을 전적으로 simpleFactory에서 담당하게 만듦으로 pizzaStore의 클래스를 수정할 필요가 없어지며, simple에서 다양한 피자객체와 연관시킬수 있는 확장력을 얻었다. 
• 하지만 피자스토어가 하나가 아니라면 두개의 다른 영역을 가지게 되는 피자가게가 하나 더 생기게 된다면, simple Factory가 복잡하게 구성되어진다.  

[그림2]

[그림2]의 다수의 피자가게에 피자 객체 확장 문제점을 [그림3]에서 해결한것이다. 피자가게가 피자객체를 사용한다는 의존관계를 역의존관계로 느슨하게 결합하도록 제공한다.

• 왜 심플 팩토리는 안되는가?
• 다수의 피자가게가 심플팩토리에서 확인과정을 거쳐야 하며(어떤 피자가게인지, 어떤 피자를 생성해 줘야 하는지) 생성될 수 있는 객첵조건을 다 만들어 줘야 하기 때문에,  심플팩토리는 무거워지며, 수정할 부분이 많아지게 된다. 
• 심플팩토리를 왜 만들었는가?
• 이제 다시 , 원점으로 돌아가서 심플팩토리를 왜 만들어 주었는가 생각해보자, 의존성 때문이었다라고 말한다면 , 그것이 정답이다. 그렇다면 피자 스토어를 상속하는 다른 다수의 피자스토어를 만들어보고, 피자객체를 상속하는 다수의 피자 객체를 어떻게 연관시켜야하는가? 이 의존성을 어떻게 하면 없앨수 있는가? 이렇게 나온것이 역의존관게이다.   
• 어떻게 역 의존하게 만드는가?
• 피자객체에서 팩토리 객체를(다른피자 객체 ) 파라미터나 레퍼런스로 받아, 그 객체를 이용하여 실행되는 피자 객체를 생성한다. 마치 피자 객체가 수행되는것 같지만 내부적으로 팩토리가 실행된다.
• ex) new CheesePizza(Factoty fac){ fac.createCheese()} 이 코드와 같이 실질적으로 cheesePizza의 객체가 실행되지만, 실질적 내부는 팩토리 함수가 실행된다. 이와 같은 방식을 의존성 역전이 되었다고한다

[그림3]

• 의존성 역전의 장점은 무엇인가?
• 피자 객체를 수정할 필요없이, 팩토리에 수정과 추가로 확장이 가능하며, 다양한 피자의 조합을 피자가게에 적용할 수 있게 된다. 

3. 팩토리 패턴의 장점 및 단점

• 생성할 클래스가 변하면, 메서드 ,인터페이스 전체를 바꾸어야한다.
• 다수의 클래스, 상황에 맞는 클래스 생성 시 적합하다.
• 객체 생성을 위한 인스턴스를 생성하지 않아도 된다. 

* 참고 및 출처

 - http://warmz.tistory.com/entry/Abstract-Factory-Pattern-%EC%B6%94%EC%83%81-%ED%8C%A9%ED%86%A0%EB%A6%AC-%ED%8C%A8%ED%84%B4

hardware communication(I2C, SPI, UART)

1. I2C, SPI, UART 차이

• I2C 
• 1: 다 통신
• 반이중통신 (Master, slave)
• 표준 100kbps 고속 400kbp SPI에 비해서는 한참 느린 수준
• SPI
• 1: 다 통신
• 반이중 통신 (Master, slave)
• 셋중에서 가장 빠른 속도를 가지며 mbps까지 가능하다.
• UART 
• 1:1 통신
• 양방향 통신 
• 셋 중에서 가장 느리며 최고 kbps가 한계이다.

2. 각 하드웨어  통신 특징 및 개념  

• UART (Universal Asychronous Receiver Transmitter)

• Serial 통신이라고 불린다. 
• RX, Tx 두개의 핀으로 서로 통신한다.
• 시리얼통신을 셋팅시에는 BITS RATE와 PARIT BIT를 설정하게 되는데, 시리얼통신 시에는 데이터를 동기화할 CLOCK이 없다. 그래서 이 동기를 수행해줄 역할이 바로 BITS RATE가 수행을 하게된다. 각 영역을 BITS RATE로 나누어 해당 데이터를 인식한다. 가끔 ARDUINO 시리얼 모니터에서 SETUP()과 다른 BIT RATE로 설정하게 되면 글씨가 깨지게 되는데, 이 이유는 잘 못된 주기로 데이터를 인식하기 때문이다. 두번째는 PARIT BIT인데 패리트 비트는 해당 데이터가 제대로 전송되었는지에 대한 오류 검출 코드이다. 1의 발생갯수가 홀수인가 짝수인가를 체크하여 홀수개이면 그 해당 데이터는 에러인지 아닌지를 검출하게 된다. 
• 위에서 보이는 데이터 패킷의 형태는 START는 데이터의 시작을 알리는 신호이며 STOP 데이터 종결이자 패리트 비트가 위치하는 영역이다. 

          PS. 실질적으로 양방향통신임에도 UART가 빠르지 않은 이유는 , 동시에 전송과 송             신을 할경우 시그널 왜곡현상이 일어나게 되기때문에 고속으로 보내지 못한다.

• I2C
  
  
  

•  기본적으로  I2C는 SCL(clock) 과 SDA(Data)의 두개의 핀을 가지고 있다.
•  마스터가 SCL을 생성하며 동기형 클럭은 오직 마스터가 권장한다.
•  SDA는 슬레이브에서 마스터로 갈수도 마스터에서 슬레이브 모두 가능한 양방향 신호선이다.
• 하나의 마스터에 다수의 슬레이브가 붙을 수 있는 구조이며, 클럭신호를 통해 패킷만을 처리한다. 

• I2C 패킷 시작과 끝
• I2C 프로토콜에서는 SDA와 SCL이 모두 1인 상태에서 SDA가 0이 되면서 시작을 알린다.
• SCL이 0이면 SDA가 바뀌는 상태이며 SCL 1이면 data는 stable한 상태로 인식되어 읽히게된다.
• SCL이 1인상태에서 SDA가 0이되면 패킷의 종료를 알리게 된다.

•  I2C 패킷 형태
• 마스터가 보내온 클럭신호에 따라 각 비트를 읽게 된다.
• 여기 ACK란 데이터를 수신한 쪽에서 데이터를 잘 수신했다는 의미로 보내주는 시그널이다.
• 예를들어 마스터에서 특정 슬레이브로 신호를 SCL 1번부터 8번까지 보냈다고 한다면 수신받은 슬레이브 SCL 9번에 위치해있는 ACK신호를 보내게되어 다음바이트 전송할지를 정할 수 있다.

• 주소지정 형식
• 각기 슬레이브는 고유주소를 가지게 되는데, Master는 특정 통신하고 싶은 슬레이브 고유주소를 먼저 보내어 통신하게 된다. 이때 버스에 연결되어있는 slave는 자기 주소와 동일한지 검사하여 ack신호에 응답한다.
• R/w 신호는 각 현재 마스터가 슬레이브를 read할 것인지 write할것인지를 알려주는 신호이다. 
• ack신호가 잘 들어오게 되면 보내고 싶은 데이터가 stop state가 될때까지 보내지게 된다.  

Head and First Jsp chapter 3: mini Mvc tutorial

1. MVC 패턴이 실행 되는 순서

• (1). 브라우저가 컨테이너에서 request 메세지를 보낸다. 
• (2). 컨테이너에서 view 페이지를 가져온다.
• (3). 컨테이너가 view페이지를 클라이언트에게 리턴한다.

• (4) 브라우저가 컨테이너가에게 request 메세지를 보낸다.
• (5) 컨테이너는 서블릿에 맵핑되어있는 url을 찾아 request를 서블릿에게 보낸다.
• (6) 서블릿은 해당 request에 해당되는 model을 실행시킨다.
• (7) model 반환된 값을 request object에 넣는다. 
• (8) 서블릿은 request를 jsp로 forward시킨다.
• (9) jsp가 request object로부터 정보를 얻어온다.
• (10) jsp 가 page를 생성하여 컨테이너에게 반환한다.
• (11) 컨테이너가 최종적으로 클라이언트에게 해당 페이지를 반환한다.

More..... 여기서 request object는 동일한 객체이며 재사용된다.

2. user Project 구조

3. 톰켓(컨테이너) project 구조

More . 왜 view 파일(.jsp)은 컴파일 없이 바로 적용되어 질 수 있는가?

• jsp가 인터프린트드 언어이기 때문에, 미리 컴파일 할 필요가 없다.
• 인터프린트드 언어는 한줄 코드를 실시간으로 기계어로 번역하여 로드하기 때문에, 컴파일러 언어처럼 미리 컴파일 할 필요가없다.
• 하지만 인터프린트드 언어는 기존 기계어가 아닌 실시간으로 번역을 하기때문에 컴파일러 언어에 비해 속도가 느리다는 단점이 존재한다.
• 그렇기 때문에 model같은 경우는 컴파일러 언어인 java로 구현이 되어있으며, 동적으로 구성되는 페이지의 경우에는 인터프린트드 언어이자 스크립트 언어인 jsp로 구현되어있다는 점을 기억해야된다.