- Delegate 패턴은 왜 사용할까?
Delegate 패턴을 사용하는 이유는 여러가지 있겠지만, 내 생각은 이렇다.
우선 위에서 내가 말한 장점에 대해 알아보자.
위의 예제들에서 위임자들은 그저 일을 시킬 뿐, 일을 어떻게 처리해야하는지는 모른다.
일을 처리하는 방법은 그 일을 수행하는 객체에 구현되어 있다.
이미 눈치 챈 사람들도 있겠지만, 이렇게 작성하면 코드를 재사용하고 유지보수하기 쉬워진다.
어떤 일을 해야 하는지를 정해놓기만 하고, 상황에 맞는 코드를 작성하면 된다.
예를 들어 우리가 어떤 작업을 처리해야 하는데, 동일한 작업인데도 불구하고 객체마다 다른 내용을 처리해야한다고 생각해보자.
이럴 경우 동일한 작업에 대해서는 함수를 전달하기만 하고, 각각의 내용은 전달 받은 객체에서 처리하기만 하면 된다.
또한 작업을 전달할 때 공통된 부분을 제외하고 처리해야 하는 부분만을 전달하여 처리할 수도 있다.
열심히 구글링을 하며 찾아보다가 한 블로그에서 이런 문구를 보았다.
"Delegate는 어떤 객체가 해야 하는 일을 부분적으로 확장해서 대신 처리를 한다."
여러 글을 찾아보며 이해하고, 직접 글을 쓰고 난 뒤에 다시 이 문구를 보니 격하게 공감이 됐다.
내가 글에서 설명할 때에도 단순히 사전적 의미인 위임자에 집중하여 설명하였지만, 생각해보면 대신 처리를 하는 것도 맞지만 주어진 일을 확장하기도 한다.
이렇게 생각하니 이해가 더 잘 되는 느낌이다.
분명 내가 작성한 장점 외에 다른 장점들도 있을 것이고, 더 다양하게 활용하는 방법들도 있을 것이다.
앞으로 언제 쓰면 어떤 점에서 어떻게 좋을지 생각하며 적용해봐야겠다.
(출처: https://velog.io/@zooneon/Delegate-패턴이란-무엇일까)
- 코드로 UI 구성할 때는 addSubview()를 통해 메모리에만 올라와있는 오브젝트를 뷰의 하위 뷰에 직접적으로 올려줘야.
- Auto Layout 코드 구현시 Constraint 한번에 등록하기
NSLayoutConstraint.activate([passwordInfoLabel.leadingAnchor.constraint(equalTo: passwordTextFieldView.leadingAnchor, constant: 8), passwordInfoLabel.trailingAnchor.constraint(equalTo: passwordTextFieldView.trailingAnchor, constant: 8), 등등 constraint들을 배열 형태로 전달])- 코드로 UI를 만들어서 씬을 연결할 때는 해당 뷰컨의 인스턴스가 생성되는 순간 그 씬의 모든 object들이 다 같이 생성된다. 스토리보드로 씬을 생성할 때는 presentedVC(두번째 뷰컨)의 viewDidLoad가 호출 되는 순간에 해당 작업이 일어나기 때문에 presentingVC(첫번째 뷰컨)의 메서드에서 presentedVC의 오브젝트들의 속성에 접근하려고 하면 Crash 발생.
- direct dispatch - Extension, 수평적 확장, 메서드 배열의 추가
- class 선언 시에 더이상 상속할 일 없으면 final 붙여야 메모리 관리에 용이.
- 일반적으로 속성들은 private을 써서 외부에서 접근불가능 하게 만들어 놓는 것이 좋다. 대신, 해당 속성에 접근 할 수 있는 getSth() 등의 메서드를 구현토록 한다.
- viewDidLoad가 호출되면서 내가 코드로 만든 객체들과 스토리보드의 객체들이 연결된다.
- loadView: 뷰를 커스텀하여 view를 다른 뷰로 대체하려고 할 때 호출. view controller의 라이프 사이클 중 viewDidLoad보다 빠르게 호출되며 상위구현을 호출하면 안된다. 뷰를 대체하지 않을 때는 호출하면 안됨.
- scenedelegate는 appdelegate에서 화면에 관련된 것들만 따로 떼어 놓은 개념이라고 생각해도 됨
- view의 drawing cycle
제약을 업데이트하고(setNeedsUpdateConstraints(), updateConstraintsIfNeeded() - 1/60초 기다리지 않고 당장 제약 업데이트 - 웬만해서 잘 안 쓸 듯), 뷰를 다시 배치하고 (setNeedsLayout(), layoutIfNeeded() -1/60초 기다리지 않고 바로 컨텐츠 재배치 - ), 필요한 경우 컨텐츠를 다시 그리기(setNeedsDisplay() - 다음 사이클에 다시 그리기 - )
뷰를 다시 그리기 위해 우리가 호출하는 것은 사진의 파란색 메서드가 아니고 볼드체 함수들임. 파란색 함수들은 뷰가 내부에서 알아서 실행시키는 것들.
(출처: https://medium.com/@eurejp)
- SceneDelegate에서 탭바 설정 가능. 인스타그램처럼 로그인 화면 이후, 탭바가 나오는 대표적인 경우에서 가장 베이스에 탭바가 있는 뷰를 두고 그 위에 로그인이 안 되어있다면 로그인 화면이 등장했다가 사라져서 로그인 화면이 메모리에서 해제될 수 있도록 구현.
- navigation bar 에서 다음화면으로 넘어가는 것을 push, 다시 돌아오는 것을 pop 이라고 함. (stack 메모리에서 함수가 쌓이고 나가는 것과 같음)
- show는 push를 포함하는 더 큰 범위의 개념. ipad에서 왼쪽의 목록에서 선택을 했을 때 오른쪽에 detail view로 보여주는 것이 show이고 작은 화면에서는 push 방식으로 화면이 오른쪽으로 넘어감.
- swipable tab & menu 코드
https://iosexample.com https://iosexample.com/swipable-tab-and-menu-view-and-viewcontroller/ - side bar 메뉴 코드
https://iosexample.com/create-amazing-sidebar-menu-with-animation-using-swift/
2차전직 개발자가 되자