일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 알고리즘
- Linked List
- struct
- 비동기
- 동기화
- IOS
- COLOR
- 동시성
- 오브젝트
- 인프런
- 운영체제
- 가상 메모리
- scrollview
- UserDefaults
- 100 days of SwiftUI
- 프로세스 스케줄링
- decode
- 데드락
- Codable
- async
- SwiftUI
- 앨런
- forEach
- Apple Developer Academy
- Algorithm
- deadlock
- Swift
- 상호배제
- core data
- @state
- Today
- Total
기어가더라도 제대로
객체지향적으로 사고를 해보자 (from 2022.03.07 강의, 코드스쿼드) 본문
강의를 바탕으로 정리한 내용입니다.
코드스쿼드의 견해와 다를 수 있으며 오류가 있을 시 전적으로 저의 무지에서 비롯된 것입니다.
양해바랍니다.
# Swifty 객체지향 프로그래밍
객체지향이 어려운 이유
사물을 대하는 관점이 동서양이 다르다. 동양은 어떤 물체를 자신과 동일시하고, 서양에서는 어떠한 물체를 대상화 한다. 동양은 표현 중심적인 반면, 서양은 개념 중심적이다. 같은 실체를 보고도 이런 차이를 보인다.
위의 사진은 "윗면이 평평하고 다리가 있는 물건"이다. 이는 책상을 개념적으로 풀어 쓴 것이고, 이 개념을 표현하면 "책상"이 된다. 다시 말하면 서양인들은 중간의 동그라미 처럼 생각을 하고, 우리는 가장 오른쪽 "책상"으로 생각하기 때문에, 개념적으로 설명하는 객체지향을 이해하기 어렵다고 합니다.
추상화와 개별화
먼저 추상화는 대상을 생략하거나 간추려 요약하는 것이다. 또는 단순화되거나 대표성을 띄는 것이기도 하다. 눈에 보이는 사물을 재현하지 않고, 단순화한 구조로 표현하는 것이다. 위의 [그림1]에서 사진을 개념으로 설명하는 것이 추상화이다. 그렇다면 반대로 개별화는 개념을 바탕으로 실제적으로 구현해내는 것이 개별화이다. 조금 프로그래밍 적으로 보자면 아래와 같다.
class Desk { // - 추상화
var name: String
init(name: String) {
self.name = name
}
}
var oakDesk: Desk = Desk(name: oak) // - 개별화
책상의 성질이 어디 이름만 있진 않을 것이다. 강도나, 심재를 사용했는지, 몇년 생 나무를 썻는지, 어느 계절에 벌목을 했고, 얼마나 건조를 한 나무를 사용하는지, 가격은 얼마인지, 배송비는 포함인지 등 나열하자면 끝도 없다. 하지만 이를 심플하게 추상화하면, 대략 위의 코드와 같다.
예전의 코드와 추상화 시도
예전엔 이렇게 날것의 상태로 코드를 짰더라면, 이를 추상화하기 위한 시도가 있었다. 첫째는 공통이 되는 기능들의 순서를 묶어 함수화하는 것이 초창기 추상화 시도 중에 하나이다. 이제 두 번째 추상화 시도는 절차 뿐만 아니라 타입도 추상화해서 이를 Classification하도록 묶는 경향이다. 오늘의 수업은 이 클래스들을 어떻게 분리하고, 어느 기준으로 묶고, 그들간의 의존성을 어떤식으로 낮출 수 있는지에 대한 수업이였다. 주로 토끼책에 많은 영감을 받았는데 역할과 책임과 협력의 기준에 따라 인스턴스를 나누는 걸 추천합니다. 그게 객체지향이라고 하고요. 다음 문구는 객체지향을 한 줄로 추상화하면 이렇게 되는 것 같습니다. (메서드에게 명령을 내리는 것이 메시지이고요.)
객체 속성을 가져오지 말고
객체가 일하도록 메서드로 시켜라
# 객체 설계 원칙 - SOLID 😱
1. SRP (Single-Responsibility Principle) 소프트웨어 요소(클래스, 모듈, 함수)는 응집된 하나의 책임을 갖는다 ⇒ 클래스를 변경하는 이유는 반드시 응집도여야 한다
2. OCP (Open-Close Principle) 소프트웨어 요소는 확장 가능하도록 열려있고, 변경에는 닫혀있어야 한다 ⇒ 새 기능을 추가할 때 변경하지 말고 새 클래스 나 함수를 만들어서 변경하거나 영향을 받는 부분을 최소화한다
3. LSP (Liskov Substitution Principle) (상속받은) 서브타입은 (상위)기본 타입으로 대체가능해야 한다. 자식 클래스는 부모 클래스 동작(의미)를 바꾸지 않는다
4. ISP (Interface-Segregation Principle) 클라이언트 객체는 (구체 타입 또는 추상화된 인터페이스든) 사용하지 않는 메소드에 의존하면 안된다
5. DIP (Dependency-Inversion Principle) 상위레벨 모듈은 하위레벨 모듈에 의존하면 안된다 ⇒ 둘 다 추상화된 인터페이스에 의존해야 한다 추상타입은 구체타입에 의존하면 안되고, 구체타입는 추상타입에 의존해야 한다.
(출처: 코드스쿼드 내부 자료)
... 라고 합니다.
'기타' 카테고리의 다른 글
네트워크 프로그래밍 (0) | 2022.04.07 |
---|---|
220310. Protocol 외 다수 (0) | 2022.03.10 |
객체지향의 사실과 오해 - 1 - (0) | 2022.03.04 |
20220224 - Struct vs Class 외 다수 (0) | 2022.02.24 |
AppElements (0) | 2022.02.21 |