오늘의 주제

Objective-C의 상수와 스위프트의 상수


안녕하세요 야곰입니다.

Objective-C를 쓰다가 스위프트로 넘어왔을 때 고민되었던 부분 중의 하나인 스위프트의 상수에 관해 이야기해 보려 합니다.


혼자 프로젝트를 진행하다 보면 상수의 필요성을 많이 느낄 수 없을지 모르지만, 누군가 협업을 하게 된다면, 혹은 미래 또는 과거의 나와 협업(?)을 하게 된다면 상수의 필요성을 많이 느끼게 됩니다. 바꾸면 안 되는 데이터를 실수로 바꿔서 난감했던 경험이 없나요? 혹시 그런 적이 있다면 상수의 필요성에 대해서는 많이 공감하실 것으로 생각됩니다.


* 오해가 생길 소지의 표현들이 있어서 처음 발행 이후 조금 수정하였습니다. 좋은 의견 주신 과니님 고맙습니다 :)


사라진 const


사실 저는 Objective-C에서 특별한 경우가 아니면 const를 많이 사용하지 않았습니다(반성).


그런데 스위프트에서는 전역이든 지역이든 데이터를 저장할 공간(변수 또는 상수)에는 var 또는 let을 사용하여 변수인지 상수인지 명확히 명시해 주어야 하므로 상수에 대한 고민을 많이 하게 되었습니다.


사실 지역상수가 필요한 경우에 const 키워드를 쓰는 귀찮음 때문에 상수를 많이 사용하지 않았는데 스위프트에서는 var 또는 let을 선택해야 하는 시간이 조금 걸렸지만, 지금은 큰 시간 들일 필요 없이 자연스럽게 상수를 많이 사용하고 있습니다. 또, 혹시라도 상수로 사용해야 하는 경우임에도 변수로 선언하고 사용한다면 Xcode에서 변수 대신 상수를 사용하는 게 어떻냐는 경고를 보여줍니다. 




[Xcode의 경고]


지역상수


지역상수를 사용하는 경우에는 사실 Objective-C와 크게 다를 바 없이 사용할 수 있습니다. 상수의 이름을 지어주는 명명법도 크게 다를 바 없습니다. 

상수로 사용할 변수 앞에 const를 붙여 쓴 것처럼 let을 사용하여 상수를 선언하여 사용하면 됩니다.



// Objective-C
const NSInteger someConstant = 100;


// Swift
let someConstant: Int = 100



전역상수


전역상수를 사용할 때 조금 더 생각해보아야 할 것들이 있습니다. 저는 처음 스위프트를 사용할 때 별생각 없이 Objective-C에서 사용하던 것과 같은 명명법으로 전역상수를 사용했습니다.


// Objective-C NSInteger const  YGSomeGlobalConstant = 100;


// Swift
let YGSomeGlobalConstant: Int = 100


그런데 Objective-C에서 'YG'와 같이 접두어(prefix)를 붙이는 것은 Objective-C에는 네임스페이스(name space)가 없기 때문인데, 스위프트에는 이 단점을 극복했다는 것에 대한 생각이 문득 스쳤습니다.


Objective-C에는 네임스페이스가 없어서 전역변수를 선언하고 사용할 때 꽤 골치가 아팠습니다. 귀찮기도 아주 귀찮았죠. 이름도 매우 길어지기만 했습니다. 열거형(enum)은 정수밖에 지원하지 않기 때문에 다른 타입의 값들은 관련된 상수끼리 묶어 쓰기도 어렵기도 했지요.


// Objective-C의 상수들... // 네임스페이스가 없기 때문에 // 연관된 상수들을 접두어를 사용하여 표현합니다 // 요일 상수들 NSString *const YGWeekMonday = @"MON"; NSString *const YGWeekTuesday = @"TUE"; NSString *const YGWeekWednesday = @"WED"; NSString *const YGWeekThursday = @"THU"; NSString *const YGWeekFriday = @"FRI"; NSString *const YGWeekSaturday = @"SAT"; NSString *const YGWeekSunday = @"SUN"; // 네트워킹 관련 상수들 NSTimeInterval const YGNetworkingTimeoutInterval = 10.0f; NSUInteger const YGNetworkingMaxRetryCount = 3; NSString *const YGNetworkingBaseURLString = @"https://abc.com";


