프로그래밍 패러다임 (함수형, 객체지향, SOLID 원칙)

 

---

함수형 프로그래밍

→ JS

순수 함수들을 블록처럼 쌓아 로직을 구현하고 고차 함수를 통해 재사용성을 높인 프로그래밍 패러다임

• 순수 함수 : 출력이 입력에만 의존
• 고차 함수 : 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것

함수형 프로그래밍은 순수 함수를 통해 side effect를 최대한 억제하여 오류를 피하고 프로그램의 안정성을 높이려는 노력의 한 방법

 

🔎 함수형 프로그래밍이 최근에 주목받는 이유 → 재사용성

 

 

---

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

프로그래밍에서 필요한 데이터를 추상화시켜서 상태와 행위를 가진 객체로 만들고, 객체들 간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법

• 상태 : 어떤 상태 값을 나타내는 변수
• 행위 : 그 행위를 하는 메서드

 

장점

• 프로그램을 보다 유연하고 변경이 용이하게 만들 수 있음 
• 각각 역할 단위로 분리하여 사용하여 협업 수월
• 필요한 부분만 수정 가능하며 프로그램 유지보수가 쉬움
• 코드의 재사용을 통해 반복적인 코드를 최소화하고, 코드를 최대한 간결하게 표현

 

특징

(상추캡다...)

 

상속(Inheritance)

• 기존의 클래스를 재활용하여 새로운 클래스를 작성하는 것으로 속성과 행위를 물려줌

 

추상화(Abstraction)

• 공통의 속성과 행위를 찾아서 타입을 정의하는 과정
• 불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 프로그램을 간단하게 만드는 것
  • 중요한 정보 → 객체의 공통적인 속성과 기능

 

캡슐화(Encapsulation)

• 서로 연관있는 속성과 기능들을 하나의 캡슐로 묶는 것
• 데이터의 보호와 은닉이 가능하게 함

 

다형성(Polymorphism)

• 하나의 변수명, 함수명이 상황에 따라 다른 의미로 해석될 수 있는 것
• 오버라이딩, 오버로딩

 

---

오버라이딩(overriding)

상위 클래스가 가진 메서드를 하위 클래스가 재정의해서 사용

즉, 같은 이름의 메서드가 상황에 따라 다른 역할 수행

→ 런타임 중 발생하는 동적 다형성

 

---

오버로딩 (overloading)

하나의 클래스 내에서 같은 이름의 메서드를 여러 개 중복하여 정의하는 것

같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 함

※ 매개변수의 개수, 순서, 데이터 타입 중 하나라도 다르면 됨

→ 컴파일 중 발생하는 정적 다형성

function 덧셈_후_정수_반환(int a, int b){
	return a + b
}

function 덧셈_후_정수_반환(double a, double b){
	return Math.trunc(a + b)
}

 

 

---

객체지향 설계 원칙 (SOLID)

단일 책임 원칙 (SRP, Single Resposibility Principle)

클래스는 단 하나의 책임(목적)만 가져야 함

※ 책임 = 기능 담당

 

클래스를 세분화하게 되면 복잡해져서, 100퍼센트 지킬 수는 없는 원칙이지만 최대한 따르기를 권장

 

 

개방-폐쇄 원칙 (OCP, Open Closed Principle)

확장에는 열려있어야 하며, 수정에는 닫혀있어야 함

즉, 기존의 코드는 잘 변경하지 않으면서도 확장은 쉽게 할 수 있어야 함

 

클래스를 수정해야 한다면 그 클래스를 상속(확장)하여 수정함

즉, 기본이 되는 클래스는 가만히 두고, 수정사항은 해당 클래스를 상속하는 클래스를 새로 만들어 반영

• 부모 클래스 → 폐쇄
• 상속받은 클래스 → 수정 & 개방

 

 

리스코프 치환 원칙 (LSP, Liskov Substitution Principle)

서브 타입은 언제나 부모 타입으로 교체할 수 있어야 함

즉, 상속된 클래스에서 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가게 만드는 것

※ 다형성 원리를 이용하기 위한 원칙

부모 클래스에서 자식 클래스를 상속할 때 구조를 overriding 하여 변경하지 않아야 함

 

 

인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

각 행위에 대한 인터페이스는 서로 분리되어야 함

하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 함

 

 

의존 역전 원칙 (DIP, Dependency Inversion Principle)

상위 클래스가 하위 클래스에 의존하면 안 된다는 법칙

어떤 클래스를 참조해서 사용해야 하는 상황이 생긴다면, 그 클래스를 직접 참조하는 게 아니라 그 대상의 상위 요소(추상 클래스 / 인터페이스)로 참조하라는 원칙

부모 클래스는 하위 클래스와 치환은 되지만, 의존해서 변경되면 안 됨

독립성을 확실히 가지고 있어야 함