보다 나은 내일, 다이어리

몇몇 태그는 내장된 고유 기능이 있다.

form 태그는 submit될 시에 페이지를 새로 고침을 한다.

이런 것들을 방지하기 위해 `e.preventDefault()`를 사용한다.

`e.stopPropagation()` 은 이벤트 버블링과 관련.

html 태그 안에서 자식에게 이벤트가 발생하면 특정 함수가 발생되도록 이벤트 핸들러를 심어놓는다.

ex) `onClick = {() => console.log('hi')}`

그러면 이벤트가 발생한 자식을 기점으로 부모에서부터 위로 존재하는 모든 태그의 끝까지 순차적으로 이벤트 핸들러가 동작한다.

이것을 막기 위해 `e.stopPropagation()` 을 사용한다.

하지만 이벤트 버블링을 막아야 할 상황은 거의 없다고 하기 때문에 `e.stopPropagation() `의 사용은 권장하지 않는다.

• focus 이벤트와 같이 몇몇 이벤트를 제외하곤 거의 모든 이벤트는 버블링된다.
• this (`event.currentTarget`) : 현재요소 <form> 요소에 있는 핸들러가 동작했으므로 <form> 요소를 가리킴
• `event.target` - 폼 안쪽에 실제 클릭한 요소를 가리킴
• 꼭 필요한 경우를 제외하곤 버블링을 막지 마세요!
  • 버블링을 막아야 해결되는 문제라면 커스텀 이벤트 등을 사용해 문제를 해결할 수 있다.
  • 핸들러의 event 객체에 데이터를 저장해 다른 핸들러에서 읽을 수 있게 하면, 아래쪽에서 무슨 일이 일어나는지를 부모요소의 핸들러에게 전달할 수 있으므로,
  • 위와 같은 방법으로도 이벤트 버블링을 통제할 수 있습니다!

[개념잡기] e.preventDefault() 와 stopPropagation() 의 차이

버블링과 캡처링

import LogoSrc from './assets/logo.png';

/* ... */

const LogoDiv = styled.div`
  background-image: url(${LogoSrc});
  /* width and height should be set otherwise container will have either have them as 0 or grow depending on its contents */
`;

/* ... */

<LogoDiv />

`../assets/images/lala.jpg `로 했는데도 이상하게 안됐다!

이미지를 import 시켜와서 url에 넣어두고 width와 height을 주면 그제서야 잘 나오는 것 같다!

→ 왜? width와 height 값을 설정해주지 않으면 컨테이너가 0으로 설정되거나 컨테이너의 내용에 따라 변화한다! (auto가 되므로)

styled-components는 이미지를 import 해서 시키는 것을 권장한다! 정석이다!

백엔드 코드를 수정하고 저장하고 다시 시작하면 nodemon stuck restarting… 하면서 오류가 떴다.

`C:\\Windows;` `C:\\Windows\\system32;` `C:\\Windows\\System32\\Wbem`

를 시스템 환경변수에 넣어주면 ,,,!!! 드디어 restarting 에서 stuck되던 게 !!

다시 starting이 된다!!!

https://github.com/remy/nodemon/issues/1956

It was a Windows path thing. Windows was not able to get the path as it had unnecessary special characters like the &  and the whitespaces in the path names. Looks like Node is not able to resolve the paths.

⇒ 윈도우 환경변수의 path에 경로가 존재하지 않아서 노드가 path를 찾을 수가 없어서 starting을 하지 못했던 것이다!

multer, s3

[Node.js] multer-s3를 이용한 AWS s3 파일 업로드

아마존 웹 서비스 IAM 사용자의 액세스 키 발급 및 관리

iam에서 액세스키와 비밀 액세스 키는 한번 생성되면 다시 확인할 수 없으니 .csv로 저장해두거나 잘 메모해놔야 한다.

• multer, multer-s3: 파일 업로드 모듈
• aws-sdk: AWS 서비스 연결 모듈
• s3: s3 객체
• acl: 파일 액세스 권한
  • private : default, 버킷 소유자만 읽기/쓰기 가능
  • public-read: 읽기만 가능, 쓰기(수정) 불가능
  • public-read-writer: 읽기/쓰기 모두 가능
  • bucket: 버킷명
  • key: 파일명