정말 보기만 해도 정신이 없습니다. 또, 실수로 복사 붙여넣기를 하다가 중복된 값을 넣었다면 컴파일 오류가 발생하지 않기 때문에 실수를 찾아내기도 매우 어려워집니다.


스위프트에서는 이런 전역 상수들을 조금 더 멋진 방법으로 표현해 볼 수 있습니다. 타입 내부에 다른 타입을 정의하는 방법으로 네임스페이스를 사용할 수 있습니다. 더군다나 네임스페이스 덕분에 접두어는 더 이상 스위프트에서 사용하지 않습니다.


// Week라는 구조체 타입 내부에
// 여러 타입 상수를 선언
struct Week {
    static let mon: String = "MON"
    static let tue: String = "TUE"
    static let wed: String = "WED"
    static let thu: String = "THU"
    static let fri: String = "FRI"
    static let sat: String = "SAT"
    static let sun: String = "SUN"
}

// 실제 사용시 Week.mon // "MON" Week.sat // "SAT"


처음에 이렇게 선언해 보았습니다. 그런데 만약 복사 붙여넣기를 하다가 실수로 중복된 값을 넣는다면...? 가령 "SUN"을 넣어야 하는데 "SAT"를 넣어버렸다면? 이때는 중복 값이 들어있는지 확인할 수 없습니다. 물론 의도적으로 다른 이름의 상수에 같은 값을 넣을 수도 있지만 그렇지 않은 경우에는 낭패입니다.


그래서 이렇게 개선해 봅니다.


// 열거형의 연관 값(associated value)을 사용하여
// 상수처럼 사용
enum Week: String {
    case mon = "MON"
    case tue = "TUE"
    case wed = "WED"
    case thu = "THU"
    case fri = "FRI"
    case sat = "SAT"
    case sun = "SUN"
}

// 실제 사용시 Week.mon.rawValue // "MON" Week.sat.rawValue // "SAT"



이렇게 사용하면 열거형 내부의 연관 값이 중복되는 경우에 컴파일오류가 발생하게 됩니다. 그래서 미리 실수를 발견하기도 좋습니다.


또, 위의 Objective-C로 선언했던 네트워킹 관련 상수를 스위프트에서 선언한다면 이렇게 바꿔볼 수 있을 것 같습니다.


// Objective-C NSTimeInterval const YGNetworkingTimeoutInterval = 10.0f; NSUInteger const YGNetworkingMaxRetryCount = 3; NSString *const YGNetworkingBaseURLString = @"https://abc.com";
// 사용 YGNetworkingTimeoutInterval // 10.0


// Swift
struct Networking {
    static let timeoutInterval: TimeInterval = 10.0
    static let maxRetryCount: Int = 3
    static let baseURL: URL? = URL(string: "https://abc.com")
}

// 사용

Networking.timeoutInterval // 10.0


이처럼 꼭 열거형의 연관 값을 사용하지 않고 용도에 맞게 구조체의 타입 상수(static let)로 사용해도 좋습니다. 


상수뿐만 아니라 전역변수, 전역함수(메서드) 등에도 충분히 응용할 수 있습니다.


또한 구조체 내부에 다른 타입(구조체, 클래스, 열거형) 등등 몇 단계를 걸쳐 내부 타입을 정의할 수 있기 때문 연관된 값을 타입의 타입의 타입까지 여러 번에 걸쳐 정의도 가능합니다.



struct CalendarItem {
    typealias Year = Int
    typealias Day = Int
    
    enum Week: String {
        case mon = "MON", tue = "TUE" //...
    }
    
    enum Month: Int {
        case jan = 1, feb, mar //...
    }
    
    static let startYear: Int = 1970
    static let startMonth: CalendarItem.Month = .jan
    
    struct Date {
        var day: Day = 1
        var weekDay: CalendarItem.Week = .mon
        var month: CalendarItem.Month = .jan
        var year: Year = CalendarItem.startYear
    }
}

var userBirthday: CalendarItem.Date userBirthday = CalendarItem.Date.init(day: 10, weekDay: .tue, month: .mar, year: 2017)



마치며


같은 Cocoa 플랫폼 위에서 코드를 작성하는데도 불구하고 역시나 언어의 특성을 살려 새로이 구조를 설계하기는 쉽지 않습니다 하핳


무언가 두서없이 써내려간 느낌입니다만, 잘 이해가 가지 않거나 궁금한 점이 있다면 댓글 남겨주세요 :D





by yagom

facebook : http://www.facebook.com/yagomSoft

