기어가더라도 제대로
20220224 - Struct vs Class 외 다수 본문
강의 필기를 블로그에 올린 내용입니다. 오류가 있을 수 있고, JK의 견해와는 다를 수 있습니다.
JK는 잘알려주셨으나 제가 잘못 이해한 것일 확률이 매우 높습니다.
type에 관하여
Int 형은 약 -20억 ~ 20억을 커버하는데 대다수 경우에는 그보다 작은 범위의 값을 사용한다. 그리고 디버그 시 효율을 위해 사용하고자 하는 변수에 좀 더 적합한 타입을 생각해보는 것이 중요하다.
예를 들어 학생 성적을 입력하는 타입을 만들고자 하면,
string으로 A~F 까지 작성하는 것보다는
enum Grade {
case A, B, C, D, E, F
}
이런식으로 작성하는 편이 낫다.
문자열의 일부를 가져오면
이것은 SubString이 된다. 이것의 타입은 String.subsequence
자기만의 라이브러리
패턴화와 분류, 재상용성을 신경 쓴 잘만든 클래스나 스트럭트를 다음에도 또 사용할 수 있도록 수련하자.
코드를 좀더 일반화 시키는 방법
제네릭이나 이런 것을 쓰는 것도 좋지만, 로직을 일반화 할 수 있는지가 포인트이다.
JK가 본인의 코드의 짤 때 흐름을 보여주셨는데, 라이브 코딩 비슷하게 하셨다. 하나의 공룡 스파게티를 만드는 것 보단, 입력을 위한 클래스, 출력을 위한 클래스, 모델링을 위한 클래스를 구분하고, 조금 더 코드의 일반화를 도와줄 수 있는 기법들, extension을 활용하는 등의 방법을 통해 공룡 클래스를 나누는 과정을 학습했다. 연습할 때 의식하며 코드를 짜는 것이 중요하겠다.
캡슐화
정보를 감추고, 정보 접근은 메서드로 추상화
몇가지 알고있으면 좋을 원칙들
* 기본 클래스 프로퍼티는 internal이 기본 속성인데, private으로 지정해주는 것이 좋다
* init으로 private 프로퍼티에 접근하는 것 정도는 좋다.
* 추상화란 하위에 있는 복잡한 코드들이 겉으로 안보여지는 것을 말한다.
* 접근하는 기능을 하위 클래스에서 구현하는 것이 좋다.
* 만약 클래스 내부에 배열을 저장할 일이 있으면, 따로 클래스를 빼서 다시 상위, 하위 관계로 만드는 것이 좋은 냄새가 나는 코드다
Class 타입 규칙
objC의 흔적이 남아 복잡해짐
생성자 상속과 재정의
struct의 경우에 init()을 생략하는 거지 안 사용하는 건 아님
다형성
오버라이드 한 부분이 있으면 상위 클래스보다 하위 클래스의 속성이나 메서드가 먼저 적용됨
예시) 바리스타가 커피를 내린다. (추상화, 혹은 일반화)
각각의 바리스타는 브루잉하는 스타일이나 커피콩을 볶는 스타일이 저마다 다르다.(다형성)
두 단계 초기화
편의 생성을 해도 수퍼 클래스의 생성자 규칙을 지켜야함
designate init : 일반적으로 사용하는 init
convienence init : 지정 생성자를 기반으로 수정을 가한 init, 더 사용하기 편리한 방향으로 수정됨.
캐스팅
- IS - a 관계 : 포함관계를 확인한다.
- I'm a boy. 에 비유가 가능하다.
- 나는 소년의 포함되는 개념이다.
- as - a 관계 : 변환할 수 있는지를 확인하는 키워드이다.
- He has deressed as a policeman .
- 경찰관 처럼 옷을 입은 남자.
업 캐스팅
하위 타입을 상위 타입으로 변환하는 것.
(다운 캐스팅은 부르는 개념도 명확하지 않고 사용할 수 도 없다.)
예시
food
- kimch
- cheese
김치를 푸드 타입으로 변환하는 것은 가능하지만, 푸드 타입의 인스턴스를 김치로 다운시키는 것은 불가하다.
그래서 보통 as 키워드는 ? 와 함께 사용하며, 실패 했을시 nil 반환을 대비한다.
메모리 관리
- 수동 메모리 관리(MRC) - objC 에서만 가능
- 자동 메모리 관리(ARC) - swift에서 지금도 잘사용하고 있음
retain Cycle
언제 어떻게 인스턴스나 변수가 메모리를 얻고 해제되는지 흐름을 이해해야 좋다.
memory 획득 {
선언시
함수 등 코드블럭안에서 선언시
}
메모리 반환 {
인스턴스에 nil값 입력시
class나 struct의 정의 자체를 삭제했을 시
함수 등 코드블럭이 끝났을 때
}
강한 참조, 순환참조 문제
강한 참조는 기본적으로, 구조체나 클래스 내부에서 채택하는 전략이다.
struct car {
var name : String
var wheelCount : Int
var owner: Person?
이런 샘플 코드가 있는데, car
구조체가 name과 같은 프로퍼티를 강한 참조하고 있는 것이다.
여기서 그 차의 주인이 현재 있을 수도 있고, 없을 수도 없는 상황에서, owner가 한번 정의 되면, owner값을 nil로 주지 않고, 인스턴스가 먼저 nil이 되면, 차는 폐차되어도, Person
을 메모리상에 여전히 참조하고 있는 상황이다. 이를 해결하기 위해 약한 참조를 사용한다.
struct car {
var name : String
var wheelCount : Int
weak var owner: Person?
이렇게 되면, car = nil
이 되면 자동으로 car.owner = nil
이 된다.
순환 참조 오류 샘플앱
순환 참조가 무엇이냐면, A 클래스에서 B를 참조하고, B 클래스에서 A를 참조하는 것으로 알고 있는데 정확하지는 않다.
JK_GitHub
느낀점
잘 이해하고 있는지 모르겠어서 정리를 했는데 오류 투성이 인 것 같다. 6개월 후에 스스로를 코드 스쿼드 멤버라고 소개할 수 있을런지 두렵다.
'기타' 카테고리의 다른 글
객체지향적으로 사고를 해보자 (from 2022.03.07 강의, 코드스쿼드) (0) | 2022.03.07 |
---|---|
객체지향의 사실과 오해 - 1 - (0) | 2022.03.04 |
AppElements (0) | 2022.02.21 |
GitHub Gist를 원격에서 편집하기 (feat. git) (0) | 2021.12.31 |
(4) Git&GitHub [ch.3] 여러 명이 함께 Git으로 협업하기 (0) | 2021.11.23 |