OOD (Object Oriented Disign)

과거에는 한명이 주도적으로 프로그래밍을 했지만 현재에 와서는 그 규모가 너무 커져서 혼자서는 도저히 불가능한 상황이 되었다.

그렇기 때문에 수백명의 인원이 모여서 프로그래밍을 할때 각자 맡은 부분에서 프로그래밍이 가능하게끔 조율하고 설계를 하는것이 중요하게 되었다.

이러한 설계를 할때 객체 중심으로 설계를 하는 것이 OOD라고 한다.

OOD를 할때 가장 중요하게 여겨지는 법칙이 바로 SOLID 이다.

S (SRP. Single responsibility principle)

단일 책임 원칙

하나의 객체는 하나의 책임만 가져야 한다.

O (OCP. Open/closed principle)

개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

L (LSP. Liskov substitution principle)

리스코프 치환 원칙

“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.

기존 함수를 확장한 함수가 기존 함수의 동작 바꾸면 안된다.
상속을 할 때 많이 생기는 문제들

*Go언어에서는 상속을 지원하지 않기 때문에 L의 원칙은 신경쓰지 않아도 된다.

I (ISP. Interface segregation principle)

인터페이스 분리 원칙

“특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”

여러개의 관계를 하나의 인터페이스에 넣는것 보다 하나의 인터페이스 하나에 하나의 관계로 나누는 것이 더 좋다.

D (DIP. Dependency inversion principle)

의존관계 역전 원칙

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”의존성 주입은 이 원칙을 따르는 방법 중 하나다.

관계는 인터페이스에 의존해야지 객체에 의존하면 안된다. 즉 인터페이스를 통해 객체들 과의 관계를 가지는게 중요하다.

Beyond OOP

OOP는 많은 문제점을들 만들어주고 많은 것을 바꾸어 주었다.

하지만 OOP는 절대적인 개념이 아니고, 잘 하기도 매우 어렵다.

문제점
첫 번째로 OOP를 이용해 잘 만든 프로그램을 만들기가 어렵다.
두 번째로 수많은 프로그래머들이 이직을 하면서 현장을 왔다 갔다 하는 상황에서 기존에 프로그램을 OOP를 통해 잘 만들었다고 해도 그 프로그램을 이어받은 프로그래머가 OOP를 이해하고 숙달된 프로그래머라는 보장이 없다. 숙달이 안된 프로그래머가 OOP로 만든 프로그램에 익숙해지는데 많은 시간이 걸릴 것이다.

현대 벤처 사업에서의 모토 Make fast, break things 즉 제품을 빨르게 만들어서 시장에 내서 반응을 보고 아니다 싶으면 빨리 없앤다는 것이다.

이 모토에 따르면 OOP는 빨리 만들기가 쉽지않다. 빨리 만들기 위해선 OOP의 원칙을 많이 어기게 될 것이다. 이런 것을 기술 부채(Tech Debt)라고한다.

만약 OOP의 원칙을 어겨가면서 빠르게 만든 프로그램이 시장에서 인기를 끌었다고 했을때 기반이 잘 되어 있지 않으면 견딜 수가 없다.
그렇기 때문에 빠르기 만들기 위해 쌓아둔 기술 부채를 빠르게 없애고 완성을 시켜야한다.
하지만 OOP를 이용한 프로그램은 이 것이 쉽지가 않다.

이러한 문제점을 통해 OOP를 뛰어넘는 개념이 생겨나기 시작했다.

stateless

상태와 기능이 혼재되어 빠르게 만들지 못한다면
상태를 없애고 기능만 만든다는 개념이다.

Functional 함수형 언어

• erlang
• lisp
• scala
• F#
• Elixir

상태를 가진 함수는 입력이 같아도 결과가 달라질 수 있다. 하지만 순수하게 기능만 가진 함수는 같은 입력을 넣으면 결과는 같다.
그래서 상태를 없애고 기능만 가진 언어가 함수형 언어 이다.

Micro Service

하나의 웹페이지를 만들때 각각의 파트에 있는 서비를 다 따로 만들어서 가져와서 하나의 웹사이트를 완성 시키는 개념

Serverless

기존의 서버의 방식은 사용자가 요청을 하면 하나의 웹서버에서 요청에 대한 답을 주고 받는 방식이었다.
Serverless는 여러 서버들을 취합하여 페이지마다 각각의 서버를 사용하는 방식이다.

프로그래머들이 각자의 영역에서 각자의 서비스를 만들어서 완성된 기능들을 조립해서 하나의 서비스가 된다면 make fast, low tech dept 이 가능하게 된다.