[Android] 애플리케이션 앱설계와 원칙은?

안녕하세요~ 헬창코딩입니다. 오늘은 최근에 안드로이드 설계를 공부하면서 좋은 책을 하나 알게 되었어요~~

https://book.naver.com/bookdb/book_detail.nhn?bid=16327417 

아키텍처를 알아야 앱 개발이 보인다

기본적인 앱 설계에 대한 지식들을 공부할 수 있게 도와준 책입니다.!!! 하여튼 

이 책을 참고해서 안드로이드 앱 설계와 원칙을 알아볼게요~~~

 

 

1.  애플리케이션 설계

애플리케이션 설계란? -> 구성요소들 사이에서 유기적 관계를 표현하고, 요구사항을 해결하는 계획 과정 등의 원칙

설계에 대한 설명은 주로 텍스트나 그림, 다이어그램 등 다양한 형식을 취함.

 

그럼 굳이 애플리케이션 설계에 신경을 쓰는 이유는 무엇일까요?

애플리케이션은 만들고 나면 유지보수나 수정하는데 비용이 많이 듭니다. 그 이유는 안드로이드 정책이 변경되고 시장의 요구사항이 

지속적으로 변화하기 때문입니다. 그리고 앱은 점점 더 커지기 때문에 나중에는 유지보수에 더욱 큰 비용이 발생하게 되는 거죠 

이때 잘 만들어진 앱은 유지보수비를 줄여주고 성능, 안정성, 보안 등에 많은 도움을 줍니다. 

 

 

 

2. 애플리케이션의 설계 원칙은?

애플리케이션의 설계 원칙은 2000년대 초반 로버트 c. 마틴이 객체 지향 프로그래밍 및 설계에 대한 SOLID라는 5가지 원칙으로 합니다.(SOLID는 5가지 원칙의 각 원칙의 머리글자를 따와 만든 명칭입니다.)

 

 

 

 

단일 책임원칙(Single Responsibility Principle)

  - 객체 지향 프로그래밍에서 단일 책임원칙은 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 말합니다.

    그 말은 즉슨 단일 책임은 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 한다는 뜻입니다.  이렇게 설계되면 변경사항이 발   생하더라도 그 변경사항에 대한 책임이 있는 부분만 수정하면 됩니다.

 

 개방-폐쇄 원칙(Open Closed Principle)

  - 개방 폐쇄 원칙은 소프트웨어가 확장에 대해서는 열려 있어야 하고 수정에 대해서는 닫혀 있어야 한다는 원칙입니다. 즉 개방 폐쇄 원칙은 시스템의 구조를 올바르게 구성하여 변경 사항이 발생하더라도 다른 코드나 모듈에 영향이 없도록 하는 것입니다. 개방 폐쇄 원칙이 잘 적용된 경우, 새로운 기능을 추가하거나 기존 기능을 변경하기가 좋아집니다.

    -> 객체지향 프로그래밍의 핵심 원칙!! 이 원칙을 무시하고 객체지향 언어 구현이 가능하긴 하지만 재사용성, 유지 보수성, 유연성을 얻을 수 없습니다. 반드시 지켜야 하는 원칙입니다!!

 

 리스 코프 치완 원칙(Liskov Substitution Principle)

   - 치환성은 객체 지향 프로그래밍 원칙입니다. 클래스 S가 클래스 T의 자식 클래스라면 별다른 변경 없이 부모 클래스 T를 자식 클래스 로 치환할 수 있어야 하는 원칙입니다. 즉 다운 캐스팅된 인스턴스가 논리적으로 그 역할이 문제없어야 합니다.

     

     리스 코프의 원칙은 객체 지향 프로그래밍 특징에 관한 몇 가지 표준적인 요구 사항을 강제합니다. 

   

        1. 하위 클래스에서 메서드 파라미터의 반공 변성

        2. 하위 클래스에서 반환형의 공변성 

        3. 하위 클래스에서 메서드는 상위 클래스 메서드에서 던져진 예외 사항을 제외하고 새로운 예외 사항을 던지면 안 됨 

        4. 하위 클래스에서 선행조건은 강화될 수 없음

        5. 하위 클래스에서 후행 조건은 약화할 수 없음 

        6. 하위형에서 상위형의 불변 조건은 반드시 유지되어야 함

 

      

   예시) 다음과 같이 차례로 상속받는 타입이 있다고 가정하면

    A <- B <- C 

    public class A {}

    public class B extends A {}

    public class C extends B {}

 

   공변성 -> List <? extends B> 란 B를 상속받는 타입으로 이루어진 리스트가 있다면  List <C> List <C>를 사용할 수 있다는 내용입니다.

   반공 변성 -> List <? extends B>란 리스트가 있을 때 List <A>를 사용할 수 있다는 점이다. 물론 A의 가능합니다

 

 

