절차 지향 vs 순차 지향 vs 객체 지향

안녕하세요
오늘은 프로그래밍 패러다임을 얘기해 보려고 합니다
저는 자바 스프링을 주요 기술로 공부하면서 늘 "객체 지향적" 설계를 중요하게 생각해 왔습니다

객체가 자신의 책임과 역할을 하도록 설계하며,
늘 해당 역할을 잘 수행하고 있는지
네이밍에 한정된 책임 부여는 아닌지 고민하고
책임이 잘 분리될 수 있도록 설계하기 위해 노력했어요

하지만 생각해 보면 절차 지향이라고 책임이 없을까요?
함수 단위로 나뉜 건 책임이 아닐까요?

제 안의 개념의 혼동이 있다는 사실을 인지하고
잘 정의하기 위해서 글을 정리해 보고자 합니다

정의

• 순차 지향 (Sequential Programming): 말 그대로 코드가 작성된 순서대로 한 줄씩 순차적으로 실행하는 방식

• 절차 지향 (Procedural Programming): 프로그램을 함수나 절차 단위로 나누어 순서대로 실행하는 방식

• 객체 지향 (Object-Oriented Programming, OOP): 데이터와 그 데이터를 처리하는 함수를 하나의 객체로 묶어 관리하는 방식, 책임과 역할을 가진 객체 단위

의문점

위 정의를 토대로 이렇게 생각해 볼 수 있어요
데이터를 기준으로 책임과 역할을 분리하는 것이 객체 지향입니다
거시적으로 볼 때 함수의 흐름에서 해당 함수를 분리하였을 때, 그것이 역할도 명확이 분리된다면 절차 지향이며 객체 지향으로 볼 수 있을까요?

객체 지향은 역할과 책임 단위로 객체를 분리하는 것이잖아 만약 어떠한 절차에서 함수를 분리하였을 때 거시적인 관점에서 책임이 분리되었다면 그것이 절차 지향이며 객체 지향으로 볼 수 있는 거야?

여기서 집중해야 할 점은

객체 지향이 데이터(상태)와 행동(메서드)을 하나의 단위(객체)로 캡슐화 한다는 점입니다
단순히 함수로 책임을 분리해도 캡슐화가 되어 있지 않으면 이것은 객체 지향이 아니라는 점이에요

즉, 함수로 인해 책임과 역할이 분리될 수는 있으나 객체가 단순히 책임과 역할뿐만 아니라 "자신의 상태를 책임지고, 외부에서 직접 상태를 조작하지 않고 메서드를 통해서만 상태를 변경" 특성까지 고려한다면 단순 책임 분리일 뿐 객체 지향으로 보기는 어렵습니다

생각

하지만 늘 객체 지향이 좋은 것만은 아닙니다

객체 지향은 설계와 구조가 복잡해질 수 있고, 적절한 추상화와 캡슐화를 위해 많은 고민과 시간이 필요합니다
특히 작은 규모의 프로젝트나 단순한 문제에서는 절차 지향이 더 직관적이고 빠르게 개발할 수 있는 장점이 있습니다
또한, 잘못 설계된 객체 지향 구조는 오히려 유지보수와 확장성을 어렵게 만들 수도 있습니다
따라서 상황과 요구사항에 맞게 적절한 프로그래밍 패러다임을 선택하는 것이 중요합니다

협업을 해 보면 객체 지향이 협업에서 꽤 유용하게 작동되더라~ 정도의 판단일 뿐,
특정 상황과 환경에서 100%로 잘 맞다! 는 절대 아니라고 생각합니다

수많은 경험을 통해서 협업 환경에서 어느정도로 잘 동작하기에 선택한 패러다임이며,
특정 부분에서 객체 지향이 코드 퀄리티를 저해할 경우에는 다른 패러다임을 선택해서 작성할 수 있다고 생각합니다

따라서 개발자는 이러한 패러다임을 잘 인지하고 코드를 작성하는 것이 중요하다고 생각합니다 👍