개발자가 반드시 정복해야 할 객체지향과 디자인 패턴에서 발췌한 글이 포함되어 있습니다.
우선 책의 1장을 읽으며 기록해뒀던 것들을 스스로 남겨두기 위해 몇 줄 적고 본격 절차지향을 지양해야하는 이유에 대해 작성하겠다.
본격 구현 전, 설계를 통해 비슷하게 동작하는 것들을 구분하자
서로 다른 이유로 변경되는 코드가 한 메서드에 섞여있으면 향후 유지 보수하기 어렵다. 메서드 내부의 코드들이 모두 같은 목적을 바라보고 있는지 확인해보자
소프트웨어는 사용자의 요구 사항을 만족시킴과 동시에, 변화할 수 있어야한다. (요구사항은 언제든 변화할 수 있다.)
절차지향을 지양해야하는 이유
절차지향과 객체지향 중, 객체지향을 따라야 한다는 말은 많이 들어봤을 것이다. 그런데 도대체 왜? 절차지향보다 객체지향을 지향해야할까라는 의문이 생겼다. 이 책을 통해, 절차지향을 지양해야하는 이유를 확인할 수 있었고, 그 이유들을 정리해보기 위해 책을 읽던 도중 노트북을 켰다 🤨
우선, 절차지향은 데이터를 조작하는 코드를 별도로 분리해서 함수나 프로시저와 같은 형태로 만들고, 각 프로시저들이 데이터를 조작하는 방식으로 코드를 작성한다. 이렇게 프로시저로 프로그램을 구성하는 기법을 절차 지향 프로그래밍이라 부른다. (절차 지향은 데이터를 중심으로 한 프로시저로 구성된다.)
각 프로시저는 데이터를 사용해서 기능을 구현하며, 필요에 따라 다른 프로시저를 사용하기도 한다. 또한 여러 프로시저가 동일한 데이터를 공유한다. 데이터와 그 데이터를 사용하는 프로시저를 작성하는 것은 자연스럽기에, 최초 구현은 어렵지 않다. 하지만 프로그램의 규모가 커져 데이터의 종류가 증가하고 이를 이용하는 프로시저가 증가하게 된다면, 다음과 같은 문제들이 발생하게 된다.
- 데이터 타입이나 의미를 변경해야 할 때, 함께 수정해야하는 프로시저가 증가한다.
- 같은 데이터를 프로시저들이 서로 다른 의미로 사용하는 경우가 발생한다.
위와 같은 문제를 비롯하여, 절차 지향적으로 프로그램을 구성하면 동일한 데이터를 공유한다는 문제점에서 비롯하여 연쇄적으로 여러 문제가 발생할 수 있다. 따라서 이는 새로운 요구사항에 대응하는 것이 어렵다. 이는 코드의 수정을 어렵게 하며 수정하는 데 많은 비용이 투입된다.
따라서, 우리는 flexible하지 않은 절차지향이 아닌 객체지향(데이터 및 데이터와 관련된 프로시저를 객체로 묶으며, 그 객체들이 모여 한 프로그램을 구성한다.)을 지향해야한다 !!!