혹시 multerS3에 다른 기능도 넣고 싶다면 공식문서를 참고하자.

multer-s3

• multer
  • single(fieldName): 하나의 파일을 받아서 저장
  • array(fieldName, 최대개수): 하나의 필드명을 가지는 여러개의 파일을 받아서 저장

오류: client.send()is not function

multerS3 와 aws-sdk의 버전이 달라서 생긴 오류였다.

다르니까 @aws-sdk/client와 @aws-sdk/abort-controller 모듈이 필요하다는 에러가 떴고 설치해서 실행하니까 client.send() 함수가 없다는 오류가 뜬 것이다.

버전을 2.~~으로 맞춰서 설치해주니까 두 모듈이 필요하다는 에러메시지가 안뜨고 해결됐다!

(근데 이걸 팀원분이 찾아낸 해결책인데 구글에 어떻게 검색하신 걸까?)

검색어: aws-sdk multer-s3 @aws-sdk/abort-controller

Can the multer-s3 package be used with AWS v3 NodeJS SDK?

→ multer-s3 패키지는 오직 aws-sdk v2 api만 지원한다.

오류: aws s3 access denied

[AWS] AccessDenined: Access Denied

• aws 계정에 대한 액세스
• 퍼블릭 액세스
• IAM 퍼블릭 액세스 차단도 풀어주고
• AmazonBracketFullAccess를 IAM으로 생성한 testUser에게 권한 부여했지만 아직 해결안됨
• accessDenied_solve 라는 커스텀 정책을 만들어서 testUser에게 권한 부여하니 잘 됨!
  AWS S3 Access denied 에러 (+ 버킷 정책 했는데도 안될때)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1405592139000",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::dev-team8-bucket/*",
                "arn:aws:s3:::dev-team8-bucket"
            ]
        }
    ]
}

개선점:

오피스아워 중 코치님 조언

multer에서 로직처리를 하고 s3에 업로드를 하는 방식이 더 좋지 않을까?!

리뷰, 커뮤니티, 유저프로필 별로 폴더를 만들어서 넣어줌?

[AWS] Node.js Multer로 S3에 이미지 업로드하고 Mysql에 저장하기

aws s3 용량 확인하는 법 찾기

→ 5기가를 넘어서는 과금이 생김

사용이유

로그인과 회원가입 페이지를 만들기 위해 위의 레이아웃을 만들어야 했다.

자주 사용하던 `display: flex` 로 하려니까, flex는 아이템 간의 간격을 줄 수 있는 코드가 있을까? 싶어서 이번엔 `display: grid`를 사용해 봤다!

배운 내용

굉장히 뚝딱 거리다가 원하는 대로 레이아웃을 만들긴 했다! 그런데

const Container = styled.main`
  border: 1px solid black;
  background: #fff;
  margin: 100px;
  border-radius: 30px;
  display: grid;
  place-items: center;
  align-content: center;
  grid-template-rows: 0.3fr 1fr 0.3fr;
  grid-row-gap: 30px;
`;

const FormContainer = styled.form`
  width: 70%;
  display: grid;
  grid-template-rows: 1fr 1fr 1fr;
  grid-row-gap: 30px;
`;

grid를 자유자재로 사용하는 것은 아직.. 잘 모르겠다.

나중에 flex도 제대로 익히고 싶다! 솔직히, 가운데 정렬을 하는 `justifyContent: center` 랑 `align-items: center` 밖에 안쓰는 것 같아서 말이다

작년에 정보처리기사는 이미 땄다.

근데 왜 다시 공부하는가?

전체적인 Computer Science를 복습하기엔 정보처리기사가 제격이라고 생각했다!

운영체제, 네트워크, 자료구조, 컴퓨터구조, 데이터 베이스 등 CS의 핵심 내용을 다 다루기 때문이다. 

현 상태는 개념들을 대충은 알지만 누군가가 내게 물어본다면 ...? 자신있게 말하지 못할 것 같았다.

