소공 시간에 배운 내용 요약한 부분입니다. ^^
틀린 부분 있으면 댓글 달아주세용~

조만간 말로 잘 바꿀 생각이긴한데-
언제 할지는.. T^T

Design patterns(1)

why design patterns?

● reuse : 재사용을 위함이다.

● 재사용 하다보면 패턴을 찾게 되고, 어떤 형태의 디자인 패턴을 알게 된다.(flexible, elegant, reusable)

● 잘 만들어진 디자인을 카피해서 적용하게 되고, 쓰다보면 잘 사용하는 패턴을 알게 될 것이다.

● 여럿이서 같이 작업 했을 때 패턴에 대해 공유가 되어있는 상태면 척하면 알 수 있으므로 작업이 쉬워짐.

● 쉬워지는 만큼 표준화가 되어 좋다.

● 표준화의 문제??

■ 보안이 취약해짐(다른팀에서도 슬쩍만 봐도 알게됨)

■ 단순한 것도 틀을 맞춰야 하니 시간이 걸리게 될 수 있음. 코드가 길어 질 수 있음. 예외사항이 나왔을 때 표준화 시켜야하는 부가적인 제약이 생김.

■ 예외 사항이 발견 됬을 때 대응을 못함.(법 규정이 없어서 처리 못하는 것처럼)

■ 표준화를 공부해야 하는 아픔?

■ 내가 짤려도 잘 돌아감. (내가 아니더라도 누군가가 쉽게 할 수 있다.)

● 디자인 패턴은 디스크립션이다. 오브젝트나 클래스들 간에 연결관계(수직,수평,만드는 등)를 디스크립션 해놓은 것이다.

● 커먼 디자인 스트럭쳐 - 오브젝 오브젝트 디자인 위에서...

Elements of a Pattern

● Name : 모든지 이름은 있어야. 이해하기 쉽게 정해야 한다.

● Problem: 목적, 문제.

● Solution : 패턴은 이렇게 한다- 해결

● Consequences : 해결된 것은 이렇다.

PATTERNS VS Design(설계)

VS Framework : 클래스들의 집합, 재사용 할 수 있게 잘 모여 있어야. 패턴에 맞게 잘 되어있어야 된다. 훨씬 더 플렉서블 해서 뭔가를 만들 수 있도록 되어있어야 한다.

VS Architecture - 틀, 구조? 어플리케이션 정도? 프레임웍들을 사용해서 만들어 놓은 무언가. 네모난 프레임으로 아파트, 상가 모두 만들 수 있다. 아파트, 상가 이런거는 아키텍처.가능한 한 독립적으로 해야 한다.

ex) 건축된 결과물이 아키텍쳐(건축). 겉의 뼈대를 프레임. 철근-클래스. 객체같은 것.

: 패턴이 잘 되어있어야 한다. 정말 잘 만들어져 있는 아파트는 하루에 세층씩 만들어짐.

★정말 중요한 것이 패턴 - 처음 만들 때부터 디자인을 잘 해서 프레임을 잘 만들어야.. 바꾸기 쉽도록.

MVC(모델, 뷰, 컨트롤러)

● UI에서 많이 나옴.

● UI바꾸면 코딩이 바뀜, 데이터도 바뀜, 다른 UI도 바뀜, 그래서 분리하고 싶어 함.

● 독립적으로 만들어 한군데 수정해도 문제없게, 추상화를 잘 해야 함.

● 각각이 플렉서블 해야함.

■ 모델→model

■ 뷰→어떻게 보여줄까

■ 컨트롤→어떻게 처리할까

ex) 옛날 html은 세 개가 다 있어서 힘듦. html/CSS(뷰)/javascript(컨트롤러)

The essential principles

● Implementation(구현) 보다는 인터페이스로 프로그래밍 해라.

● Interface - 추상화 잘해서 코딩해라.