facebook group : https://www.facebook.com/groups/yagom/


p.s 제 포스팅을 RSS 피드로 받아보실 수 있습니다.

RSS Feed 받기   


저작자 표시 비영리 변경 금지
신고
Posted by yagom


오늘의 Tip

1. CocoaPods이란?

2. CocoaPods 설치

3. Pod 설치

4. Pod 찾아보기


안녕하세요 야곰입니다.

오늘은 코코아팟에 대한 이야기를 해보려고 합니다.


# CocoaPods이란?


iOS 및 macOS, tvOS 등 애플 플랫폼에서 개발을 할 때, 외부 라이브러리를 관리하기 쉽도록 도와주는 의존성 관리 도구들이 있습니다. CocoaPods는 애플 플랫폼을 위한 의존성 관리도구의 일종입니다. 애플 플랫폼에서 사용할 수 있는 의존성 관리 도구의 대표적인 예로는 [CocoaPods], [Carthage], [Swift Package Manager] 등이 있습니다.


더 자세한 설명은 이미 써두신 분들이 많아 링크를 드립니다.


CocoaPods에 대해 설명하고 있는 문서 링크


# CocoaPods 설치 및 Pod 설치


가장 빠른 것은 아래 영상을 보고 따라하는거예요.






영상을 보기 싫은 분들을 위해 텍스트 설명


# CocoaPods 설치


쉽습니다. 별로 할 게 없어요. 맥을 사용하고 있다면 터미널을 열어서 명령어 한 줄만 입력하면 됩니다.

아무 반응이 없더라도 기다리세요. 설치가 되고 있습니다. 처음에 꽤 오래 걸립니다. 그러니 차분히 기다리세요.


sudo gem install cocoapods


# Pod 설치


CocoaPods를 통해 가져올 수 있는 라이브러리를 Pod이라고 할 수 있습니다. 


먼저 현재 내가 진행하고 있는 프로젝트 폴더에 Podfile 이라는 이름의 파일을 생성합니다. 이 Podfile을 통해 CocoaPods이 라이브러리 의존성을 파악하게 됩니다.


원하는 라이브러리는 cocoapods.org에서 검색해 보는 것이 가장 쉽고 빠릅니다. 검색하여 찾은 라이브러리의 pod spec을 복사하여 Podfile에 붙여넣어줍니다.


파일을 저장한 후 터미널에서 (프로젝트 경로에서)아래 명령어를 입력해줍니다.


pod install


그러면 기존 프로젝트 파일 외에 워크스페이스 파일이 별도로 생성되는데, 이제 그 워크스페이스 파일로 작업을 진행하면 됩니다.



# Pod 설치


그러면 도대체 쓸만한 Pod은 어디서 찾을까요?


일단 CocoaPods를 통해 제공되는 라이브러리는 모두 cocoapods.org에서 찾아볼 수 있는데요, 

UI를 미리 보고 싶다면 cocoacontrols.com도 추천합니다.

각종 UI/UX 라이브러리들이 모여있고, 미리보기, 라이센스 확인도 모두 가능합니다.




Download Source를 선택해 들어가면 대부분 github 페이지로 이동합니다.

github 페이지의 README 파일에 보면 대부분 cocoapods을 통해 설치할 수 있는 pod 정보도 설명이 되어있습니다.




그런데 더 놀라운 곳이 있습니다! 양이 너무 많아 무얼 써보아야 할지 모르지만~ 

[Awesome iOS]에 많은 라이브러리 목록이 있습니다. 

UI만 또 모아놓은 곳도 있구요~ [Awesome iOS UI]


이제 손쉽게 라이브러리를 검색하고 의존성 관리도 손쉽게 해보세요!








by yagom

facebook : https://facebook.com/yagomsoft

facebook group : https://www.facebook.com/groups/yagom/


p.s 제 포스팅을 RSS 피드로 받아보실 수 있습니다.

RSS Feed 받기   


저작자 표시 비영리 변경 금지
신고
Posted by yagom

# 재미있는 언어 Objective-C
여러분들께서는 오브젝티브-C를 어떻게 생각하시나요? 언어의 역사와 배경을 아는 것이 정말 무의미해 보일지 모르겠지만, 오브젝티브-C의 탄생 배경을 살펴보면 재미난 점도 많고, 사용하면서 부딪힐 의문에 대해서도 더 많이 이해하게 될 수 있습니다.
그럼 오브젝티브-C는 어떻게 태어났는지, 왜 제대로 알고 써야 할지 생각해 볼까요?