Output이 안된다고나 할까. 그래서 이건 내가 요약해서 정리한 것이니까 나중에 봤을 때도 내가 가장 이해하기 쉬울 것이고 기억에 남기도 더 쉬울 것이라고 판단했다.

또한 지금까지 했던 개발에서 디자인 패턴이나 그런 설계들을 의도적으로 고려하진 않았던 것 같은데, 정처기로 관련 개념들을 다시 정리하면서 '내가 개발한 게 이 패턴이었구나~' 하면서 뭔가 좀 재밌게 복기할 수 있을 것 같았다.

그리고 타이핑 공부법이란?

말 그대로 타이핑하면서 공부하는 방법...인데 어디 유튜브에서 본 방법이다. 

Input과 Output 이 필요한 과정에서 Output의 속도를 미친듯이 올려준다.

1. 일단 정처기 핵심요약본을 읽고 이해한다.

2. 내가 머리에 넣을 수 있을 부분까지 타이핑으로 써본다. 

3. 잘 안써지는 부분은 색칠한다.

4. 나중에 다시 해당 부분을 볼 때도 안떠오르는 부분은 다른 색으로 덧칠한다.

...

언제 끝날진 모르지만.....화이팅!

67. 구조패턴 (Structural Pattern)

클래스나 객체를 조합해서 더 큰 구조로 만들 수 있게 해 주는 패턴

총 7개

1. 어댑터, Adapter
   호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
   기존 클래스를 이용하고 싶지만 인터페이스가 다를 때 이용
   
   
2. 브리지, Bridge
   구현부에서 추상층을 분리하여 독립하여 확장할 수 있도록 한 패턴.
   기능과 구현을 두 개의 별도 클래스로 구성
   
   
3. 컴포지트, Composite
   객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함된 구조 표현할 수 있음
   
   
4. 데코레이터, Decorator
   객체 간 결합을 통해 능동적으로 기능 확장할 수 있는 패턴
   임의의 객체에 부가기능 추가 위해 다른 객체를 덧붙이는 방식으로 구현
   
   
5. 퍼싸트, Facade
   서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요
   복잡한 서브 클래스를 피해 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 함
   
   
6. 플라이웨이트, Flyweight
   다수의 유사 객체를 생성할 때 유용
   매번 인스턴스를 생성하는 게 아니라 가능한 한 공유해서 사용함으로써 메모리를 절약
   
   
7. 프록시, Proxy
   접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
   네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용

68.  행위 패턴(Behavioral Pattern)

클래스나 객체가 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도 최소화에 도움

총 11개

1. 책임 연쇄, Chain of Responsi-bility
   요청을 처리할 수 있는 객체가 chian으로 묶여 있어 요청이 해결될 때까지 책임이 넘어감
   
   
2. 커맨드, Command
   요청을 객체 형태로 캡슐화해서 재사용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
   요청에 사용되는 각종 명령어들을 추상 클래스로 분리하여 단순화함
   
   
3. 인터프리터, Interpreter
   언어에 문법 표현을 정의하는 패턴
   SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용
   
   
4. 반복자, Iterator
   접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함, 내부 표현 방법 노출 없이 순차적 접근 가능
   
   
5. 중재자, Mediator
   수많은 객체들 간의 복잡한 상호작용(Interface)를 캡슐화하여 객체로 정의
   
   
6. 메멘토, Memento
   특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공, Ctrl+Z 같은 되돌리기 기능을 개발할 때 주로 이용
   
   
7. 옵서버, Observer
   한 객체의 상태가 변하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
   주로 분산된 시스템 간에 이벤트를 생성/발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용
   
   
8. 상태, State
   객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
   
   
9. 전략, Strategy
   동일한 계열의 알고리즘을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
   클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능
   
   
10. 템플릿 메서드, Template Method
    상위 클래스에서 골격을 정의하고 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
    유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드 양 줄이고 유지보수 용이하게 함
    
    
11. 방문자, Visitor
    각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
    분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행함

69. 요구사항 검증 방법