클래스를 감싸고 인터페이스를 몇 개 열어둠→캡슐화해서 추상화 하란 얘기.

→플렉서블리티,를 높이기 위해 저런걸 함..

● Inheritance(상속) - composition(내가 갖다 쓰는 것)을 사용해라!

필요할 때 왕창 받아쓰고, 나머지는 그냥 갖다 써라. (?)

→플렉서블리티,를 높이기 위해 저런걸 함..

Organizing the Catalog

● 목적에 따라 3가지 패턴으로 다름.

■ Creational Patterns(생성패턴) : 오브젝트, 클래스 생성

■ Structural Patterns(구조패턴) : 구조관련된 것들. 컴포짓(가져다 써라)

■ Behavioral Patterns: 액션 어떻게 할까, 상호작용, 액션에 관련된 방법들을 잘 정리해놓은 패턴.

Design patterns(2)

● Creational patterns

: 만들 때 사용한다. 플렉서블리티하게 잘 만들려고-

■ Factory Method Pattern(공장): 몬가를 만들어내는 클래스를 만들어냄. 모든 오브젝트는 얘가 만들어냄. 모든 클래스 안에 크리에이션 하는 게 들어있으면 불편하니깐 크리에이션 하는 것만 따로 만들어져 있게 되면 좋음.

■ Singleton Pattern : 뮤직 어플리케이션, 내가 동작을 하고 있을 때 다른 애들은 동작 못하게 해야 함. ex) ATM 기계, static으로 만들어야 할 것이 있다면 싱글레톤 패턴을 써라.

● Structural patterns

■ Decorator pattern : 장식.

a‘를 만들 때 a로부터 조금 데코레이터 해서 만들면 좋음.

잘 추상화 되어있는 클래스에 데코레이터 붙이면 좋음.

■ Adapter pattern: 변환해 줌.

어댑터를 붙이면 변신 됨. 여러개 쓰면 여러군데 변신할 수 있음.

얼마나 더 넓게 사용 할 수 있느냐가 문제.

추상화가 잘 되어있어야 어댑터를 잘 사용할 수 있음.

■ Composite pattern : 불러다 씀.

내 클래스가 적음-

자기가 무언가를 하긴 하지만 내가 갖고 있지 않은 기능들을 가져다 씀.

잘 독립적으로 만들어져 있어야 함.

앱스트랙션이 잘 되어있어야 한다→인터페이스가 잘 되어있어야

어떻게 컴포짓패턴을 쓸까?→클래스나 오브젝트 만들 때 쓴다.

● Behavioral patterns : 클래스들 간의 인터랙션 관련.

■ Command pattern

: 명령어, 엄마가 몇몇 명령을 자녀들에게 함. 집안일을 아빠와 애들에게 명령어.

아버지에게 집을 잘 보세요. 아버지는 자녀들에게 구체적으로 커맨드를 줌.

클라이언트에게 리퀘스트를 전달 할 때 잘 추상화 시켜서 실행을 해라.

컴플릿 커맨드 -

커맨드 인터페이스를 써서 플렉서블리티하게.

■ Observer pattern

: 구경하는 애,

패턴의 상태 변화를 보고하는.

한번 알려주면 쫙-

등록된 인스턴스에게 상태 변화에 대해 알려줌. 플랙서블리티 높아짐.

■ Template Method pattern

: 컴포짓 보다 인헤리턴스에 근거된 것. 템플릿을 잘 만들어라-

혼자 있는 것 보다는 인헤리턴스 잘 해야 좋다.

오퍼레이션을 쭉 붙여놓은 것 - 알고리즘.

■ State pattern

: 끄는 것, 켜는 것, 상태변화를 관리하는 패턴이 있으면 좋다.

■ Strategy pattern

: 알고리즘들을 정의하고 인캡슐레이션 해서 패턴화 해놓으면 좋겠다.

-> 알고리즘이 캡슐레이션 되어있음. 블랙박스.