Swift TIL(33)

웰디(Well-D)·2023년 9월 21일
0

Sweet & Soft, SWIFT

목록 보기
31/76

복습

확장과 함께하는 하루..

클래스의 확장, 구조체의 확장으로 구분지을 수도(!) 있을 것 같지만 우선 확장이 가능한 요소들과 아닌 요소들로 나눌 수 있다.

확장이 가능하지 않은 것은 저장속성, 확장이 가능한 것은 함수처럼 동작하는 모든것..이라고 생각하면 편한데 정확히는 타입계산속성,(인스턴스)계산속성,메서드,새로운 생성자, 서브스크립트 , 중첩타입으로 사용할 경우, 프로토콜 관련 메서드, 채택 등등 이다.
사실 확장이라는게 일종의 기능, 동작을 추가한다는 개념으로 보면 좀 더 쉽게 이해할 수 있을 것같다(당연히 저장속성같은 데이터는 nope)

인상깊었던 부분은 소급모델링 이라 칭하는 부분인데, 즉 swift에 원래 구현되어있는 구조체나 클래스를 커스터마이징 해서 사용하는 것이다. 예를들어 Int 구조체를 확장해서 계산속성을 좀 더 복잡하게 넣는다거나..내맘대로 메서드를 만들어서 사용해볼수 있다.
계산속성으로 구현하면 심지어 좀 더 멋지게(?) 점접근자로 커스터마이징한 기능을 구현할 수 있는 장점도 있다.

그리고 좀 더 기억하면 좋은 것.
리터럴값.계산속성 혹은 리터럴값.메서드(아규먼트: 값)이 가능하다는 것
예를들어 "honeySweet".customCaculator 이런식으로 리터럴 string값에 직접 계산속성인 customCaculator을 사용할 수 있다. 이것도 멋진(?)부분

단 주의해야할 점은 상위클래스에서 확장한 타입에서 추가구현한 메서드는 재정의 할 수 없다. 메서드 디스패치에서 더 정확히 다루게 되겠지만 아예 메서드 테이블로 새로 추가구현한 메서드가 삽입되는 구조가 아니기때문이다

또 메서드에서 주의하면 좋은 점(구조체의 메서드)
구조체의 메서드는 스스로의 속성 변경이 불가한데 속성변경을 원한다면 mutating 키워드를 메서드 앞에 써주고 그 안에서 속성변경을 해줘야한다. 개인적으로 정리해보니 이렇게 스스로의 속성변경하는 방법을 구현하는게 일단 한 세가지 정도가 있는데, 각각 사용할 수 있는 방법이 달라서(어떤건 리터럴로는 접근이 안되고, 꼭 변수를 선언해서 불러줘야하고 등) 비교해서 익숙해지면 좋을 것 같다.

생성자가 가장 헷갈리기 쉬운 부분인 듯 한데,
생성자의 확장의 경우 클래스는 편의생성자만 확장형에서 구현가능하고, 구조체의 경우 제약이 거의 없다고 보면 된다. 물론 클래스와 구조체 둘다 내부에서 본래타입의 생성자를 호출해야하는 공통점은 있지만, 조금 특이한 것은 구조체는 원래 생성자를 구현해주면 기본으로 제공되는 init()과 memberwise init()이 제공되지 않는 부분이 있는데 확장형을 만드는 순간 이 제약이 사라진다. 둘다 제공이 여전히 된다. 구조체의 탄생이유? 목적을 알 수 있는 부분이었다. 가볍게 사용하고, 편하게 사용하라는 뜻이 아닐까..(아니면 유감..)

또 구조체의 경우 본체의 생성자 호출대신 그냥 스스로 내부에서 값을 셋팅해주도록(생성자 역할을 하는 코드를 작성) 할 수 있는 것도 알아두면 흥미로운 포인트인 듯 하다.

여기서 한번 더 결국 생성자는 값을 셋팅해주기 위함이라는 것을 제 1원칙으로 기억해야하는 것 같다고 느꼈다.

중첩타입의 확장과 서브스크립트의 확장은 마치 알고리즘 문제를 푸는 듯한 스위프트 공식예제..흥미로웠다. 오 이렇게도 구현이되고 풀 수 있다니! 하는 포인트들이 많아서 재밌다.

3주차 스터디

FAQ로 스터디 진행계속, 별거는 없지만 velog 주소를 알려드렸다.(보고계시나요..?혹쉬..?)

오늘 스터디를 하면서 느낀점

내용에 관한건 늘 그랬듯이 복습하고 의견을 나누고, 내가 몰랐던 부분을 한 번 더 짚고 넘어갈 수 있어좋은것, 그대로 였고 운영에 대해 보완하고 싶은점이 생겼다. (쓰고나니 거창해보이는 매직)

아무래도 설명하는걸 화면공유해서 다같이 보고 듣기만하니, 집중도는 올라가긴하는데 내가 미쳐 생각하지 못한 부분을 알려주실때나, 아니면 추가로 기록하고 싶을때 화면공유의 화면을 캡쳐하는 방식으로만 공유가 가능하다는 것..

그래서 각자 준비해 오는 FAQ 복습정리자료를 공유하자고 제안드렸고 다들 긍정적으로 생각해주셔서 조 노션을 만들어 보기로 했다.

일단 조 노션을 그래서 나름 깔꼼하게(다른 분들의 템플릿을 잘 savage 해서 빠르게) 정리했는데.. 공유 단계에서 고민을 하게 되었다.

FAQ 특성상 강의 컨텐츠가 일부 섞여 있는데, 이걸 정리한 자료이다보니 보안상 우리끼리만 공유되어야 하는 특성이 있었다.(정말 강력한 private필요)

하지만 노션에서(일단 지금 알아본 바로는-친구와 함께 계속 시뮬레이션을 해봤다. 그냥 초대도 해봤다가 워크스테이션에도 넣어봤다가-) 워크스페이스에 팀스페이스에 멤버들을 이메일로 추가해서 조 노션페이지를 함께 보고 수정하는 것까지는 ok, 하지만 내가 정리한 자료를 우리끼리 다시 보게하려면 다른분들의 워크스페이스 팀스페이스에 나와 다른분들이 또 추가되어야만...private해지는 단점이 있었다.

그렇다고 팀스페이스에다가 FAQ자료를 정리하게 하면 너무 자유도가 떨어져서 불편할거라고 생각했다.

이렇게 돌고돌아 어렵게 하면 공유하는 의미가 없겠다 싶어서 다른 식으로 보안을 유지하면서도 깔꼼하게 자료를 공유할수 있는 방법을 더 고민해보기로 했다.
슬랙에 쓰레드를 파거나, 디스코드 서버를 만드는건 자료정리에는 효율적이지 못하다고 느껴서 일단 후순위로 두고 있는데.. 좀 더 고민해 볼 부분.

profile
Wellness 잘사는 것에 진심인 웰디입니다. 여러분의 몸과 마음, 통장의 건강을 수호하고싶어요. 느리더라도, 꾸준히

0개의 댓글