• 요구사항 검토, Requirements Review: 담당자들이 수작업으로 분석
  - 동료검토, Peer Review: 작성자가 직접 설명하고 동료들이 결함을 발견
  - 워크스루, Walk Through: 회의 전 미리 배포하여 사전 검토 후 회의를 통해 결함을 발견
  - 인스펙션, Inspection: 작성자를 제외한 다른 전문가가 결함을 발견
  
  
• 프로토타이핑, Prototyping: 요구사항을 정확히 파악하기 위해 견본품을 만들어 최종 결과물을 예측
  
  
• 테스트 설계 : 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토함
  
  
• CASE 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리하고 표준 준수여부 확인
  *CASE : Computer Aided Software Engineering
  : 요구사항을 자동으로 분석, 요구사항 명세서를 기술하도록 개발된 요구사항 분석을 위한 자동화 도구

72. 미들웨어 (Middleware)

Middle + Software
운영체제와 응용 프로그램 또는 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어!

• DB, Datebase: DB를 사용하여 시스템을 구축하는 경우 보통 2-Tier 아키텍쳐라고 함. 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
• RPC, Remote Procedure Call : 원격 프로시저 호출, 응용 프로그램을 사용해서 원격 프로시저를 마치 로컬 프로시저처럼 호출
• MOM, Message Oriented Middleware : 메시지 지향 미들웨어, 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어, 온라인 업무보단 이기종 분산 데이터 시스템의 데이터 동기를 위해 사용됨
• TP-Monitor, Transaction Processing Monitor: 트랜젝션 처리 모니터, 항공기나 철도예약업무와 같은 온라인 트랜젝션 업무에서 처리 및 감시하는 미들웨어, 사용자 수가 증가해도 빠른 응답속도를 유지해야 하는 업무에 주로 사용됨
• WAS, Web Application Server: 정적인 컨텐츠를 처리하는 웹 서버와 달리 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어, 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어

화이팅~!!!

🚩 2과목. 소프트웨어 개발

73. 자료구조의 분류

74. 선형 리스트 (Linear List)

• 연속 리스트, Contiguous List
  배열 같이 연속적으로 저장되는 자료구조
  이용효율은 밀도가 1로서 가장 베스트
  중간에 데이터를 삽입하려면 연속된 빈 공간이 있어야 하고, 삽입과 삭제 시 자료 이동이 필요
  
  
• 연결 리스트, Linked List
  자료를 반드시 연속적으로 저장하지 않고 임의의 장소에 저장하고 , 노드의 포인터 부분을 이용해서 서로 연결시킨 자료구조
  노드의 삽입과 삭제가 용이
  포인터 부분이 필요하므로 이용효율이 좋진 않다
  연결을 위한 포인터를 찾는 시간이 필요하기 때문에 접근 속도가 느리다.
  
  
  

75. 스택 (Stack)

리스트의 한쪽 끝으로만 삽입과 삭제가 이루어지는 자료구조

후입선출 LIFO, Last In First Out: 가장 나중에 삽입된 자료가 가장 먼저 삭제된다.

응용분야

• 함수 호출의 순서 제어
• 인터럽트의 처리
• 수식 계산 및 수식 표기법
• 컴파일러를 이용한 언어 번역
• 부 프로그램 호출 시 복귀주소 저장
• 서브루틴 호출 및 복귀주소 저장

76. 큐 (Queue)

리스트의 한쪽 끝에서 삽입이 이루어지고 다른 쪽에선 삭제가 이루어지는 자료 구조

선입선출 FIFO, First In First Out: 가장 먼저 삽입된 자료가 가장 먼저 삭제된다.

시작과 끝을 표시하는 두 개의 포인터가 있다.

지금까지는 TIL, 오늘 공부 기록, 개발하면서 정리해볼 만한 것들을 Notion 위주로 기록해왔다. 그리고 티스토리 블로그에는 질이 괜찮은 것만 다듬어서 좀 아름답게? 포스팅하려고 했다.

그런데 이 방법은 나중에 봤을 때 한눈에 정리가 되지 않았고 오히려 다시 블로그로 포스팅하는 데에 시간이 많이 소요됨을 알았다. 

그래서 이제부터는 오늘 공부한 기록이나 개발 과정 중에 있던 이슈들 정리 등을 처음부터 블로그에 포스팅하기로 정했다.