인터페이스 분리 원칙(Interface Segregation Principle)

    - 인터페이스 분리 원칙이란 어떠한 클래스가 자신이 이용하지 않는 메서드에 의존하지 않아야 하는 원칙입니다

    - 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리함으로써 클래스들이 꼭 필요한 메서드들만 이용할 수 있게 합니다.

    - 역할 인터페이스 : 작은 단위로 메서드 들로 구성된 인터페이스를 말합니다.

    - 인터페이스 분리 원칙을 이해하기 위해 독수리를 클래스로 표현하는 예제를 들어 볼게요~

     

 

가장 먼저 Bird라는 추상클래스르 만들어서 새의 울음소리를 내고 날 수 있는 기능을 가진 메서드를 만든 뒤에 Bird를 상속받은 Eagle을 만들었습니다. 이때 Penguin을 만든다면 펭귄은 새지만 날지 못하므로 fly() 메서들를 가지면 ISP 인터페이스 분리 원칙에 어긋날 수 있습니다. 그래서 수정을 해야 합니다.

      public abstract class Bird{
          abstract void fly();
          abstract void cry();
      }
      public class Eagle extends Bird{
          @Override
          public void fly(){...}
          @Override
          public void cry(){...}
      }

        

fly() 메서드를 인터페이스로 분리하고 날 수 있는 새에만 구현함으로써 펭귄은 사용하지 않는 fly() 메서드를 가지지 않을 수 있어 ISP원칙을 지킬 수 있게 되었습니다. 

      public abstract class Bird{
      	abstract void cry();
  	  }
      public interface Flyable{
          void fly();
      }
     
     public abstract class FlyableBird extends Bird 				
      
      implements Flyable{
          ...
      }
      public class Eagle implements FlyableBird{
          @Override
          public void fly(){...}
          @Override
          public void cry(){...}
      }
      public class Penguin extends Bird{
          @Override
          public void cry(){...}
      }

 

 

의존 역전 원칙(Dependency Inversion Principle)

 - 모듈들을 분리하는 특정 형식을 지칭합니다. 

 - 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 역전함으로써 상위 계층이 하위계층의 구현으로부터 독립되게 할 수 있게 되었습니다.

 

- 다음과 같은 원칙을 갖고 있다 

      1) 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 합니다.

      2) 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 합니다.

          -> 상위와 하위 모두가 동일한 추상화에 의존해야 합니다. 는 객체 지향적 설계의 대원칙을 제공합니다.

 

 - 예시 1) 예전의 폰은 폰마다 전용 충전기가 존재했습니다. 전용 충전기 외의 다른 충전기는 호환되지 않았는데 이 기기는 전용 충전기에 강한 의존성을 가진다고 할 수 있습니다.

 

                  안드로이드 기기  -->  전용 충전기 

 

 - 예시 2) 요즘 안드로이드 폰은 C 타입 단자라면 어느 제조사의 것을 끼워도 호환이 됩니다. 전용 충전기가 필요가 없으며  어는 제조사의의 것을 끼워도 잘 동작한다 이는 C 타입을추상화시켜서기기가 특정 충전기에의존하던 것을인터페이스를 통해 의존성을역전 시킨 것입니다.

                                                      

                  안드로이드 기기 --> c타입 충전기  --> s사 충전기 , l사 충전기, x사 충전기

 

 

오늘은 애플리케이션 앱 설계와 원칙을 알아봤는데 다음 시간에는 안드로이드 앱 설계를 알아볼게요~