안드로이드 애플리케이션 설계
애플리케이션 설계란?
애플리케이션 설계는 구성 요소들 사이에서 유기적 관계를 표현하고, 요구 사항을 해결하려는 계획 과정 등의 원칙을 나타낸다고함. 설계에 대한 설명은 주로 텍스트나 그림, 다이어그램을 비롯한 다양한 형식을 취함.
애플리케이션은 우선 구현되고 나면 변경하는 데 비용이 많이 듬. 시간이 지남에 따라 안드로이드의 정책이 바뀌고, 시장의 요구 사항이 변경되어 애플리케이션에 대한 지속적인 유지보수가 필요하게 되는데, 이때 애플리케이션도 점점 거대해져 유지보수는 점점 커질 수 밖에 없음. 잘 설계된 애플리케이션은 유지 보수비를 줄요 주고, 성능, 보안, 안정성 등의 측면에서 많은 이점이 있다 라고함.
애플리케이션 설계에는 끊임없는 노력이 필요하다. 변ㄹ화에 대응하지 않고, 시간이 흐르면 아무리 잘 설계된 앱도 무너질 수밖에 없다. 예를 들어, 안드로이드 앱을 잘 만들어서 배포를 마친 상태인데, 이에 대해 유지보수를 하지 않는다면 이후에 나오는 안드로이드 플랫폼 버전과 호환되지 않거나 마켓 정책상의 이유로 앱이 제 기능을 하지 못할 것이다. 따라서 애플리케이션 설계에서 가장 중요한 점은 개발자가 이러한 설계 및 유지 보수에 대해서 지속해서 고민하고 발전시키려는 의지 라고 한다.
애플리케이션의 설계 원칙
좋은 애플리케이션 설계를 위해서는 어떠한 원칙을 정하고, 그것을 기반으로 프로그램을 작성한다면 적어도 원칙 없이 작성한 코드보다는 더 나은 결과물을 볼 수 있다. 2000년대 초반 로버트 C. 마틴이 객체 지향 프로그래밍 및 설계에 대한 SOLID라는 5가지 원칙을 소개한 바 있다. SOLID 원칙은 5가지 원칙에서 각 원칙의 머리글자를 따와 만든 명칭이다. 유지 보수와 확장이 쉬운 애플리케이션을 만들려고 할 때 이 원칙을 적용할 수 있다. 코드의 가속성을 높이고 확장이 쉬운 구조를 만드는 지침이다. 각 원칙이 무엇인지 살펴본다.
단일 책임 원칙(Single Reponsibility Principle)
객체 지향 프로그래밍에서 "단일 책임 원칙"이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야함.
단일 책임은 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 한다는 뜻이다. 즉 변경 사항이 발생하더라고 그 변경 사항에 대한 책임이 있는 부분만 수정하면 된다. 예를 들어서 특정 데이터를 분석하고 서버에 전송하는 모듈을 생각해 보면, 이 모듈은 두 가지 이유로 변경될 수 있다. 첫 번째로 데이터를 분석하는 알고리즘 때문에 변경될 수 있다. 두 번째로 실제로 분리된 두 책임 때문이며, 따라서 분리된 클래스나 모듈로 나누어야 한다. 다른 시기에 다른 이유로 변경되어야 하는 두 가지를 묶는 것은 나쁜 설계일 수 있다.
개발-폐쇄 원칙(Open Closed Principle)
계방-폐쇄 원칙(OCP, Opeb-Closed Principle)은 소프트웨어가 확장에 대해서는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다는 원칙이다.
어떠한 내용을 수정하기 위해 연관된 다른 코드나 모듈까지 수정하는 것은 어렵고 난감하다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 구성하여 변경 사항이 발생하더라도 다른 코드나 모듈에 영향이 없도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용된 경우, 새로운 기능을 추가하더나 기존 기능을 변경하기가 용이해진다.
개방-폐쇄 원칙은 객체 지향 프로그래밍의 핵심 원칙이라고 할 수 있다. 개방-폐쇄 원칙을 따르지 않는다고 해서 객체 지향 언어 구현이 불가능한 것은 아니지만, 이 원칙을 무시하고 프로그래밍을 한다면 객체 지향 프로그래밍의 가장 큰 장점인 유연성, 재 사용성, 유지 보수성 등을 결코 얻을 수 없다. 따라서 객체 지향 프로그래밍 언어에서 개방-폐쇄 원칙은 반드시 지켜야 할 기본적인 원칙이다.
리스코프 치원 원칙(Liskov Substitution Principle)
치환성은 객체 지향 프로그래밍 원칙이다. 클래스 S가 클래스 T의 자식 클래스라면 별다른 변경 없이 부모 클래스 T를 자식 클래스 S로 치환할 수 있어야 한다는 원칙이다. 즉 다운 캐스팅된 인스턴스가 논리적으로 그 역할이 문제 없어야 한다. 리스코프의 원칙은 객체 지향 프로그래밍 특징에 관한 몇 가지 표준적인 요구사항을 강제한다.
하위 클래스에서...
- 메서드 파라미터의 반공변성
- 반환형의 공변성
- 메서드는 상위 클래스 메서드에서 던져진 예외 사항을 제외하고 새로운 예외 사항을 던지면 안 됨
- 선행 조건은 강화될 수 없음
- 후행 조건은 약화할 수 없음
- 하휘형에서 상위형의 불변 조건은 반드시 유지되어야 함.
다음과 같이 차례로 상속받는 타입이 있다고 가정해보자.
A ← B ← C
class A { }
class B: A() { }
class C: B() { }
공변성의 예를 들면, 현재 객체에서 B를 상속받고 있다면, 이를 상속받고 있는 C를 사용 할수 있어야한다.
반공병성의 예를 들면, 현재 객체에서 B를 상속받고 있다면, A를 사용 할수 있다는 것과 A로 치환도 가능하다.
불변성은 위의 공변성과 반공변성을 허용하지 않는 경우임