# Objective-C는 어떻게 탄생하고 발전해왔을까?
오브젝티브-C는 ‘객체 지향 프로그래밍 C언어 [Object-Oriented Programming in C, OOPC]’라는 이름으로 시작된 언어입니다. 즉, C를 객체 지향 언어로 발전시킨 것으로, 1983년에 발표되었습니다. 당시 사람들은 구조적 프로그래밍  습관에 따라 프로그래밍을 하였는데, 풀어내야 할 문제들이 많이 생겨나자 그 해결책으로 객체 지향 프로그래밍  연구를 활발히 하던 시절이었습니다.

애플사에서 나온 스티브 잡스는 넥스트사를 설립한 후 오브젝티브-C의 사용 허가를 받았습니다. 그는 회사를 꾸준히 발전시켜 넥스트스텝이라는 객체 지향형 운영체제에 사용하기 위하여 AppKit과 Foundation Kit 등을 개발하였습니다. 이것이 현재 애플 운영체제의 전신이 되었습니다. 그 후 넥스트는 애플에 합병되었고, 애플은 넥스트에서 쓰던 툴들을 기반으로 Mac OS X라는 운영체제를 출시하였습니다. 오늘날 애플의 Cocoa API 대부분은 이에 기반을 두었죠(애플 운영체제의 클래스 접두어가 대부분 NS인 것이 바로 이 때문입니다).

애플은 2006년 애플 세계 개발자 회의Apple Worldwide Developers Conference, WWDC에서 ‘현대적인 가비지 콜렉션, 문법 기능 향상, 런타임 성능 개선, 64비트 지원’을 포함하는 오브젝티브-C 언어의 리비전Rivision으로 오브젝티브-C 2.0 공개하였습니다. 즉, 우리가 현재 배우고 사용하고 있는 오브젝티브-C는 오브젝티브-C 2.0이죠.

# 왜 Objective-C의 특성을 살려야 할까?
앞에서 언급했듯이 오브젝티브-C는 조금은 독특한 역사를 가지고 있으며, 객체 지향의 특징을 구현하기 위하여 많은 고민을 거듭하여 발전한 언어입니다. 절차 지향 언어인 C에서 파생된 언어이고, 자세히 파헤쳐보면 100% 객체 지향 언어라고 하기에는 무리가 있지만, 저는 객체 지향 특성을 제대로 활용할 수 있는 몇 안 되는 언어 중에 하나라고 생각합니다. 또한, 같은 객체 지향 언어라 하더라도 C++, Java와는 조금 다른 특성들을 많이 갖고 있기에 기존에 개발하던 개발자들이라도 배워야 할 필요가 분명히 있습니다.

게다가 오브젝티브-C를 사용하는 것은 대부분 애플 기기 기반의 애플리케이션을 제작하려는 목적이므로 당연히 애플이 제공한 프레임워크 및 킷을 활용하여 제작할 것은 자명한 사실이죠.

지금에 비하여 처음의 Cocoa API는 오브젝티브-C의 특성을 잘 살리지 못했었습니다. 하지만 지금은 API의 특성을 이해하지 못하면 사용하기 어려울 정도로 오브젝티브-C의 특성들을 많이 활용하고 있습니다. 또한, 프로토콜(특히 Delegate), 카테고리, 블록, GCD 등 오브젝티브-C의 특징을 살린 API와 패턴들이 점점 많아지고 있습니다. 그러므로 좀 더 안정적이고, 유연하고, 빠른 애플리케이션 개발을 위하여 오브젝티브-C의 특성을 알아야 한다고 생각합니다



제 생각들을 조금 정리해 보았는데, 여러분들의 생각은 어떠신지요?
많은 고수분들의 의견을 들어보고 싶습니다 ^^

P.S. 오브젝티브-C를 오브젝트C 라고 잘못 표현하는 분들이 종종 계십니다. 정식명칭은 'Objective-C[오브젝티브-C]'가 맞습니다.

by yagom

facebook : http://www.facebook.com/yagomSoft

facebook group : https://www.facebook.com/groups/yagom/

twitter : http://www.twitter.com/yagomSoft ( @yagomsoft )

p.s 제 포스팅을 RSS 피드로 받아보실 수 있습니다.

RSS Feed 받기   

 


저작자 표시 비영리 변경 금지
신고
Posted by yagom


티스토리 툴바