카테고리로도 분류할 수 있고, 무엇보다 깔끔하게 한 눈에 들어온다는 것이 큰 장점 같다!!

사생활 부분이나 아직 아름답게? 잘 다듬어지지 않은 것들은 일단은 비공개로 두거나 나중에 다시 고쳐서 공개로 포스팅하는 게 나아보인다!!

그래서 일단은 밀린 노션기록들을 후다다다다닥 블로그에 포스팅할 계획이다...

54. 객체지향 설계 원칙 =SOLID 원칙

• SRP, Single Responsible Principal: 객체는 단 하나의 책임만 져야 한다.
• OCP, Open-Closed Principal: 기능을 추가할 때 기존의 코드를 변경하지 않을 수 있어야 한다.
• LSP, Liskov Substition Principal: 자식 클래스는 최소한 부모 클래스의 행위는 수행할 수 있어야 한다.
• ISP, Interface Segregation Principal: 자신이 사용하지 않는 인터페이스와 의존관계나 영향을 받지 않아야 한다.
• DIP, Dependency Inversion Principal: 각 객체들 간 의존관계가 성립될 때, 구체적인 객체보다 추상화에 의존해야 한다.

*DIP 추가설명!

객체에서 어떤 클래스를 참조해야 할 때, 직접 클래스를 참조하는 것이 아니라 그보다 상위 클래스(추상 클래스 or 인터페이스)를 참조해야 한다. 

55. 결합도 (Coupling)

모듈 간 상호의존하는 정도, 연관관계

약할 수록 품질 높고, 강할 수록 품질 낮다.

결합도가 약함에서 강함 순! 자스제외공내 (자스 제외하고 공부한 나..)

• 자료 결합도, Data Coupling: 모듈 간 인터페이스가 자료 요소로만
• 스탬프 결합도, Stamp Coupling: 모듈 간 인터페이스가 자료 구조(배열, 레코드 등) 전달
• 제어 결합도, Control Coupling: 한 모듈이 다른 모듈의 논리적 흐름 제어하기 위한 제어 요소(switch, flag, function) 전달
• 외부 결합도, External Coupling: 한 모듈에서 선언한 변수를 다른 모듈에서 참조
• 공통 결합도, Common Coupling: 공유되는 공통 데이터 영역을 여러 모듈이 사용
• 내용 결합도, Content Coupling: 한 모듈이 다른 모듈의 내부 기능 및 자료 직접 참조

56. 응집도 (Cohesion)

정보 은닉 개념을 확장한 것

모듈이 독립적인 기능으로 정의되어 있는 정도

약할 수록 품질 낮고, 강할 수록 품질 높다.

응집도가 강함에서 약함 순! 기순통절시논우 (기가 순한 통은 절에서 시를 짓고 논에서 운다...)

• 기능적 응집도, Functional Cohesion: 모듈 내부 모든 기능이 단일 문제와 연관되어 수행
• 순차적 응집도, Sequential Cohesion: 모듈 내 활동으로부터 나온 출력 데이터를 다음 활동의 입력 데이터로 사용
• 통신적 응집도, Communication Cohesion: 동일한 입/출력을 사용해서 서로 다른 기능을 수행하는 구성요소들이 모임
• 절차적 응집도, Procedural Cohesion: 다수의 관련 기능을 가질 때, 순차적으로 기능을 수행함
• 시간적 응집도, Temporal Cohesion: 특정 시간에 처리되는 몇 기능을 모아 하나의 모듈로 작성
• 논리적 응집도, Logical Cohesion: 유사 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성됨
• 우연적 응집도, Coincidental Cohesion: 모듈 내부 각 요소가 서로 관련 없는 요소로만 구성

57. 팬인(Fan-In)/ 팬아웃(Fan-Out)

팬인(Fan-In): 어떤 모듈을 호출하는 모듈의 수

팬아웃(Fan-Out): 어떤 모듈에 의해 호출되는 모듈의 수

58. N-S 차트 (Nassi-Schneiderman Chart)

논리의 기술에 중점을 둔 도형을 이용한 표현, 박스 다이어그램

