디자인 패턴은 프로그래밍 언어에 상관없이 적용되는 거지만 나는 지금 스위프트를 공부하고 있으니까...
xcode에서 처음 프로젝트를 생성하면 viewController와 main.storyboard 파일이 있는데 (swiftUI 말고 storyboard 선택한 경우) 맨 처음 ios 개발을 하나씩 배우다 보면 viewController 파일 하나에 모든 코드들을 몽땅 작성하게 된다. 화면에 보여줄 데이터, 그 데이터를 조작하거나 가져오는 부분 등.. 처음엔 간단히 작성하는 것이기 때문에 viewController 파일 하나에 작성해도 되지만 프로젝트 크기가 커지면 작성해야 하는 코드가 많아지고 다뤄야 하는 화면들도 많아지게 된다. 그래서 디자인 패턴을 적용하여 프로젝트를 관리하기 쉽게, 수정하기 쉽게, 새로운 기능을 추가하기 쉽게 관리할 필요가 있다.
그러므로 디자인 패턴이란...
소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
소프트웨어 설계 - 위키백과, 우리 모두의 백과사전
소프트웨어 설계 위키백과, 우리 모두의 백과사전.
ko.wikipedia.org
위키에 저렇게 정의되어 있다. 한글로 적혀 있는데도 알 듯 모를 듯한 이 느낌!
저기서 포인트가 되는 단어는 '템플릿', '형식'이라고 생각한다. 나는 좀 생소한 개념에 다가갈 때 내가 그 개념을 좀 더 친근하게 느낄 수 있는 예시를 생각해보려고 하는데 디자인 패턴은 아래처럼 생각해 보았다.
예를 들어 내 방에 책이 5권 있을 때와 도서관에 500,000권이 있을 때 책들을 정리해야 할 방식이 완전 다를 것이다. 책이 5권만 있다면 딱히 정리하지 않아도 내가 원하는 책을 찾아 읽기 쉽고 관리도 간단하다. 하지만 500,000권 중에서 내가 원하는 책을 찾거나, 혹은 새로 들여온 책을 정리하려면 이것들을 정리하고 분류할 체계(=디자인 패턴)가 필요하다.
1. 책을 분야 별로 나누고 (철학, it, 인문, 어학, 자연과학...)
2. 그 분야 안에서 ㄱ, ㄴ, ㄷ 순으로 정리
이렇게 정리 체계가 있다면 새로운 책이 들어와도 정리하기 쉽고 찾기도 쉽다. '하하하' 라는 철학 책을 찾으려고 하면 먼저 철학 책이 모인 곳으로 가서 ㅎ 섹션에서 책을 찾으면 될 것이고, '고고고' 라는 자연과학 책이 새로 들어오면 자연과학 책이 모인 곳에 ㄱ 섹션에다가 책 이름 순서에 맞게 책을 꽂아 넣으면 될 것이다.
(아는 책 이름이 없다.......)
마찬가지로 소스 코드 파일들도 역할에 따라 분류하여 정리해놓으면 나중에 소스 코드를 수정해야 할 때 수정해야 할 파일이 어디 있는지 찾을 수 있고 새로운 기능을 작성할 때도 해당 소스 코드 파일을 어디로 분류하여 넣어 놓을 지 알 수 있을 것이다. (또는 현재 체계에 맞게 소스 코드 파일을 잘게 쪼개어 작성하는 데에도 도움이 되는 것 같다. ) 또한 소스 코드는 나 혼자만 작성하지 않는다. 내가 작성한 것을 다른 사람이 고쳐야 하는 경우는 아주 흔하다. 그렇기 때문에 철학 책, 영어책, 과학책 등을 한 곳에 몽땅 섞어놓는 것보다 템플릿을 정해놓고 그것에 맞게 소스 코드 파일들을 정리해가면서 프로젝트를 만드는 것이 바람직할 것이다.
디자인 패턴의 종류는 아주 많은데 상황에 따라, 프로젝트에 따라 또는 개인이나 조직의 선호에 따라 어느 디자인 패턴을 사용할 지 결정하면 되는 것 같다. 오늘은 MVC에 대해 간단히 정리하려고 한다.
(이렇게 안 하면 오늘 배운 것은 다음날 아침밥 먹으면서 다 잊어버리는 것 같다..)
MVC는 model, view, controller의 약자다. model, view, controller는 위의 도서관 예시처럼 '철학, 인문, 자연과학' 처럼 그 특징, 그 역할에 따라 부여된 이름이라고 생각하면 될 것 같다. model에는 앱에서 다루는 데이터와 그 데이터를 조작하거나 찾거나 하는 등의 로직도 포함된다. model에 들어갈만 한 내용은 대충 이렇게 만들 수 있을 것 같다.
2022.02.14 추가: 그리고... model의 가장 중요한 부분은 UI와 분리되어야 한다는 것이다 (UI independant). 모델에서는 이게 스크린에 어떻게 보일 것인지? 에 대한 고민을 하고 있으면 안된다! 스크린에 어떻게 보여야 하는가는 컨트롤러에서 담당할 문제다.
// model 파일 이름을 ~Source로 할 지 ~Manager로 할 지 ~Service로 할 지...그건 아직 잘 모르겠음
struct FruitSource {
// fruits 라는 데이터 (Fruit 이라는 struct 이 있다고 가정)
let fruits = [
Fruit(name: "apple", price: 200),
Fruit(name: "guava", price: 400),
Fruit(name: "orange", price: 150),
Fruit(name: "grapefruit", price: 200)
]
// 데이터를 다룰 로직들..
func getFruitNum() -> Int { // fruits라는 데이터의 갯수를 반환
return fruits.count
}
func getApple() -> Fruit { // fruits라는 데이터의 맨 첫번째 요소를 반환
return fruits[0]
}
mutating func addNewFruit(newFruit: Fruit) { // fruits라는 데이터에 새로운 데이터 하나 추가
fruits.append(newFruit)
}
}
view에는 main.storyboard 라는 화면을 보여주는 부분이 포함되며 controller가 시키는 대로 스크린에 무언가를 보여줘야 한다. controller는 viewContoller 파일처럼 이 앱이 스크린에 어떻게 보일지에 대한 것을 담당한다. (how your model is presented to the user) 그래서 뷰를 컨트롤 하기도 하고 뷰에 어떤 것을 보이도록 하기 위해 모델에 작성된 메소드들을 적절히 활용하여 필요한 데이터 요청하여 가져와서 뷰에 뿌리는 역할을 하기도 한다.
// viewController 파일
let currentFruits = FruitSource()
let fruitsNum = currentFruits.getFruitNum()
let currentApple = currentFruits.getApple()
currentFruits.addNewFruit(Fruit(name: "lemon", price: "120"))
mvc 패턴에서는 view에서 model한테 'currentFruits'라는 데이터를 controller 없이 바로 요청하거나 또는 model에서 view를 바로 변경하거나 하지 않는다. 이렇게 각 파일마다 정해진 역할이 정해져 있고 그것을 지키려고 노력하면서 소스 코드를 작성하면 될 것 같다. controller는 약간 매니저급, 팀장, 부장(??) 같은 느낌이고 model, view가 실무자 같은 느낌이다. 그래서 controller가 'fruit 데이터 내놔' 하면 model에 데이터를 반환하는 메소드를 작성해놓고 '새로운 Fruit 넘길테니까 좀 추가해봐' 하면 Fruit을 받아서 추가하는 메소드를 작성하면 될 것 같다. 또한 데이터들을 가지고 controller가 ui 요소들을 업데이트 하는 코드들을 작성해놓으면 view가 그것에 맞게 화면에 보여주는 것도 그렇고.. (이런 비유는 하지말까)
실무를 하면서 파일을 각자 역할에 맞게 모듈화 하는 것이 중요하다는 것을 알았기 때문에 이런 디자인 패턴을 좀 더 내 것으로 만들고 잘 이해하고 싶은 생각이 든다.
다음엔 MVVM으로 작성해 봐야겠다.