현재 플젝에 데이터 가져오는 URL이 하드코딩 되어있어서 이걸 내일 리팩토링 하려고 공부해보았다 (사실 구 RayWenderwich의 URLSession 강의 따라하다가 딴길로 샘). 다음과 같은 URL이 있다고 해보자. https://itunes.apple.com/search?media=music&entity=song&term=Musehttps는 scheme itunes.apple.com은 host /search는 path ? 뒤부터 나오는 media=music&entity=song&term=Muse는 query다. URL을 만들 때마다 위처럼 하드코딩을 해줄수도 있겠지.. 그치만 그런 멍청한 방법은 당연히 쓰고 싶지 않다. 그럼 얘를 어떻게 쪼갤까? 할 때 URLComponents, URLQueryI..
야곰 아카데미에서 프로젝트를 진행하다가 "OO는 왜 구조체로 구현했나요?"라는 질문을 받았는데, 그 질문에 대한 답변이 바로 떠오르지 않았다. 왜냐하면... 특별한 이유를 생각해보지 않고 구현했기 때문이었다^^;;; 굳이굳이 이유를 찾아보자면, 아직 프로젝트 요구사항이 전부 밝혀지지 않아서 굳이 class로 작성할 이유를 찾지 못했기 때문이라고 할 수 있겠다. (애플 공식문서에서 클래스에서만 지원하는 기능이 필요한 경우가 아니면 기본적으로 구조체를 쓰라고 했기 때문에) 그런데 연결 리스트를 구현해보는 과정에서 Node는 아무 생각 없이 클래스로 구현했었던 것이 생각나서, (나를 포함한 다른 사람들도) 왜 노드는 클래스로 구현했지?라는 의문을 갖게 되었다. Doubly Linked List의 노드는 일반적..
- Total
- Today
- Yesterday
- HTTP message
- URLQueryItem
- OSI
- TCP
- URL
- ssh-configure
- 네트워크
- Cow
- URLComponents
- copy on write
- 커리어스타터캠프
- multipart/form-data
- ssh-agent
- 어플
- Github
- 참조 타입
- 값 타입
- 스택
- 메모리 구조
- 야곰아카데미
- IOS
- SWIFT
- HTTP Methods
- ssh-add
- 부트캠프
- Endpoint
- SSH
- 앱개발
- 코딩
- JSON
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |