💡 객체 지향 프로그래밍이란?
객체 지향 프로그래밍은 컴퓨터 프로그래밍의 패러다임중 하나로, 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고, 그 객체들 간의 유기적인 상호작용을 통해서 로직을 구성하는 프로그래밍 밥법이다.
위의 그림에서 보면 알 수 있듯이 절차지향은 프로그램 순서와 흐름이 중점이 되고, 객체지향은 객체가 중점이 된다.
즉, 절차지향 프로그래밍은 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방식이라면,
객체지향 프로그래밍은 자료구조와 이를 중심으로 한 모듈들을 먼저 설계한 다음에 이들의 실행 순서와 흐름을 짜는 방식인 것이다.
💡 객체 지향 프로그래밍의 장단점
- 장점
- 코드 재사용이 용이하다 ← 남이 만든 클래스를 가져와서 이용할 수 있고 상속을 통해서 확장해서 사용할 수 있다.
- 유지보수가 쉽다 ← 절차 지향 프로그래밍에서 코드를 수정해야 할 때 일일이 찾아서 수정해야 하는 반면 객체 지향 프로그래밍에서는 수정해야 할 부분이 클래스 내부에 멤버 변수 혹은 메서드로 존재하기 때문에 해당 부분만 수정하면 된다.
- 대형 프로젝트에 적합하다 ← 클래스 단위로 모듈화시켜 개발할 수 있으므로, 대형 프로젝트처럼 단위가 큰 프로젝트에서 개발 시 업무 분담에 용이하다.
- 단점
- 처리 속도가 상대적으로 느리다.
- 객체가 많아지면 용량이 커질수 있다.
- 설계 시 많은 시간과 노력이 필요하다.
💡 객체지향 프로그래밍의 특징
- 클래스 + 인스턴스
- 클래스 ← 변수와 메서드로 정의되어 있는 것(액티비티가 될 수도 있고 모든 클래스가 될 수 있다)
- 인스턴스 ← 클래스가 실제 메모리상에 할당하여 사용되는 데이터
- 추상화 ← 핵심적인 개념이나 기능만 추려내서 나타내는 것
- 캡슐화 ← 서로 연관성이 있는 멤버변수, 메서드를 하나의 클래스로 묶어주는 것
- 상속 구조 ← 부모 클래스의 속성과 기능을 그대로 사용할 수 있으며, 일부를 변경하거나 수정이 가능한 것.
- 다형성
- 오버로딩 ← 메서드의 이름은 같으나, 필요한 매개변수의 개수나 데이터 타입이 다른 경우
- 오버라이딩 ← 자식 클래스에서 부모 클래스에서 만들어진 메서드를 다시 재정의하여 사용하는 것
💡 애플리케이션 앱 설계와 원칙
- Android - 객체지향설계
- 애플리케이션의 설계 원칙은 로버트 c.마틴이 객체 지향 프로그래밍 및 설계에 대한 SOLID라는 5가지 원칙으로 한다.
- 단일 책임 원칙(Single Responsibility Principle)
- 객체 지향 프로그래밍에서 단일 책임원칙은 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 한다.
- 즉, 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 한다.
- 이렇게 설계되면 변경사항이 발생하더라도 그 변경사항에 대한 책임이 있는 부분만 수정하면 된다.
- 개방-폐쇄 원칙(Open Closed Principle)
- 개방 폐쇄 원칙은 소프트웨어가 확장에 대해서는 열려 있어야 하고 수정에 대해서는 닫혀 있어야 한다는 원칙이다.
- 즉, 시스템의 구조를 올바르게 구성하여 변경 사항이 발생하더라도 다른 코드나 모듈에 영향이 없어야 한다.
- 이렇게 설계하게 되면 새로운 기능을 추가하거나 기존 기능을 변경하기 좋아진다.
- 이 원칙을 무시하고 객체지향 언어 구현이 가능하긴 하지만 재사용성, 유지 보수성, 유연성을 얻을 수 없으므로, 반드시 지켜야 하는 원칙이다.
- 리스 코프 치환 원칙(Liskov Substitution Princle)
- 치환성은 객체 지향 프로그래밍이 원칙이며, 자식 클래스는 별다른 변경 없이 부모 클래스를 자식 클래스로 치환할 수 있어야 한다는 원칙이다.
- 즉, 다운 캐스팅된 인스턴스가 논리적으로 그 역할이 문제가 없어야 한다.
- 리스 코프 원칙은 객체 지향 프로그래밍 특징에 관한 몇 가지 표준을 요구한다.
- 하위 클래스에서 메서드 파라미터의 반공 변성
- 하위 클래스에서 반환형의 공변성
- 하위 클래스에서 메서드는 상위 클래스 메서드에서 던져진 예외 사항을 제외하고 새로운 예외 사항을 던지면 안 된다.
- 하위 클래스에서 선행조건은 강화될 수 없다.
- 하위 클래스에서 후행 조건은 약화할 수 없다.
- 하위형에서 상위형의 불변 조건은 반드시 유지되어야 한다.
- ex) A ← B ← C 차례로 상속받는 타입이 있다고 할 경우
- public class A {}
- public class B extends A {}
- public class C extends B {}
- 인터페이스 분리 원칙(Interface Segregation Principle)
- 인터페이스 분리 원칙이란 어떠한 클래스가 자신이 이용하지 않는 메서드에 의존하지 않아야 하는 원칙이다.
- 즉, 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리함으로써 클래스들이 꼭 필요한 메서드들만 이용할 수 있게 된다.
- 역할 인터페이스 : 작은 단위로 메서드들로 구성된 인터페이스를 말한다.
// 잘못된 예시
public abstract class Bird{
abstract void fly();
abstract void cry();
}
public class Eagle extends Bird{
@Override
public void fly(){...}
@Override
public void cry(){...}
}
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)
- 모듈들을 분리하는 특정 형식을 지정합니다.
- 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 역전함으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있게 된다.
- 원칙은 아래와 같다.
- 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
- 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다. ← 상위와 하위 모두 동일한 추상화에 의존해야 한다.
- 이전에 구글에서 권장했던 Android 개발 권장
- Activity 또는 Fragment는 단지 ViewModel 만을 참조한다. ← ViewModel 만 참조하여 ViewModel 에서 하위 계층의 의존성이 어떻게 변경되는 Activity 나 Fragment 는 관심이 없어야 한다.
- ViewModel 은 Repository라는 저장소를 참조하고 이 저장소로부터 Ui 컴포넌트가 화면을 구성하는데 필요한 데이터를 불러온다. ← 데이터를 불러와서 LiveData라는 데이터의 변화를 감지할 수 있는 형태로 관리한다.
- 저장소는 2가지 타입의 모델을 참조한다.
- 네트워크 연결이 필요 없는 내부(Local) 모델 (Sqlite, Room 등 내장 DB)
- 서버에서 데이터를 불러오는 원격(Remote) 모델 (Retrofit2, volly 등 서버와의 통신)
- ViewModel 은 내부 데이터베이스만을 항상 참조하고, 클라이언트의 데이터베이스와 서버의 데이터베이스가 요청으로 비동기적으로 동기화한다.
참고
'Develop > Kotlin' 카테고리의 다른 글
[kotlin] Android 4대 컴포넌트 (2) | 2023.08.30 |
---|---|
[kotlin] 코틀린 기본 문법 (0) | 2022.12.06 |
[kotlin] 코틀린이란 무엇인가? (0) | 2022.12.02 |
[kotlin - Error] 코틀린 Android Error inflating class com.google.android.material.button.MaterialButton (0) | 2022.05.09 |
[kotlin] 코틀린 Android MVVM Retrofit(BE 연결) 구현 (0) | 2022.05.01 |