객체지향 프로그래밍의 4대 원칙 (Four Principles of OOP)
쉽게 풀면
자동차를 생각해 봅시다. 운전자는 핸들과 페달만 조작할 뿐 엔진 내부 회로가 어떻게 동작하는지는 몰라도 됩니다(캡슐화·추상화). 그리고 "세단"이나 "트럭"은 모두 "자동차"라는 공통 설계를 물려받으면서 각자 다른 기능을 더합니다(상속). 또한 "출발" 버튼을 누르면 전기차는 모터가, 엔진차는 엔진이 돌아가듯, 같은 명령이라도 객체 종류에 따라 다르게 동작합니다(다형성). 이 네 가지 원칙은 코드를 자동차처럼 "필요한 조작만 노출하고 나머지는 감춘 채, 공통된 틀을 재사용하며, 상황에 맞게 다르게 반응하도록" 설계하기 위한 규칙들입니다.
왜 중요한가
소프트웨어공학 논문에서는 시스템의 유지보수성, 재사용성, 확장성을 평가할 때 이 네 원칙이 얼마나 잘 지켜졌는지를 설계 품질의 근거로 자주 제시합니다. 특히 대규모 시스템일수록 기능 추가나 변경이 다른 모듈에 미치는 영향을 최소화하는 것이 중요한데, 캡슐화·상속·다형성·추상화는 바로 이런 변경의 파급 효과를 통제하기 위한 기본 도구이기 때문에, 소프트웨어 아키텍처·설계패턴·리팩토링을 다루는 연구에서 이론적 근거로 반복해서 등장합니다.
논문에서는 이렇게 쓰입니다
이 문장은 "내부 구현을 감추고(캡슐화), 같은 인터페이스로 다양한 동작을 처리할 수 있게(다형성) 설계함으로써 코드 수정이 다른 부분에 영향을 덜 주게 만들었다"는 뜻입니다.
소프트웨어 품질 개선 연구에서는 4대 원칙을 적용한 리팩토링 전후로 정량적 코드 품질 지표가 어떻게 달라지는지를 비교합니다.
컴퓨터교육 연구에서는 4대 원칙 각각을 학습자가 얼마나 잘 이해하고 적용하는지를 교육 효과 측정의 대상으로 다룹니다.
조금 더 깊게 보면
네 원칙은 서로 독립적이라기보다 맞물려 작동하는 경우가 많습니다. 예를 들어 다형성은 상속이나 인터페이스 구현을 통해 공통 타입을 공유하는 여러 클래스가, 동일한 메서드 호출에 대해 각자 다르게 반응하도록 하는 방식으로 실현되며, 이는 추상화(공통 인터페이스만 남기고 세부 구현은 감추는 것)와 밀접하게 연결됩니다. 실제 설계 논의에서는 이 네 원칙을 그대로 적용하는 것보다, 이를 구체화한 SOLID 원칙이나 디자인 패턴(전략 패턴, 팩토리 패턴 등)을 함께 언급하며 원칙이 실제 코드 구조로 어떻게 구현되는지를 다루는 경우가 많습니다.
주의할 점
4대 원칙은 객체지향 프로그래밍 자체와 같은 말이 아닙니다. 객체지향 프로그래밍이 "객체 단위로 설계한다"는 큰 방향이라면, 4대 원칙은 그 방향을 실제로 구현하기 위한 세부 규칙에 해당합니다. 네 원칙을 형식적으로 흉내만 내고 실제로는 클래스 간 의존성이 뒤엉켜 있으면 원칙의 효과를 얻지 못합니다.