절차지향 및 객체지향 프로그래밍

이미지 출처: https://gbsb.tistory.com/3, https://www.upgrad.com/blog/oop-vs-pop/

요약

분류	절차지향	객체지향
접근 방식	Top-Down	Bottom-Up
구성 요소	함수	객체
접근 제어	없음	public, protected, private
다형성	불가능	함수, 생성자, 연산자 등 오버로딩 가능
상속	불가능	가능
보안성	낮음	높음
데이터 공유	모든 함수 공유	객체간 멤버 함수로만 공유

절차지향 프로그래밍은 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방식이다.
객체지향 프로그래밍은 반대로 자료구조와 이를 중심으로 한 모듈들을 먼저 설계한 다음에 이들의 실행순서와 흐름을 짜는 방식이다.

절차지향 프로그래밍(Procedural Programming)

프로시저(루틴, 하위 프로그램, 서브루틴, 메서드, 함수 등)를 이용하여 작성하는 프로그래밍 방식을 말한다. 프로시저 콜(함수 호출)의 개념을 바탕으로 한 프로그래밍 패러다임이다.

기능이 중심이 되며, "어떤 기능을 어떤 순서로 처리할 것인가?"의 관점으로 바라보는 방식이다.
대표적인 프로그래밍 언어로 C, Visual Basic, Fortran, Pascal이 있다.

절차지향 프로그래밍의 특징

• 하나의 큰 기능을 처리하기 위해 작은 단위의 기능들로 나누어 처리하는 Top-Down 접근 방식으로 설계된다.
• 데이터와 함수를 별개로 취급한다.
• 모든 함수는 데이터 공유가 가능하다.
• 정해진 순서대로 입력해야 하므로 순서가 바뀌면 결과를 도출하기 어렵다.
• 프로그램이 커질수록 구조가 복잡해져 유지보수가 어렵다. (소형 프로젝트에 적합)

객체지향 프로그래밍(Object-Oriented Programming)

우리가 실생활에서 쓰는 모든 것을 객체라고 하며, 프로그램 구현에 필요한 객체를 파악하고 각각의 객체들의 역할이 무엇인지를 정의하여 객체 간의 상호작용을 통해 프로그램을 만드는 것이다. 객체는 클래스라는 틀에서 생겨난 실체(Instance)이다.

객체가 중심이 되며, "누가 어떤 일을 할 것인가?"의 관점으로 바라보는 방식이다.
Bottom-Up 접근 방식으로 설계되는데, 세부 모델부터 설계하고 조립한다.
대표적인 프로그래밍 언어로 C++, C#, Java, Python이 있다.

장점

• 상속, 캡슐화, 다형성의 특징으로 코드를 재사용하거나 확장하기 좋아서 유지보수가 쉽다.
• 관련이 많은 객체의 상호작용을 생각해 실세계에 대한 모델링을 좀 더 쉽게 해준다.
• 캡슐화 특징으로 실제로 구현되는 부분을 외부에 드러나지 않도록 은닉하여 보안성이 높다.

단점

• 캡슐화와 격리구조 때문에 절차지향 프로그래밍보다 실행 속도가 느리다.
• 객체 단위의 구성으로 필요한 절차지향 프로그래밍보다 메모리 비용이 크다.

객체지향 프로그래밍의 주요 특징 4가지

추상화(abstraction)

구체적으로 정의하는 것이 아니라 필요한 정보만을 중심으로 간소화 하는 것을 의미한다. 지하철 노선도 처럼 실제 지형도보다 지하철역 간의 상대 위치가 중요하게 정리된 것이 추상화의 대표적인 예로 볼수 있다.

캡슐화(Encapsulation)

객체가 독립적인 역할을 할 수 있도록 데이터와 기능을 하나로 묶어서 관리하는 것을 말한다. 실제로 구현되는 부분을 외부에 드러나지 않도록 하여 정보를 은닉할 수 있다.

상속성(Inheritance)

하나의 클래스가 가진 데이터나 기능을 다른 클래스가 그대로 물려받는 것을 말한다. 기존 코드를 재사용하여 확장시킬 수 있다.

다형성(Polymorphism)

하나의 클래스나 메서드가 다양한 방식으로 동작이 가능한 것을 말한다. 오버라이딩과 오버로딩이 있다.

오버라이딩(Overriding): 상속받은 자식 클래스에서 부모 클래스의 메서드와 같은 이름을 사용하고 매개변수와 리턴 타입도 같은 상태에서 기능을 재정의하는 것을 말한다.
오버로딩(Overloading): 같은 이름의 함수를 매개변수를 다르게 하여 기능을 재정의하는 것을 말한다.

객체지향 설계 원칙 5가지(SOLID)

단일 책임 원칙(Single responsibility principle)

한 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다.

개방-폐쇄 원칙(Open/closed principle)

소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다.

리스코프 치환 원칙(Liskov substitution principle)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

인터페이스 분리 원칙 (Interface segregation principle)

클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다. 큰 덩어리의 인터페이스를 구체적이고 작은 단위로 분리함으로써 클라이언트들이 꼭 필요한 메서드만 이용할 수 있게 한다.

의존관계 역전 원칙(Dependency inversion principle)

첫째, 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
둘째, 추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다.