연속, 선택 및 다중 선택, 반복 등 제어 논리 구조를 표현

화살표x

참고 

60. 재사용

재사용되는 대상은 결합도는 낮고 응집도는 높아야 한다.

비용과 개발 시간을 절약하기 위해 이미 개발된 기능들을 재구성하여 새로운 기능을 사용하기 적합하도록 최적화

규모에 따른 분류

• 함수와 객체: 클래스나 메서드 단위 소스 코드 재사용
• 컴포넌트: 독립적인 기능을 수행하는 실행코드 기반으로
• 애플리케이션: 공통 기능을 제공하는 애플리케이션을 공유하는 방식

61. 효과적인 모듈 설계 방안

기능은 예측가능해야 하며 지나치게 제한적이면 안된다

효과적인 제어를 위해 계층관계를 정의하는 자료가 제시되어야 한다.

복잡도와 중복을 줄이고 일관성을 지킨다.

64. 디자인 패턴(Design Pattern)의 개요

• 각 모듈의 세분화된 역할이나 모듈들 간 인터페이스 같은 코드를 작성하는 수준의 세분적인 구현 방안을 설계 시  참조할 수 있는 전형적인 해결방식 또는 예제.
• 구성: 문제 및 배경, 실제 적용된 사례, 재사용 가능한 샘플 코드 등,,,
• Don't reinvent the wheel, 바퀴를 다시 발명하지 마라 : 개발 중 문제가 발생하면 새로운 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고해서 적용하는 것이 더 효율적!!
• GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨

65. 디자인 패턴 사용의 장/단점

범용적인 코딩 스타일로 인해 구조 파악 용이

객체지향 설계 및 구현의 생산성 높임

검증된 구조의 재사용으로 시간과 비용 절약

설계 변경 요청에 대한 유연한 대처 가능

의사소통 원활

초기 투자 비용 부담

객체지향 기반이므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.

66. 생성 패턴 (Creational Pattern)

객체의 생성과 참조 과정을 캡슐화해서 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 해서 유연성을 높임

총 5가지 추싱팩프빌 (추석에 팩하는 프로 보디빌더..)

1. 추상 팩토리, Abstract Factory:
   구체적인 클래스에 의존하지 않고 인터페이스를 통해 연관 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
   연관된 서브 클래스를 묶어 한 번에 교체 가능 -> DIP가 떠오른다!!
   
   
2. 싱글톤, Singleton:
   하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 순 없음
   클래스 내 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화
   
   
3. 팩토리 메소드, Factory Method
   =가상 생성자 패턴, Virtual Constructor
   객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
   상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당
   
   
4. 프로토타입, Prototype
   원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
   일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용함
   
   
5. 빌더, Builder
   작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
   객체의 생성 과정과 표현 방법을 분리하고 있어서 동일한 객체 생성에서도 서로 다른 결과를 만들어낼 수 있음
   
   

30. 사용자 인터페이스(UI)의 특징

사용자의 만족도에 가장 큰 영향을 미치는 요소, 변경이 많음

사용자 중심으로 설계되어 사용자 중심 상호작용이 되도록 함

수행 결과의 오류를 줄임

사용자의 막연한 작업에 대해 구체적 방법 제시

31. UI 의 구분

• CLI(Command Line Interface): 명령, 출력이 텍스트 형태
• GUI(Graphic User Interface): 아이콘이나 메뉴를 마우스로 클릭하여 작업 수행 형태
• NUI(Natural User Interface): 사용자의 말이나 행동으로 조작 형태
• VUI(Voice User Interface): 사람의 음성을 기기 조작 형태
• OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용-> 사물인터넷, 가상현실, 증강현실, 혼합현실 등과 함께 대두되고 있음

32. UI 의 기본 원칙

유유학직!!ㅎㅎ

• 유연성: 요구사항 최대한 수용, 실수 최소화
• 유효성: 목적 정확하고 완벽하게 달성
• 학습성: 누구나 쉽게 익힘
• 직관성: 누구나 쉽게 이해

33. UI 의 설계 지침

