|
|
|
|
使用Swift扩展的“错误”方式
|
| |
|
作者：Natasha The Robot 来源：CSDN 发布于 2016-4-15 |
|
|
|
| 看到我Swift代码的人会立即询问，为什么要使用这么多的扩展。下面是我另一篇文章下面的一条评论：
翻译如下：非常感谢，这篇文章很不错。我一直疑惑你为什么要用这么多不必要的扩展，我认为你并未按照正确的用途来使用它们。能否简单地将它们当作一个整体类？
我使用扩展的主要原因是为了增加可读性。在这些地方我喜欢使用扩展，尽管“这并不是扩展设计的初衷”。
私有Helper函数
在OC语言中，.h和.m文件维护起来一样烦人，从.h文件中可以很容易地看出类的外部API，而内部API则保存在.m文件中。但在Swift中，我们只有一个文件。
因此，我们很容易看出类的公共函数：可以从外部及私有部分所访问的函数。我将私有内部函数放在私有扩展中，如下例：
// it's easy to glance and see which parts of this struct are
// supposed to be used externally
struct TodoItemViewModel {
let item: TodoItem
let indexPath: NSIndexPath
var delegate: ImageWithTextCellDelegate {
return TodoItemDelegate(item: item)
}
var attributedText: NSAttributedString {
// the itemContent logic is in the private extension
// keeping this code clean and easy to glance at
return itemContent
}
}
// keeps all this internal logic out of the public-facing API of this struct
// MARK: Private Attributed Text Builder Helper Methods
private extension TodoItemViewModel {
static var spaceBetweenInlineImages: NSAttributedString {
return NSAttributedString(string: " ")
}
var itemContent: NSAttributedString {
let text = NSMutableAttributedString(string: item.content, attributes:
[NSFontAttributeName : SmoresFont.regularFontOfSize(17.0)])
if let dueDate = item.dueDate {
appendDueDate(dueDate, toText: text)
}
for assignee in item.assignees {
appendAvatar(ofUser: assignee, toText: text)
}
return text
}
func appendDueDate(dueDate: NSDate, toText text: NSMutableAttributedString) {
if let calendarView = CalendarIconView.viewFromNib() {
calendarView.configure(withDate: dueDate)
if let calendarImage = UIImage.imageFromView(calendarView) {
appendImage(calendarImage, toText: text)
}
}
}
func appendAvatar(ofUser user: User, toText text: NSMutableAttributedString) {
if let avatarImage = user.avatar {
appendImage(avatarImage, toText: text)
} else {
appendDefaultAvatar(ofUser: user, toText: text)
downloadAvatarImage(forResource: user.avatarResource)
}
}
func downloadAvatarImage(forResource resource: Resource?) {
if let resource = resource {
KingfisherManager.sharedManager.retrieveImageWithResource(resource,
optionsInfo: nil,
progressBlock: nil)
{ image, error, cacheType, imageURL in
if let _ = image {
dispatch_async(dispatch_get_main_queue()) {
NSNotificationCenter.defaultCenter()
.postNotificationName(TodoItemViewModel.viewModelViewUpdatedNotification,
object: self.indexPath)
}
}
}
}
}
func appendDefaultAvatar(ofUser user: User, toText text: NSMutableAttributedString) {
if let defaultAvatar = user.defaultAvatar {
appendImage(defaultAvatar, toText: text)
}
}
func appendImage(image: UIImage, toText text: NSMutableAttributedString) {
text.appendAttributedString(TodoItemViewModel.spaceBetweenInlineImages)
let attachment = NSTextAttachment()
attachment.image = image
let yOffsetForImage = -7.0 as CGFloat
attachment.bounds = CGRectMake(0.0, yOffsetForImage, image.size.width, image.size.height)
let imageString = NSAttributedString(attachment: attachment)
text.appendAttributedString(imageString)
}
} |
注意：在上例中，属性字符串计算的逻辑超级复杂。如果存在于结构（struct）的主要部分中，我们就无法轻易发现它，并了解哪个部分比较重要了（在OC语言中这个部分是属于.h文件的）。 这样做也会使得代码更干净。
尤其如果这个属性字符串在代码中其他地方还有调用的话，使用这样的长扩展将逻辑重构到自身结构中会是很好的开头。不过在编写代码时，将它放在私有扩展中会更好。
分组
一开始我在Swift中真正使用扩展的原因在于：Swift刚出来的时候，无法添加pragma mark注释。没错，Swift出现后我想用它做的第一件事就是这个。在OC代码中，我通过pragma mark来进行区分，换到Swift后还想继续用。
于是我去了WWDC的Swift Labs，询问如何在Swift中添加pragma marks，回答者建议我使用扩展来替代。于是我开始使用扩展了，并完全爱上了这种用法。
尽管pragma marks（在Swift中是//MARK）非常棒，但在新写的代码中很容易忘记添加MARK，对于编码风格多样的团队来说更是如此。结果就是该MARK的函数没MARK上，不该加的反而有了。因此，如果一组函数之间相互归属，我倾向于将它们放在同一个扩展中。
一般我总会有一个扩展是将所有ViewController或者AppDelegate的初始样式设计方法归类到一起的：
private extension AppDelegate {
func configureAppStyling() {
styleNavigationBar()
styleBarButtons()
}
func styleNavigationBar() {
UINavigationBar.appearance().barTintColor = ColorPalette.ThemeColor
UINavigationBar.appearance().tintColor = ColorPalette.TintColor
UINavigationBar.appearance().titleTextAttributes = [
NSFontAttributeName : SmoresFont.boldFontOfSize(19.0),
NSForegroundColorAttributeName : UIColor.blackColor()
]
}
func styleBarButtons() {
let barButtonTextAttributes = [
NSFontAttributeName : SmoresFont.regularFontOfSize(17.0),
NSForegroundColorAttributeName : ColorPalette.TintColor
]
UIBarButtonItem.appearance().setTitleTextAttributes(barButtonTextAttributes, forState: .Normal)
}
} |
或者将所有通知逻辑归类到一起：
extension TodoListViewController {
// called in init
func addNotificationObservers() {
NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onViewModelUpdate:"),
name: TodoItemViewModel.viewModelViewUpdatedNotification, object: nil)
NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onTodoItemUpdate:"),
name: TodoItemDelegate.todoItemUpdatedNotification, object: nil)
}
func onViewModelUpdate(notification: NSNotification) {
if let indexPath = notification.object as? NSIndexPath {
tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
}
}
func onTodoItemUpdate(notification: NSNotification) {
if let itemObject = notification.object as? ValueWrapper {
let updatedItem = itemObject.value
let updatedTodoList = dataSource.listFromUpdatedItem(updatedItem)
dataSource = TodoListDataSource(todoList: updatedTodoList)
}
}
} |
协议一致性
This is a special case of grouping. 我喜欢将所有符合同一个协议的函数放在同一个扩展中。在OC语言中我是用pragma mark来实现的，但我更偏爱扩展的硬分隔和可读性：
struct TodoItemViewModel {
static let viewModelViewUpdatedNotification = "viewModelViewUpdatedNotification"
let item: TodoItem
let indexPath: NSIndexPath
var delegate: ImageWithTextCellDelegate {
return TodoItemDelegate(item: item)
}
var attributedText: NSAttributedString {
return itemContent
}
}
// ImageWithTextCellDataSource Protocol Conformance
extension TodoItemViewModel: ImageWithTextCellDataSource {
var imageName: String {
return item.completed ? "checkboxChecked" : "checkbox"
}
var attributedText: NSAttributedString {
return itemContent
}
} |
用扩展对UITableViewDataSource与UITableViewDelegate进行分割也很奏效。
// MARK: Table View Data Source
extension TodoListViewController: UITableViewDataSource {
func numberOfSectionsInTableView(tableView: UITableView) -> Int {
return dataSource.sections.count
}
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return dataSource.numberOfItemsInSection(section)
}
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath)
-> UITableViewCell {
let cell = tableView.dequeueReusableCellWithIdentifier(String.fromClass
(ImageWithTextTableViewCell),forIndexPath: indexPath) as!
ImageWithTextTableViewCell
let viewModel = dataSource.viewModelForCell(atIndexPath: indexPath)
cell.configure(withDataSource: viewModel, delegate: viewModel.delegate)
return cell
}
}
// MARK: Table View Delegate
extension TodoListViewController: UITableViewDelegate {
// MARK: Cell Selection
func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
performSegueWithIdentifier(todoItemSegueIdentifier, sender: self)
}
// MARK: Section Header Configuration
func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {
let view = UIView()
view.backgroundColor = ColorPalette.SectionSeparatorColor
return view
}
return nil
}
func tableView(tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {
return 1.0
}
return 0.0
}
// MARK: Deleting Action
func tableView(tableView: UITableView, canEditRowAtIndexPath indexPath: NSIndexPath) -> Bool {
return true
}
func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) ->
[UITableViewRowAction]? {
let deleteAction = UITableViewRowAction(style: .Destructive, title: "Delete")
{ [weak self] action , indexPath in
if let updatedTodoList = self?.dataSource.listFromDeletedIndexPath(indexPath) {
self?.dataSource = TodoListDataSource(todoList: updatedTodoList)
}
}
return [deleteAction]
}
} |
模型
我在OC中使用Core Data时非常喜欢使用模型，因为在更改时模型由Xcode生成，因此需要将函数或任何其他内容放入同一个扩展或分类中。
我尝试尽可能在Swift中使用结构，但还是更喜欢用扩展来分出模型属性与基于属性的计算。对我来说，这样增加了模型代码的可读性。
总结
尽管这种做法也许不够“传统”，在Swift中对扩展的超简单运用能极大程度地改善代码，让代码超级具有可读性。 |
|
|
|
|
