디자인 패턴이 객체지향 프로그래머에게 크게 영향을 미치게 된 계기는 “디자인 패턴 (Design Patterns)” 책이 출간되면서부터다. 이 책에서 GoF(Gang of Four의 약자로 “디자인 패턴 (Design Patterns)”의 저자들 Erich Gamma, Richard Helm, Ralph Johnson, Jone Vlisside 네 사람)는 객체지향설계를 위한 23개의 패턴을 기술 하였다. 이를 토대로 객체지향 분석/설계, 도메인 설계, 프로세스 조직/설계, 사용자 인터페이스 설계와 같은 다양한 분야에서 패턴과 패턴 언어에 대한 논문과 책들이 출간되고 객체지향 프로그래밍 개발에서 디자인 패턴이 폭넓게 사용되기 시작하였다.
• GoF
“특정한 상황에서 일반적 설계문제를 해결하기 위해 상호교류하는 수정 가능한 객체와 클래스들에 대한 설명이다.”
• 라만(C. Larman)GoF
“숙련된 객체지향 개발자 및 기타 소프트웨어 개발자는 소프트웨어 개발의 가이드라인이 되는 일반적인 원칙들과 관용적인 해결책들의 레퍼토리(repertoire)를 구축한다. 패턴은 이러한 원칙들과 관용적 해결책들이 문제와 해결책을 기술하는 구조적인 형태로 체계화되고 명명된 것이다.”
프로그래밍 디자인 패턴은 소프트웨어를 설계할 때 특정 상황에서 자주 사용하는 패턴을 정형화한 것이며, 좋은 소프트웨어 설계를 위한 개발자들의 경험적 산물이라고 할 수 있다.
프로그래밍 디자인 패턴의 특징
경험을 통하여 얻을 수 있다
특정한 형식을 갖고 체계적으로 작성되는 것이 일반적
패턴에는 각기 다른 추상화 수준이 존재하며 계속 진화함
프로그래밍 디자인 패턴의 장점
의사소통에 도움을 준다. 디자인 패턴을 알고 있는 설계자들은 특정 문제에 대해 공통으로 알고 있는 패턴을 이용해 해결책에 대해 논의를 할 수 있기 때문에 더욱 원활하게 의사소통할 수 있다.
검증된 지식인 패턴을 사용하면 높은 완성도의 디자인을 빠른 시간에 만들어 낼 수 있기 때문에 소프트웨어 개발 비용을 줄일 수 있어서 경제적이며, 코드의 수준을 한 단계 높여 주고 적은 수의 클래스로 원하는 목적을 달성할 수 있는 환경이 제공된다.
좋은 설계나 아키텍처가 패턴이라는 이름으로 명명되어 있어 개발자는 그 패턴의 이름만으로도 그 소프트웨어의 구조를 알 수 있다. 이를 바탕으로 이전의 소프트웨어 개발에서 사용한 설계나 구조를 쉽게 이해할 수 있고, 새로운 소프트웨어로 빠르게 적용할 수 있어서 소프트웨어 재사용을 쉽게 해준다.
디자인 패턴의 분류
새로운 소프트웨어를 개발할 때마다 대부분 개발자는 어떤 클래스를 만들고 어느 시점에 객체를 생성하고 소멸시킬지, 데이터를 어떻게 받아서 처리할지, 구조 설계를 어떻게 할지 고민해야하는데, 디자인 패턴 분류는 위와 같이 소프트웨어 코드를 작성할 때 자주 반복되는 특정 상황에서 설계를 용이하게 하며 코드의 재사용이 용이하도록 패턴을 정리해 놓은 것이다.
그중 가장 잘 알려진 분류법으로 GoF의 패턴분류 방법이 있다.
• 목적
패턴이 무엇을 하는지 정의하는 것으로 "생성", "구조", "행위" 중의 한 가지 목적을 갖는다.
◦ 생성 (Creational Pattern)
객체의 생성 과정에 관여하는 패턴
◦ 구조 (Structural Pattern)
클래스나 객체의 구성을 통해 더 큰 구조로 만들 수 있게 해주는 것과 관련된 패턴
◦ 행위 (Behavioral Pattern)
패턴을 주로 클래스에 적용하는지 아니면 객체에 적용하는지에 따라 구분되는 패턴
• 범위
패턴을 클래스에 적용하는지 아니면 객체에 적용하는지에 따라 구분되는 패턴
◦ 클래스 패턴 (Class Pattern)
클래스들과 하위 클래스 간의 관계를 다루는 패턴입니다. 컴파일 시에 관계가 결정
◦ 객체 패턴 (Object Patterns)
객체 간의 관계를 다루며 보통 구성을 통해 정의됨.
객체 패턴은 일반적으로 실행시간에 관계가 생성되기 때문에 더 동적이면서 유연
디자인 패턴의 종류
수많은 패턴 중 몇 가지 패턴의 종류를 간단하게 설명한다.
• 싱글턴 패턴 (Singleton Pattern)
목적 : 생성
범위 : 객체
객체의 생성에 관련된 패턴으로서 특정 클래스의 인스턴스가 오직 하나임을 보장하고 이 인스턴스에 접근할 방법을 제공
• 퍼사드 패턴 (Facade Pattern)
목적 : 구조
범위 : 객체
건물의 정문에 있는 안내소처럼 개발자가 사용해야 하는 서브 시스템의 가장 앞쪽에 위치하면서 하위 시스템에 있는 객체들을 사용할 수 있도록 하는 역할을 한다.
> 시스템의 복잡성을 줄이기 위해 서브 시스템을 구조화하고 서브 시스템으로의 접근을 하나의 퍼사드 객체로 제공하는 패턴
• 옵저버 패턴 (Observer Pattern)
목적 : 행위
범위 : 객체
객체의 상태변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 패턴
• 스트래티지 패턴 (Strategy Pattern)
목적 : 행위
범위 : 객체
알고리즘을 담당하는 각각의 클래스를 만들어 책임을 분산하기 위한 목적으로 만든 행위 패턴
• 팩토리 패턴 (Factory Pattern)
목적 : 생성
범위 : 클래스
객체를 생성하기 위한 인터페이스를 정의하지만 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 하위 클래스에서 이루어지도록 인스턴스 생성의 책임을 떠넘기는 패턴
• 어댑터 패턴 (Adapter Pattern)
목적 : 구조
범위 : 클래스, 객체
클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 동작하도록 함
소프트웨어 디자인 패턴을 사용할 때 생각해 볼 점
디자인 패턴은 특정 상황에 대한 선배 프로그래머의 경험의 산물이자 방법론으로 즉, 디자인 패턴은 모든 상황에서 만능은 아니다.
예를 들어 싱글턴 패턴을 적재적소에 활용하면 유용하겠지만, 적절치 못한 상황에 사용하면 오히려 큰 독이 될 수도 있다. 다양한 디자인 패턴을 아는 것도 중요하지만, 언제 어떻게 사용하는 것이 좋을지 고민하는 것도 굉장히 중요한 문제이다.
디자인 패턴은 그 종류도 다양해지고 있으며, 기존의 디자인 패턴을 변형하여 사용하는 경우도 많다. 다양한 디자인 패턴을 익히고 자신의 코드에 적용해 보되, 깊은 공부와 많은 고민은 필수!
윈도우 는 그 자체로 콘텐츠를 표현할 수 없지만 애플리케이션의 뷰를 위한 컨테이너 역할을 한다.
뷰 는 UIView 클래스 또는 UIView 클래스의 하위클래스(Subclass)의 인스턴스로 윈도우의 한 영역에서 콘텐츠를 보여준다.
뷰가 나타낼 수 있는 콘텐츠는 이미지, 문자, 도형 등과 같이 다양하며, 뷰는 또 다른 뷰를 관리하고 구성하기 위해 사용되기도 한다. 뷰는 제스처 인식기(gesture recognizer) 를 사용하거나 직접 터치 이벤트를 처리할 수 있으며, 또한 뷰 계층(view hierarchy)구조에서 부모뷰(parent view)는 자식뷰(child view)의 위치와 크기를 관리한다.
나타내고자 하는 유형의 콘텐츠에 적합한 뷰를 여러 개 사용하여 뷰 계층(view hierarchy)구조를 구성하고 이를 통해 콘텐츠를 보여주는 것이 좋다. 예를 들어 UIKit에는 이미지, 텍스트 그리고 다른 유형의 콘텐츠를 나타내는 뷰가 포함되어 있다.
뷰 계층(View hierarchy)
뷰 계층구조와 서브뷰 관리
뷰는 자신의 콘텐츠를 보여주는 것과 더불어, 다른 뷰를 위한 컨테이너로써의 역할도 한다. 하나의 뷰가 다른 뷰를 포함할 때, 두 뷰 사이에 부모-자식 관계가 생성된다.
해당 관계에서는 자식뷰는 서브뷰(subview) 로, 부모뷰는 슈퍼뷰(superview) 로 불려집니다.
부모-자식 관계 형성은 애플리케이션의 시각적 모습과 동작 모두에 영향을 미친다.
예시
1.슈퍼뷰와 서브뷰의 관계에서 서브뷰가 불투명할 경우 아래 그림과 같이 슈퍼뷰가 서브뷰에 가려진다.
2.서브뷰가 반투명할 경우 서브뷰와 슈퍼뷰의 콘텐츠가 서로 섞여 화면에 보여진다.
아래 그림과 같이 원래 노란색이었던 뷰가 슈퍼뷰의 빨간색과 섞여 주황색으로 화면에 보이게 됩니다.
3.슈퍼뷰는 하나의 배열 안에 서브뷰를 순서대로 저장한다. 만약 하나의 슈퍼뷰에 포함된 두 서브뷰가 서로 겹치게 되면, 나중에 추가된(또는 서브뷰 배열의 끝으로 옮겨진) 서브뷰가 맨 위에 보여진다.
OS 애플리케이션에서 뷰 계층을 만드는 방법에는 인터페이스 빌더를 이용하는 방법과 코드를 작성하는 방법이 있다.
코드작성 방식을 사용할 경우 서브뷰를 부모뷰에 추가하기 위해, 부모뷰의 addSubView(_:) 메서드를 호출한다. 이 메서드는 해당 서브뷰를 서브뷰 목록의 마지막에 추가 합니다. 부모뷰의 서브뷰를 제거하기 위해서는 서브뷰의 removeFromSuperView() 메서드를 호출한다. 이 외에도 서브뷰를 부모뷰 목록의 중간에 삽입하기 위해 insertSubview(_:at:), 부모뷰 내에 이미존재하는 서브뷰를 정렬하기 위해 bringSubView(toFront:), sendSubview(toBack:) 등의 메서드들을 호출할 수 있다.
뷰의 좌표계
UIKit에서 기본이 되는 좌표계는 좌측 상단 모서리를 원점 으로 하며, 원점으로부터 아래쪽, 오른쪽 방향으로 확장된다.
좌표값은 해상도와 상관없이 콘텐츠의 위치를 잡는 부동소수점을 사용 하여 나타냅니다.
프레임과 바운드
iOS의 좌표체계의 시작은 왼쪽 위부터 시작
즉, 제일 왼쪽의 제일 위의 지점이 (0, 0) 이다. 또, 수평축은 x로, 수직축은 y로 표현
아이폰 기종은 우리도 다 알다시피 iPhone4, iPhoneSE, iPhone8, iPhone8 Plus 그리고 iPhoneX등 다양한 사이즈와 화면비율로 출시되면서 사이즈의 구애를 받지 않고 시각적으로 동일한 화면을 구현해야 하는 데 이를 위한 가장 편리하고 권장되는 방법이 오토레이아웃 이다.
뷰의 제약 사항을 바탕으로 뷰 체계 내의 모든 뷰의 크기와 위치를 동적으로 계산
애플리케이션을 사용할 때 발생하는 외부 변경과 내부 변경에 동적으로 반응하는 사용자 인터페이스를 가능하게 함
외부변경(External Changes)
슈퍼뷰의 크기나 모양이 변경될 때 발생
각각의 변화와 함께 사용가능한 공간을 가장 잘 사용할 수 있도록 뷰 체계의 레이아웃을 업데이트 해줘야 함
사용자가 아이패드의 분할뷰(Split View)를 사용하거나 사용하지 않는 경우
장치를 회전하는 경우
활성화콜(acitive call)과 오디오 녹음 바가 보여지거나 사라지는 경우
다른 크기의 클래스를 지원하기 원하는 경우
다른 크기의 스크린을 지원하기 원하는 경우
이러한 변경사항은 대부분은 실행 시간에 발생할 수 있으며 애플리케이션으로부터 동적인 응답을 요구한다. 다른 스크린 크기를 지원하는 것과 같은 것은 애플리케이션이 다른 환경에 적응하는 것을 나타낸다. 스크린 크기가 일반적으로 실행 시간에 변경되지 않는다고 하더라도, 적응형 인터페이스를 만들면 애플리케이션이 아이폰 4S, 아이폰 6 플러스, 또는 아이패드에서도 모두 동일하게 잘 작동할 수 있다. 오토레이아웃은 아이패드 내부 변경에서 슬라이드와 분할뷰를 지원하는 핵심 요소이기도 합니다.
내부변경(Internal Changes)
사용자 인터페이스의 뷰의 크기 또는 설정이 변경되었을 때 발생
애플리케이션 변경에 의해 콘텐츠가 보여지는 경우
애플리케이션이 국제화를 지원하는 경우
애플리케이션이 동적 타입을 지원하는 경우
애플리케이션 콘텐츠가 변경됐을 때, 새로운 콘텐츠는 예전과 다른 레이아웃을 필요 할 수 있다. 새로운 애플리케이션이 각각의 신문 기사의 크기에 기반을 둔 레이아웃을 조정할 필요가 있는 경우와 같이, 텍스트 또는 이미지를 보여주는 애플리케이션에서 일반적으로 발생하는 일이다. 이와 비슷하게, 사진 콜라주는 이미지 크기와 영상의 가로 세로의 비율을 다뤄야한다.
오토레이아웃이 왜 필요할까?
오토레이아웃은 아래의 경우와 같이 인터페이스의 절대적인 좌표가 아닌 동적으로 상대적인 좌표가 필요한 경우에 유용 하다.
애플리케이션이 실행되는 iOS 기기의 스크린 화면의 크기가 다양한 경우
애플리케이션이 실행되는 iOS 기기의 스크린이 회전할 수 있는 경우
상태표시줄(Status Bar)에 전화 중임을 나타내는 액티브 콜(active call)과 오디오 녹음 중임을 나타내는 오디오 바가 보여지거나 사라지는 경우
애플리케이션의 콘텐츠가 동적으로 보여지는 경우
애플리케이션이 지역화(Localization)를 지원하는 경우
애플리케이션이 동적 타입을 지원하는 경우
오토레이아웃 속성
오토레이아웃의 속성은 정렬 사각형을 기반으로 한다.
Width : 정렬 사각형의 너비
Height : 정렬 사각형의 높이
Top : 정렬 사각형의 상단
Bottom : 정렬 사각형의 하단
Baseline : 텍스트의 하단
Horizontal : 수평
Vertical : 수직
Leading : 리딩, 텍스트를 읽을 때 시작 방향
Trailing : 트레일링, 텍스트를 읽을 때 끝 방향
CenterX : 수평 중심
CenterY : 수직 중심
안전 영역(Safe Area)
안전 영역은 콘텐츠가 상태바, 내비게이션바, 툴바, 탭바를 가리는 것을 방지하는 영역 입니다. 표준 시스템이 제공하는 뷰들은 자동으로 안전 영역 레이아웃 가이드를 준수하게 되어있다.
기존의 상/하단 레이아웃 가이드(Top/Bottom Layout Guide)를 대체하며, 하위 버전에도 호환하여 작동한다.
안전 영역은 iOS 11부터 사용할 수 있으며, iOS 11 미만의 버전에서는 상/하단 레이아웃 가이드를 사용한다.
안전 영역 레이아웃 가이드는 UIView클래스의 var safeAreaLayoutGuide: UILayoutGuide로 접근할 수 있다.
제약(Constraint)
제약은 뷰 스스로 또는 뷰 사이의 관계를 속성을 통하여 정의하며, 제약은 방정식으로 나타낼 수 있다.
Item1 : 방정식에 있는 첫 번째 아이템(B View)이며, 첫 번째 아이템은 반드시 뷰 또는 레이아웃 가이드
Attribute1 : 첫번째 아이템에 대한 속성이며 이 경우, B View의 리딩
Multiplier : 속성 2에 곱해지는 값이며, 이 경우 1.0이다.
Item2 : 방정식에 있는 두 번째 아이템(A View)
Attribute2 : 두번째 아이템에 대한 속성으로 이 경우, A View의 트레일링
Constant : 두번째 아이템의 속성에 더해지는 상수 값
위의 예제 방정식의 제약을 해석하면 ‘B View의 리딩은 A View의 트레일링의 1.0배에 8.0을 더한 위치’ 가 된다.
고유 콘텐츠 크기(Intrinsic Content Size)
뷰의 고유 콘텐츠 크기는 뷰가 갖는 원래의 크기로, 예를 들어 레이블의 고유 콘텐츠 크기는 레이블의 텍스트의 크기고, 이미지의 고유 콘텐츠 크기는 이미지 자체의 크기이다.
제약 우선도(Constraint Priorities)
오토레이아웃은 뷰의 고유 콘텐츠 크기를 각 크기에 대한 한 쌍의 제약을 사용하여 나타낸다.
우선도가 높을수록 다른 제약보다 우선적으로 레이아웃에 적용하며, 같은 속성의 다른 제약과 경합하는 경우, 우선도가 낮은 제약은 무시된다.
콘텐츠 허깅 우선도(Content hugging priority) : 콘텐츠 고유 사이즈보다 뷰가 커지지 않도록 제한.
다른 제약사항보다 우선도가 높으면 뷰가 콘텐츠 사이즈보다 커지지 않음
콘텐츠 축소 방지 우선도(Content compression resistance priority) : 콘텐츠 고유 사이즈보다 뷰가 작아지지 않도록 제한.
다른 제약사항보다 우선도가 높으면 뷰가 콘텐츠 사이즈보다 작아지지 않음
레이아웃 마진
뷰에 콘텐츠 내용을 레이아웃할 때 사용하는 기본 간격(default spacing)
레이아웃 마진 가이드(Layout Margins Guide): 레이아웃 마진에 따라 형성되는 사각의 프레임 영역
앵커(Anchor)
오토레이아웃을 코딩으로 구현하여 제약(Constraint)을 만들기 위해 앵커(Anchor)를 사용
Layout Anchor 사용 예제
중앙에 버튼을 배치하고 버튼의 top anchor를 사용하여 레이블을 버튼의 상단으로부터 10만큼 떨어지도록 배치
1.객체 라이브러리에서 버튼과 레이블을 추가해줍니다. 이제 앵커를 활용하여 제약을 만들어봅시다.
2.@IBOutlet을 활용하여 인터페이스 빌더에서 ViewController.swift 파일로 버튼과 레이블을 연결해줍니다.
3.버튼을 중앙에 배치하기 위해 버튼의 수평과 수직의 중앙 앵커를 뷰 컨트롤러의 뷰의 중앙에 기준을 잡아준다. 생성된 제약을 적용하기 위해선 isActive 프로퍼티의 값을 true로 설정 해주면 됩니다.
translatesAutoresizingMaskIntoConstraints : 오토레이아웃이 도입되기 전 뷰를 유연하게 표현할 수 있도록 오토리사이징 마스크를 사용하였는데, 오토레이아웃을 사용하게 되면 기존의 오토리사징 마스크가 가지고 있던 제약조건이 자동으로 추가되기 때문에 충돌하게 될 가능성이 발생한다. 그래서 translatesAutoresizingMaskIntoConstraints의 값을 false로 지정 한 뒤 오토레이아웃을 적용해준다. 참고로 인터페이스 빌더에서 오토레이아웃을 적용한 경우에는 자동으로 값이 false로 설정됩니다. (참조: translatesAutoresizingMaskIntoConstraints)
4.레이블의 수평 중앙을 버튼의 수평 중앙 앵커를 기준으로 제약을 생성한 후, 레이블의 하단 앵커를 버튼의 상단 앵커로부터 10만큼의 거리를 두도록 한다.(상단 앵커기준으로 위로의 거리는 부호가 - 라는 점을 주목) 생성된 제약을 적용하기 위해 isActive 프로퍼티를 true 로 설정. 그림과 같이 레이블이 버튼의 상단에 자리 잡고 있는 것을 볼 수 있다.
속성에 곱해지는 multiplier를 활용 > 앵커를 활용하여 레이블의 너비가 버튼의 너비의 2배가 되도록 제약을 만들어 본다.
iOS 애플리케이션 개발 환경으로, 애플리케이션의 다양한 기능 구현에 필요한 여러 프레임워크를 포함하는 최상위 레벨의 프레임 워크
macOS 애플리케이션 제작에 사용하는 프레임워크
핵심 프레임워크인 UIKit와 Foundation을 포함
UIKit 프레임워크란?
iOS 애플리케이션의 사용자 인터페이스를 구현하고 이벤트를 관리하는 프레임워크
제스처처리, 애니메이션, 그림 그리기, 이미지 처리, 텍스트 처리 등 사용자 이벤트 처리를 위한 클래스를 포함
테이블 뷰, 슬라이더, 버튼, 텍스트필드, 얼럿 창 등 애플리케이션의 화면을 구성하는 요소를 포함
UIKit 클래스 중 UIResponder에서 파생된 클래스나 사용자 인터페이스 관련된 클래스는 애플리케이션 메인 스래드에서만 사용
UIKit는 iOS와 tvOS플랫폼에서 사용
UIKit 기능별 요소
사용자 인터페이스
View and Control: 화면에 콘텐츠 표시
View Controller: 사용자 인터페이스 관리
Animation and Haptics: 애니메이션과 햅틱을 통한 피드백 제공
Window and Screen: 뷰 계층을 위한 윈도우 제공
사용자 액션
Touch, Press, Gesture: 제스처 인식기를 통한 이벤트 처리 로직
Drag and Drop: 화면 위에서 드래그 앤 드롭 기능
Peek and Pop: 3D 터치에 대응한 미리 보기 기능
Keyboard and Menu: 키보드 입력을 처리 및 사용자 정의 메뉴 표기
생각해보기 새롭게 ViewController를 생성하면 상단에 ‘import UIKit’이 기본적으로 명시되어있는걸 본적 있다
왜 ViewController와 UIKit는 단짝일까요?
내가 생각한 답
기본적으로 UIKit는 iOS 사용자 인터페이스를 구현하는 프레임워크이다. 사용자 인터페이스를 관리하는 View Controller를 건들기 위해서는 기본적으로 이를 관리하는 프레임워크인 UIKit가 import되어야 한다고 생각한다.
Foundation
원시 데이터타입(String, Int, Double), 컬렉션 타입(Array, Dictionary, Set) 및 운영체제 서비스를 사용해 애플리케이션의 기본적인 기능을 관리하는 프레임워크
데이터타입, 날짜 및 시간 계산, 필터 및 정렬, 네트워킹 등의 기본 기능 제공
프레임워크에서 정의한 클래스, 프로토콜 및 데이터 타입은 iOS뿐 아니라 macOS, watchOS, tvOS등 모든 애플 SDK에서 사용
Foundation에서 제공하는 데이터타입 및 컬렉션 타입의 대부분은 Objective-C 언어의 기능에서 지원하지 않는 것이기 때문에 언어기능을 보완하기 위한 구현이며, Swift에서는 이에 해당하는 데이터 타입과 기능 대부분을 Swift표준 라이브러리에서 제공한다.
Foundation 기능별 요소
기본
Number, Data, String: 원시 데이터 타입 사용
Collection: Array, Dictionary, Set등과 같은 컬렉션 타입 사용
Data and Time: 날짜와 시간을 계산하거나 비교하는 작업
Unit and Measurement: 물리적 차원을 숫자로 표현 및 관련 단위 간 변환 기능
Data Formmating: 숫자, 날짜, 측정값 등을 문자열로 변환 또는 반대 작업
Filter and Sorting: 컬렉션의 요소를 검사하거나 정렬하는 작업
애플리케이션 지원
File System: 파일 또는 폴더를 생성하고 읽고 쓰는 기능 관리
Archives and Serialization: 속성목록, JSON, 바이너리 파일들을 객체로 변환 또는 반대작업 관리
iCloud: 사용자의 iCloud 계정을 이용해 데이터를 동기화하는 작업 관리
네트워킹
URL Loading System: 표준 인터넷 프로토콜을 통해 URL과 상호작용하고 서버와 통신하는 작업
Bonjour: 로컬 네트워크를 위한 작업
생각해보기.
새롭게 ViewController 파일을 생성하면 상단에 ‘import UIKit’이 기본적으로 명시되어있다.
그렇다면 어떤 파일을 생성하면 ‘import Foundation’이 기본적으로 명시되어있을까요?
내가 생각한 답
원시 데이터 타입 및 컬렉션 타입을 사용하기 위해 기본적인 Swift파일을 생성할때 import Foundation이 된다. UIKit 내부에도 Foundation이 들어있지만, 이를 분리해서 import를 하는 이유는 iOS의 디자인 패턴인 MVC 모델을 생성할 때 사용자 인터페이스와 비즈니스 로직을 분리하기 위해 데이터 타입에서 쓰이는 Foundation을 쓰도록 권장한 것이 아닐까 싶다.
지혜의 개발공부로그
