📌 순차적 / 절차적 프로그래밍
순차적 프로그래밍
- 시간의 흐름대로, 순서대로 흘러가는 프로그래밍 구조.
코드가 100줄이라면, 첫번 째 줄부터 100번 째 줄 까지 순서대로 흘러가는 구조.
절차적 프로그래밍
-
C, Fotran, Basic 같은 언어들
-
하나의 '절차'를 함수화 시킴 -> 재사용을 위해서
-
프로시저 중심의 접근 방식. (Call - Caller 관계)
-
함수와 데이터를 따로 관리함 (Struct - (pointer) - Procedure)
📌 객체지향 프로그래밍
- Object-Oriented Programming(OOP)
- C++, JAVA, C#, Python, Ruby, Swift, Kotlin
객체지향은 세포다.
출저 : 위키피디아
소프트웨어도 세포처럼 하나의 기능을 담당하는 독립된 객체로 설계할 수는 없을까?
각각의 세포, 객체는 메세지를 주고받으면 되지 않을까?
객체의 특징 (a.k.a UML 다이어그램)
-
객체지향은 대규모 프로그램 설계를 위해 고민해서 나온 산출물이다.
-
객체에는 데이터(Data)와 프로시저(Procedure, 이하 함수)의 집합이다.
-
객체와 객체는 서로에게 의존한다.
-
객체는 다른 객체를 상속한다.
집합, 의존, 상속의 관점에서 바라본 객체(UML 다이어그램) 출저 : seolang2.log
📌 객체지향 프로그래밍(OOP)의 특징과 SOLID 원칙
객체지향 프로그래밍(OOP, Object-Oriented Programming) 특징
출저 : 코드스테이츠
➔ 추상화(Abstration)
-
공통된 특징, 본질을 모아 추출
-
설계(역할)와 구현을 분리
-
인터페이스 등을 이용해서, 어떤 객체가 가져야 할 핵심적 기능을 규정 (설계)
-
인터페이스를 상속받은 클래스에서 구현한다. (구현)
➔ 상속(Inheritance)
-
기존의 클래스를 재활용하여 새로운 클래스를 만든다.
-
반복적인 코드를 최소화, 오류를 줄여줌.
-
메서드 오버라이딩(Method Overriding)을 통해 재정의.
➔ 다형성(Polymorphism)
- 어떤 객체의 속성이나 기능이 상황에 따라 여러가지 형태를 가질 수 있는 성질
➔ 캡슐화(Encapsulation)
출처 : https://incheol-jung.gitbook.io/docs/q-and-a/architecture/undefined-1
-
변수와 함수를 하나의 클래스로 묶고 외부에서 쉽게 접근하지 못하게 은닉
-
접근제어자(public, private, protected, getter, setter etc)
객체지향 설계원칙 (SOLID 원칙)
프로젝트 규모가 커질 수록, 데이터에 접근해서 변경하는 것을 최소화 시켜야 한다.
➔ SRP (Single Responsibility Principle, 단일책임의 원칙)
-
하나의 클래스는 하나의 책임만 갖는다.
-
너무 많은 기능을 넣지 않는다.
-
기준이 모호하다는 비판, 각자의 SRP 기준은 다를 수 밖에 없다.
-
변경사항이 있을 때, 애플리케이션의 파급 효과가 적으면 SRP 원칙을 잘 따르는 것으로 볼 수 있다.
➔ OCP (Open Closed Principle, 개방폐쇄의 원칙)
-
높은 응집도와 낮은 결합도
-
확장에 대해서는 개방적이고, 수정에 대해서는 폐쇄적
-
유연한 코드 수정, 쉽게 확장할 수 있게 설계
-
객체를 직접 수정하는 것을 제한
➔ LSP (Liskov Substitution Principle, 리스코프 치환 원칙)
-
프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스(객
-
하위클래스는 인터페이스의 규약을 잘 지켜야 한다.
-
자식 객체는 부모 객체를 완전히 대체할 수 있어야 한다.
public class Rectangle
{
protected int width;
protected int height;
public int getWidth()
{
return width;
}
public int getHeight()
{
return height;
}
public virtual void setWidth(int width)
{
this.width = width;
}
public virtual void setHeight(int height)
{
this.height = height;
}
public int getArea()
{
return width * height;
}
}
public class Square : Rectangle
{
public override void setWidth(int width)
{
super.setWidth(width);
super.setHeight(getWidth());
}
public override void setHeight(int height)
{
super.setHeight(height);
super.setWidth(getHeight());
}
}
public class Main
{
public static void main(String[] args)
{
Rectangle rectangle = new Square();
rectangle.setWidth(10);
rectangle.setHeight(5);
System.out.println(rectangle.getArea());
}
}➔ ISP (Interface Segragation Principle, 인터페이스 분리 원칙)
- 범용 인터페이스 하나보다는 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다.
ex. 스마트폰 인터페이스(전화, 문자, 무선충전, AR, 생체인식)로 갤럭시 S23을 만들 때, 갤럭시 S2를 만들 때
출처 : Inpa 티스토리 (inpa.tistory.com)
➔ DIP (Dependency Inversion Principle, 의존관계 역전 원칙)
-
구체화가 아니라 인터페이스에 의존하라.
-
구현 클래스(구현체)가 아니라 인터페이스(역할)에 의존하라.
ex) 4번 타자는 이대호를 써야해 (x)
4번 타자는 장타율이 높고 홈런을 잘 치는 선수를 써야해 (o)
// High-Level Dependency
interface Weaponable {
int attack();
}
class OneHandSword : Weaponable {
String NAME;
int DAMAGE;
OneHandSword(String name, int damage) {
NAME = name;
DAMAGE = damage;
}
public int attack() {
return DAMAGE;
}
}
class TwoHandSword : Weaponable {
}
class BatteAxe : Weaponable {
}
class WarHammer : Weaponable {
}
class Character {
final String NAME;
int health;
Weaponable weapon; // High-Level Dependency
Character(String name, int health, Weaponable weapon) {
this.NAME = name;
this.health = health;
this.weapon= weapon;
}
}📌 객체'지향' 프로그래밍
- 절대법칙이 아니다!
- SOLID 법칙 중 DIP 원칙과 상속은 서로 모순된 내용을 지니고 있다.
High-Level Dependency 인터페이스를 사용하면 메소드 Override를 지양해야 한다. - 프로젝트에 맞는 설계 방식과 원칙을 '생각'해야한다.
- 우리가 객체지향을 배우고 있는 이유도 게임이라는 프로젝트에는 객체지향이 적합하다고 생각한 개발자들이 많았기 때문이다.
(AI나 데이터 사이언스에는 함수형 프로그래밍을 지향 하듯이)
객체지향의 장점과 함수형 프로그래밍의 장점을 접목 시키는 개발자나 프로젝트도 있다. - 추후 객체지향프로그래밍 아이디어는 디자인패턴으로 이어진다.
출저
출저
- SOLID 법칙 중 DIP 원칙과 상속은 서로 모순된 내용을 지니고 있다.