• 사용자 중심: 사용자 편의 위해 실사용자에 대한 이해가 바탕이 되어야 함
• 사용성: 얼마나 빠르고 쉽게 이해
• 심미성: 그래픽적 완성도
• 오류 발생 해결: 오류 발생 쉽게 인지

35. UI 설계 도구

UI 설계 도구? 화면 구조나 배치 등을 설계 시 사용하는 도구

종류

• 와이어프레임(Wireframe): 기획 단계의 초기에 제작, 개발자나 디자이너 간 진행 상태 공유 위함-> 손그림, PPT, 일러스트, 포토샵 등
• 목업(Mockup): 와이어프레임보다 좀 더 실제 화면과 유사하게 만듬. 실제로 구현은 x -> 발사믹 목업 등
• 스토리보드(StoryBoard): 와이어프레임에 콘텐츠 설명, 페이지 간 이동흐름 등을 추가 -> Axure 등
• 프로토타입(Prototype): 실제 구현된 것처럼 테스트 가능 동적 모형
• 유스케이스(Usecase): 사용자 측면에서의 요구사항 기술

36. 품질 요구사항

소프트웨어의 기능, 성능, 만족도 등 요구사항이 얼마나 충족되는가를 나타냄

ISO/IEC? International Organization for Standardization(국제 표준화 기구)/International Electrotechnical Commission(국제 전기 기술 위원회)

ISO/IEC 9126: SW 품질 특성과 평가를 위한 표준 지침

ISO/IEC 25010: 9126을 개정해서 만듬

ISO/IEC 12119: 9126을 준수한 품질 표준, 테스트 절차 포함

ISO/IEC 14598: 개발자, 구매자, 평가자 별로 제품 평가 활동을 규정

이기신사유효..ㅎ (이기적인 신사가 유효해..)

• 이식성(Portability): 다른 환경에서도 얼마나 쉽게 적용할 수 있는지?
• 기능성(Functionality): 요구사항을 정확하게 만족하는지?
• 신뢰성(Reliability): 일관되게 기능을 오류 없이 수행할 수 있는지?
• 사용성(Usability): 컴퓨터 상 발생하는 행위에 대해 사용자가 정확하게 이해하고 다시 사용하고 싶은지?
• 유지보수성( Maintainability): 개선하거나 확장할 수 있는지?
• 효율성(Efficiency(: 사용자 요구하는 기능을 할당된 시간동안 한정된 자원으로 얼마나 빨리 처리?

37. UI 요소

체크박스: 여러 선택지 중 1개 이상 선택

라디오버튼: 하나만 선택

텍스트박스: 사용자가 직접 입력

콤보박스: 이미 지정된 목록 상자에 사용자가 직접 입력 가능

목록상자: 목록 표시하지만 입력x

38. 상위 설계와 하위 설계

상위 설계

=아키텍쳐 설계, 예비 설계

시스템의 전체적인 구조

구조, DB, 인터페이스

하위 설계

=모듈 설계, 상세 설계

시스템의 내부 구조 및 행위

컴포넌트, 자료 구조, 알고리즘

39. 소프트웨어 아키텍쳐 설계의 기본 원리

• 모듈화(Modularity): 성능을 향상시키거나 재사용, 유지보수가 용이하도록 기능들을 모듈단위로 나눔
• 추상화(Abstraction): 전체적이고 포괄적인 개념을 세분화하여 구체화 -> 과정 추상화, 데이터 추상화, 제어 추상화
• 단계적 분해(Stepwise Refinement): 하향식 설계 전략
• 정보 은닉(Information Hiding): 한 모듈 내부에 포함된 절차와 자료가 숨겨져서 다른 모듈이 접근하지 못하도록 함

43. 파이프-필터 패턴

데이터 스트림 각 절차를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴

*데이터 스트림? 정해진 포맷 사용하여 한 장치에서 다른 장치로 보내지는 데이터의 흐름

*필터 컴포넌트: 재사용성, 확장 용이, 재배치하여 다양한 파이프라인 구축 가능

데이터 변환, 버퍼링, 동기화 등에 주로 사용됨, 주로 UNIX의 쉘(Shell)

44. 모델-뷰-컨트롤러 패턴

서브시스템을 3개의 부분으로 구조화하는 패턴,

• 모델(Model): 핵심기능과 데이터 저장
• 뷰(View): 사용자에게 정보를 표시
• 컨트롤러(Controller): 요청 명령을 보냄

45. 기타 패턴

• 마스터-슬레이브 패턴: 마스터에서 슬레이브로 분할, 슬레이브의 결과물을 다시 돌려받음-> 병렬 컴퓨팅 시스템
• 브로커 패턴: 사용자가 원하는 정보를 브로커에 요청하면 연결해줌-> 분산 컴퓨팅 환경
• 피어-투-피어 패턴: 피어를 하나의 컴포넌트로 간주, 피어는 사용자가 될 수도, 정보를 제공하는 서버가 될 수도
• 이벤트-버스 패턴: 소스가 특정 채널에 이벤트를 발생하면 해당 채널의 구독자에게 메시지 줌
• 블랙보드 패턴: 모든 컴포넌트들이 블랙보드에 접근가능, 검색을 통해 블랙보드에서 원하는 정보 찾음. 결정가능한 해결전략이 없을 때 유용, -> 음성인식, 차량식별, 신호 해석 등 활용
• 인터프리터 패턴: 코드의 각 라인을 수행하는 방법을 지정

46. 객체

데이터와 함수를 캡슐화한 하나의 소프트웨어 모듈

데이터= 속성(Attribute), 상태, 변수, 상수, 자료 구조

함수= 메소드(Method), 서비스, 동작(Operation), 연산

* 객체의 특성

독립적으로 식별가능 이름 가짐

상태는 시간에 따라 변함

객체 간 상호연관성에 의한 관계 형성

객체가 반응할 수 있는 메시지의 집합= 행위

47. 클래스

공통된 속성과 연산을 갖는 객체를 하나로 묶음. 객체의 타입을 의미

객체지향 프로그램에서 데이터를 추상화하는 단위

각각의 객체를 인스턴스-> 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)

48. 캡슐화 (Encapsulation)

데이터와 함수를 하나로 묶는 것

캡슐화된 객체는 인터페이스를 제외하고 정보 은닉됨

: 접근 제한적, 외부 모듈 변경으로 인한 파급효과 적음-> 객체 간 결합도 낮아져, 재사용 용이

49. 상속 (Inheritance)

이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

하위클래스는 그에 더해서 첨가해서 사용가능

50. 다형성(Polymorphism)

메시지에 의해 객체가 연산을 수행하게 될 때, 하나의 메시지에 대해 객체가 할 수 있는 고유한 특성으로 응답하는 능력

하나의 함수나 연산자가 다른 클래스에 속한 인스턴스를 같은 인스턴스처럼 수행할 수 있도록 하는 것.

오버로딩: 메소드명은 같지만 인수를 받는 자료형과 개수에 따라 기능 달라져

오버라이딩(=메소드 재정의): 상위클래스에서 정의한 메소드 명은 같지만 하위 클래스에서 실행코드를 달리하여 재정의

 51. 연관성 (Relationship)

두 개 이상의 객체들이 상호 참조하는 관계

종류

• is member of 연관화
• is instance of 분류화
• is part of 집단화
• is a 일반화 + 특수화/상세화

52. 객체지향 분석의 방법론

• 럼바우(Rumbaugh): 객체모델, 동적모델, 기능모델로 나누어 수행
• 부치(Booch): 미시적과 거시적 개발 프로세스를 모두 사용
• Jacobson: Usecase를 강조
• Coad와 Yourdon: E-R 다이어그램 사용
• Wirfs-Brock: 분석과 설계 간 구분이 x, 연속적으로 수행 

53. 럼바우의 분석 기법

=객체 모델링 기법 (OMT, Object Modeling Technique)

객체 모델링 -> 동적 모델링 -> 기능 모델링 순으로

• 객체 모델링: =정보 모델링, 속성과 연산 식별 및 객체 간 관계를 규정해서 다이어그램으로 표시
• 동적 모델링: 상태도를 이용해 시간의 흐름에 따른 동적 행위 표현
• 기능 모델링: DFD를 이용해 프로세스들 간 자료흐름 중심 처리 과정