1. 기능 중심의 프로그래밍
개발을 하게 되면 고객과 개발자의 주요 관심사는 기능이 된다. 물론 기능 구현은 중요하지만 유연한 소프트웨어와 빌드 자동화 같은 개발환경 역시 중요한 요소이다. 하지만 많은 개발자들은 오직 구현에만 신경을 쓴다. 기능을 빠르게 구현하는것도 중요하지만 개발자라면 더 좋은 소프트웨어를 만들기 위한 관심을 갖고 적절한 노력을 추구해야 한다. 기능 중심 개발을 코드 품질 저하를 야기한다. 기능 중심적 코딩을 하게 되면 유지보수, 확장성 등을 고려하지 못하게 된다. 따라서 코드가 지저분해지고 품질이 하락한다.
기능중심 프로그래밍은 다음과 같은 부작용을 가지고 있다.
1. 코드의 중복
버그가 생겨 수정을 해야되면 중복된 코드를 모두 수정해야한다.
2. 코드 속성의 과도한 노출
캡슐화 등 oop의 권장 사항을 지키지 않게 되면 한 코드(클래스)의 변수(속성)들을 외부에서 접근할 수 있는 등의 문제가 생긴다
3. 코드 행동(메서드)의 과도한 노출
모듈 간의 결합도를 낮추기 위해선 외부에 노출할 메서드와 그렇지 않는 메서드를 구분해야 한다.
4. 코드 배치에 일관성이 없다
코드 배치는 코드의 속성, 메서드, 로직이 각각 제 역할에 맞게 언어에서 권장되는 방식으로 배치되야 하지만 기능 중심 구현은 수단을 가리지 않는다.
5. 코드 가독성 저하
코드는 읽기 쉬워야 하며 이를 위해 주석, 객체지향적으로 속성, 메소드를 배치하고 로직 길이를 간결하게 유지해야한다.
6. 코드의 의존성이 증가한다
코드 속성, 메서드가 과도하게 노출되면 다른 코드들이 쉽게 접근해서 지나치게 의존한다.
7. 사이드 이펙트가 증가한다
사이드 이펙트는 하나의 코드를 수정했을 때, 수정한 코드와 연결된 또 다른 코드에서 버그를 일으키는 것을 의미한다.
8,코드의 재사용이 어렵다
모듈화된 코드를 다른 요구사항에 적용할 수 있을때 개발자는 편해진다. 기능 중심 프로그래밍은 품질저하로 인해 재사용이 어렵다
9. 코드 수정, 추가 개발, 디버그가 어려워진다.
소프트웨어의 수명이 다할때 까지는 수많은 수정(확장, 버그 수정 등)이 가해진다. 기능 중심 프로그래밍은 코드 품질 저하로 가독성 하락, 사이드 이펙트 발생 등이 야기된다.
10. 유지보수와 고도화 프로젝트에 지장이 있다
고객은 유지보수 보다 개발 완성에 더 신경을 쓴다. 이렇게 개발을 하다 보면 유지보수 단계에서의 비용 증가로 이어진다. 저품질의 소프트웨어의 유지보수는 효율성이 낮기 때문이다. 만약 고도화 프로젝트라는 이름으로 소프트웨어의 기능, 디자인을 크게 바꿀때는 추가적인 유지보수가 불가능해 아예 새로운 프로젝트로 시작할 수 도 있다.
2. 유연한 소프트웨어는 코드 품질의 향상이다.
개발을 할때는 다음과 같이 구현을 해야한다
고객이 원하는 소프트웨어 = 고객이 원하는 기능의 정확한 구현 + 유연한 구성
유연한 소프트웨어는 기능 중심 프로그래밍과 상반된 특징을 가지고 있다.
1. 코드 중복이 거의 없다
2. 코드 속성과 메소드의 캡슐화가 잘 되어 있다
3. 코드 배치의 일관성이 잘 지켜졌다
4. 코드 가독성이 좋다
5. 코드 의존성이 낮다
6. 사이드 이펙트의 감소
7. 코드 재사용이 쉽다
8. 코드 수정, 추가, 디버그가 수월하다
9. 유지보수와 고도롸 프로젝트 하기 좋다.
3. 좋은 소프트웨어를 만들기 위한 권고사항
'관계의 의존성은 낮게, 기능의 집중도는 높게'
위 말의 의미는 모듈이 기능을 할때 다른 모듈에 적게 의존해야하고 하나의 모듈은 되도록 하나의 기능만을 해야한다는 의미이다. 여기서 관계의 의존성이 낮으면 기증의 집중도가 높아지고 기능의 집중도가 높으면 관계의 의존성이 낮아진다.
4. 객체지향의 정의와 목표
정의: 객체지향은 낮은 관계의 의존성과 높은 집중도를 지향하여, 소프트웨어의 유연함을 극대화하는 개발 기법이다.
객체를 만들때 하나하나의 객체의 구현에 대한 신경을 쓰기 보다는 객체간의 관계에 신경써야한다. 객체지향을 통해 유연한 소프트웨어를 얻기 위해서는 다음 2가지를 추구해야 한다.
1. 로직 구현보다는 객체가 외부에 노출하는 인터페이스를 잘 설계하는 것
2. 객체지향적으로 리팩토링 하면서 객체 내부와 객체간의 관계를 깔끔하게 정리하는 것.
Single Responsibility Principle
1. 객체는 유일하며 다른 객체와 구별 가능하다
2. 이런 정의는 객체에 구현된 코드에도 적용되어야 한다.
3. 객체가 구현한 코드도 유일하며 다른 객체와 구별되는 특징을 가져야 한다.
4. 객체는 자신이 제일 잘할 수 있는 독립적인 책임(기능)을 가져야 한다.
5. 클래스와 메소드는 한 가지 종류의 책임만을 다음과 같이 수행해야 한다.
그 책임에 해당하는 일을 모두 한다
그 일을 다른 클래스나 메소드 보다 더 잘한다
그 일을 자신만이 유일하게 한다
6. 결론은 '객체가 하나의 일만 수행하게 하라'이다.
출처 - 한번 읽으면 두번 깨닫는 객체지향 프로그래밍
'programming' 카테고리의 다른 글
객체지향 구현 원리 5가지 - SOLID (0) | 2021.03.07 |
---|---|
객체지향의 근본 조건 (0) | 2021.03.06 |
객체지향의 기본 요소 5가지 (0) | 2021.03.05 |
명령형(Imperative) 프로그래밍과 선언형(Declarative)프로그래밍 (0) | 2021.01.22 |
API(Applicatino Programming Interface) (0) | 2021.01.11 |