프로그래밍 패러다임

패러다임

패러다임이란 모델, 패턴, 전형적인 예를 의미하는 파라데이그마(paradeigma)에서 유래

현대의 패러다임 : 한 시대의 사회 전체가 공유하는 이론이나 방법, 문제의식 등의 체계

프로그래밍 패러다임

로버트 플로이드 - 프로그래밍 패러다임 용어의 첫 사용

프로그래밍 패러다임이란? 특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일

→ 어떤 프로그래밍 패러다임을 사용하느냐에 따라 문제를 바라보는 방식과 프로그램을 작성하는 방식이 달라짐.

프로그래밍 패러다임을 통해 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유함으로써 불필요한 부분에 대한 의견 충돌을 방지할 수 있게 되었다.

프로그래밍 언어의 특징과 프로그래밍 스타일은 해당 언어가 어떠한 프로그래밍 패러다임을 채택하였는지에 따라 달라지게 된다.

Java는 객체지향 패러다임을 기반으로 한다.

패러다임과 프로그래밍 패러다임의 개념적 차이점

1. 프로그래밍 패러다임은 상이한 두 패러다임의 공존이 가능하다. → 다중 패러다임 언어

   절차형 패러다임 + 객체지향 패러다임 → C++

   함수형 패러다임 + 객체지향 패러다임 → Scala

2. 과거의 패러다임과 새로운 패러다임의 비교가 가능하다

   객체지향 패러다임 : 절차형 패러다임을 보완하여 탄생했지만 절차형 패러다임의 기반에서 구축

→ 프로그래밍 패러다임은 혁명적이 아닌 발전적

---

객체, 설계

이론이 먼저일까? 실무가 먼저일까?

로버트 I. 글래스

어떤 분야를 막론하고 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전으로 이루고, 비로소 실무의 실용성을 입증하는 이론이 모습을 갖춰간다. 해당 분야가 충분히 성숙해지는 시점에 이론이 실무를 추월한다.

→ 소프트웨어 분야는 이론보다 실무가 더 중요하다.

소프트웨어 설계 : 훌륭한 설계에 관한 최초의 이론은 1970년대가 돼서야 비로소 등장

대부분의 설계 원칙과 개념 역시 실무에서 반복적으로 적용되던 기법들을 이론화한 것이 대부분.

티켓 판매 애플리케이션 구현 예시

요구 사항

1. 추첨을 통해 선정된 관람객은 초대장을 통해 무료로 공연을 관람할 수 있다.
2. 일반 관람객은 티켓을 구매해야만 입장할 수 있다.
3. 관람객을 입장시키기 전에 이벤트 당첨여부를 확인하고 이벤트 당첨자가 아닌 경우에는 티켓을 판매한 후에 입장시켜야 한다.

구현 사항

초대장 : 초대장은 공연을 관람할 수 있는 초대일자를 변수로 가진다.

티켓 : 티켓은 티켓의 요금을 변수로 가진다.

가방 : 관람객이 가지고 있는 소지품 (초대장, 현금, 티켓)을 변수로 가진다.

→ 이벤트에 당첨된 관람객은 현금과 초대장을 가지고 있을 것이고, 그렇지 않은 관람객은 현금만 가지고 있을 것이다.
→ 따라서 이에 2가지 경우에 대응하여 가방에 대한 2가지 생성자를 만든다.

관람객 : 관람객은 소지품을 보관하는 가방을 변수로 가진다.

티켓 오피스 : 판매할 티켓들과 티켓의 판매금액을 변수로 가진다.

판매원 : 자신이 일하는 매표소(티켓 오피스)를 변수로 가진다.

극장 입장의 동작 방식

1. 먼저 관람객의 가방 안에 초대장이 들어있는지 확인한다.
2. 초대장 여부를 확인한다.
   1. 초대장이 있다면 티켓을 관람객의 가방에 넣어준다.
   2. 초대장이 없다면 소극장은 관람객의 가방에서 티켓 금액만큼을 차감한 후 매표소에 금액을 증가시킨다. 그리고 티켓을 관람객의 가방에 넣어준다.

위 방식의 문제점

로버트 마틴

모든 소프트웨어 모듈은 세가지 기능을 가진다.

1. 제대로 실행되어야 한다.
2. 변경이 용이해야 한다.
3. 이해하기 쉬워야 한다.

위와 같은 구현은 2, 3번을 만족시키지 못한다. → 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재이다.

변경에 취약한 코드

관람객이 가방을 들고 있지 않다면? 현금이 아니라 신용카드를 이용해서 결제한다면? 매표소 밖에서 티켓을 판매해야 한다면?

위와 같은 상황에서 모든 코드의 변경이 불가피하게 된다. 객체 사이의 의존성은 코드의 변경을 어렵게 만든다.

객체 사이의 의존성이 과한 경우 = 결합도가 높다

합리적인 수준으로 의존 = 결합도가 낮다

객체 간의 결합도가 높을 경우 함께 변경해야 하므로 변경의 난이도가 올라간다. 따라서 객체사이의 결합을 낮춰 변경이 용이한 설계를 만들어야 한다.

→ 이를 위해서 어플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거해야 한다. → 느슨한 결합

이해하기 어려운 코드

이해하기 쉬운 코드란 우리의 예상에서 크게 벗어나지 않는 코드. 위의 코드는 소극장이 모든 것을 통제한다는 점에서 우리의 상식과 너무나도 다르기 때문에 이 점을 만족시키지 못한다.

또한 위의 코드를 이해하기 위해서는 여러가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다.

입장 로직을 구현 하는 경우 관람객이 가방을 가지고 있고, 가방에는 현금과 티켓이 있으며, 판매원이 티켓 판매소에서 티켓을 판매하고 티켓 판매소에는 돈과 티켓이 보관되어 있다는 것을 기억해야 한다는 것이다.

→ 하나의 메서드에서 너무 많은 세부세항을 다루는 것은 코드의 작성자와 이해하는 사람 모두에게 부담을 준다.