Skip to content

Latest commit

 

History

History
87 lines (61 loc) · 5.15 KB

프로그래밍 패러다임.md

File metadata and controls

87 lines (61 loc) · 5.15 KB

🧮 프로그래밍 패러다임

프로그래밍 패러다임(Programming Paradigm) 은 프로그래밍 언어와 개발 방법에 대한 기본적인 접근 방식과 철학을 나타내는 개념이다.
또한, 프로그램의 구조와 동작을 조직화하고 추상화하는 방법을 제공하며, 각 패러다임은 고유한 개념과 원칙을 포함한다.
이를 통해 프로그래머가 문제를 해결하고 소프트웨어를 개발하는 데 사용할 수 있는 도구와 접근법을 제공받을 수 있다.

1. 선언형(Declarative Programming)

  • '무엇을' 해야 하는지 기술하는 방식의 패러다임
  • "프로그래밍은 함수로 이루어진 것이다"라는 명제가 담긴 패러다임

📍 함수형 프로그래밍

  • 순수 함수를 블록처럼 쌓아 로직을 구현하고 고차 함수를 통해 재사용성을 높인 프로그래밍 패러다임
  • JavaScript는 단순하고 유연한 언어이며, 함수가 일급 객체이기 때문에 함수형 프로그래밍 방식이 선호됨

💡 순수 함수: 출력이 입력에만 의존하는 함수

const pure = (a,b) => {
    return a + b
}

💡 고차 함수: 함수를 값처럼 매개변수로 받아 로직을 생성하는 함수

이때, 고차 함수를 쓰기 위해서는 해당 언어가 일급 객체라는 특징을 가져야 하며, 그 특징은 다음과 같다.

  1. 변수나 메서드에 함수를 할당할 수 있다.
  2. 함수 안에 함수를 매개변수로 담을 수 있다.
  3. 함수가 함수를 반환할 수 있다.

2. 명령형(Imprative Programming)

  • '어떻게' 해야 하는지 명시적으로 지시하는 방식의 패러다임
  • 프로그램은 일련의 명령문으로 구성되며, state와 변경 가능한 변수를 중심으로 동작함

📍 객체지향형 프로그래밍(Object-Oriented Programming, OOP)

  • 객체 간의 상호작용을 중심으로 프로그래밍 하는 방식
  • 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
  • 설계에 많은 시간이 소요되며 다른 프로그래밍 패러다임에 비해 처리 속도가 느림

⭐️ 객체지향 프로그래밍의 특징

객체지향 프로그래밍은 추상화, 캡슐화, 상속성, 다형성이라는 특징이 있다.

  • 추상화: 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
  • 캡슐화: 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
  • 상속성: 상위 클래스의 특성을 하위 클래스가 재사용하거나 추가/확장하는 것
  • 다형성: 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것 (오버라이딩, 오버로딩)

👉🏻 필자가 JAVA 예시 코드와 함께 자세히 작성한 객체지향 프로그래밍의 특징

⭐️ 객체지향 프로그래밍의 설계 원칙

객체지향 프로그래밍을 설계할 때는 SOLID 원칙을 지켜주어야 한다.

  • Single Responsibilitiy Principle (단일 책임 원칙)
    • 모든 클래스는 각각 하나의 책임만 가져야 한다.
  • Open Closed Principle (개방-폐쇄 원칙)
    • 기존의 코드는 적게 변경하면서도 확장이 쉬워야 한다.
  • Liskov Subsitution Principle (리스코프 치환 원칙)
    • 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  • Interface Segregation Principle (인터페이스 분리 원칙)
    • 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 한다.
  • Dependency Inversion Principle (의존 역전 원칙)
    • 변경될 가능성이 높은 것에 의존하지 않고 변경되기 어려운 것에 의존해야 한다.

👉🏻 보다 자세히 작성한 객체지향 프로그래밍의 설계 원칙

📍 절차형 프로그래밍

  • 로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있음
  • 일이 진행되는 순서대로 구현하므로 코드의 가독성이 좋고 실행 속도가 빠름
  • 계산이 많은 작업 등에 쓰임
  • 모듈화하기 어렵고 유지 보수성이 떨어짐

패러다임의 혼합

"어떠한 패러다임이 가장 좋은가?"에 대한 답은 없다.
비즈니스 로직이나 서비스의 특성을 고려해서 패러다임을 정하는 것이 좋다.


References