Skip to main content

Design Patterns with Swift: Facade pattern


facade image

About the pattern

Facade pattern is one of the Structural Patterns. The main aim of it is to hide the complexity of a system, class or logic and provide all functionalities behind a simple interface. Commonly, Facade is implemented in a way that one class is related to other classes which represents a system logic. Please take a look at the diagram:
diagram
As you can see, there is one class called Facade which separates the logic from LogicA, LogicB, LogicC classes. As a result our client only call the Facade class in order to execute some methods that are implemented in other classes.

Implementation

Let’s imagine a simple scenario. You have already created a great app called Super-Photo. One of the core features of your app is saving/converting images with JPEG or PNG extension. In order to do this you want to save UIImage representation in two ways. One is saving it as a PNG type, the second is saving it as a JPEG file type.
Fistly, in order to handle our image types and possible errors in our code - it will be nice to have two enums that will make our code cleaner and more readable.
enum ImageSaverError: Error {
    case couldNotCreateDestinationPath
    case couldNotCreateJPEGDataFromImage
    case couldNotCreatePNGDataFromImage
    case couldNotSaveImageInDestinationPath
}

enum ImageType {
    case png
    case jpeg(compressionQuality: CGFloat)
}
On the next step you will need to create a class that will handle a data providing for each photo extension:
class ImageDataProvider {
    func data(from image: UIImage, type: ImageType) throws -> Data {
        switch type {
        case .jpeg(let compressionQuality):
            return try jpegData(from: image, compressionQuality: compressionQuality)
        case .png:
            return try pngData(from: image)
        }
    }

    private func pngData(from image: UIImage) throws -> Data {
        guard let imageData = UIImagePNGRepresentation(image) else { throw ImageSaverError.couldNotCreateJPEGDataFromImage }
        return imageData
    }

    private func jpegData(from image: UIImage, compressionQuality: CGFloat) throws -> Data {
        guard let imageData = UIImageJPEGRepresentation(image, compressionQuality) else { throw ImageSaverError.couldNotCreatePNGDataFromImage }
        return imageData
    }
}
As you’ve noticed, our ImageDataProvider takes image and type parameters and creates the image data with proper extension JPEG or PNG.
The last step is to create class which is needed to save UIImage. So let’s name it a PathProvider.
class PathProvider {
    func createDestinationPath(fileName: String) throws -> URL {
        guard let path = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first else {
            throw ImageSaverError.couldNotCreateDestinationPath
        }
        let destinationPath = path.appendingPathComponent("\(fileName)")
        return destinationPath
    }
}
Ok, so at the moment we have two classes with some logic inside. Now it’s time to create a facade for it!
let's do this
Create a class called ImageSaverFacade :
class ImageSaverFacade {
    private let pathProvider = PathProvider()
    private let dataProvider = ImageDataProvider()

    func save(image: UIImage, type: ImageType, fileName: String, overwrite: Bool) throws {
        let destinationURL = try pathProvider.createDestinationPath(fileName: fileName)
        let imageData = try dataProvider.data(from: image, type: type)
        let writingOptions: Data.WritingOptions = overwrite ? (.atomic) : (.withoutOverwriting)
        try imageData.write(to: destinationURL, options: writingOptions)
    }
}
Our ImageSaverFacade class has two private objects of PathProvider and ImageDataProvider class. Because the client doesn’t need to know anything about logic inside, the only thing which ImageSaverFacade exposes to a public is one method:
  • func save(image: UIImage, type: ImageType, fileName: String, overwrite: Bool) throws
This method is the only thing that our client should care about.
Now let’s move on to the facade usage part:
let imageSaver = ImageSaverFacade()
let image = UIImage(named: "my_image")!
do {
    try imageSaver.save(image: image, type: .png, fileName: "my_file_name", overwrite: true)
} catch  {
    //handle Error
}
// or
do {
    try imageSaver.save(image: image, type: .jpeg(compressionQuality: 1.0), fileName: "my_file_name", overwrite: false)
} catch  {
    //handle Error
}

Conclusion

Please notice that our facade covers logic associated with Data providing and creating a valid URL for file destination. And because of that, it is super easy to save UIImage as PNG or JPEG using our ImageSaverFacade. Only thing to do is to pass the correct parameters to facade method.
Facade design pattern can be used in many cases. Facade creates for you a simple gateway to a complicated system. By using it you will definitely make your code simpler to understand and read.

Comments

Popular posts from this blog

Swift Tool Belt, Part 1: Adding a Border, Corner Radius, and Shadow to a UIView with Interface Builder

During my iOS work, I’ve assembled a set of code that I bring with me on every iOS project. I’m not talking about large frameworks or CocoaPods here. These are smaller Swift extensions or control overrides that are applicable to many projects. I think of them as my tool belt. In this post, I’ll show you an extension that will add a border, a corner radius, and a shadow to any UIView, UIButton, or UILabel and allow you to preview what it will look like in Interface Builder. Back in 2014, I wrote a blog post on Expanding User-Defined Runtime Attributes in Xcode where I added a border, corner radius, and shadow to a UIView using Interface Builder’s user-defined runtime attributes. This solution had no type checking—you had to type the property you wanted to modify by hand and often had to look up what it was called. You also had to run your project in order to see the effect of the runtime attribute. Starting with Xcode 6 , there is a new mech...

Alamofire vs URLSession

Alamofire vs URLSession: a comparison for networking in Swift Alamofire and URLSession both help you to make network requests in Swift. The URLSession API is part of the foundation framework, whereas Alamofire needs to be added as an external dependency. Many  developers  doubt  whether it’s needed to include an extra dependency on something basic like networking in Swift. In the end, it’s perfectly doable to implement a networking layer with the great URLSession API’s which are available nowadays. This blog post is here to compare both frameworks and to find out when to add Alamofire as an external dependency. Build better iOS apps faster Looking for a great mobile CI/CD solution that has tons of iOS-specific tools, smooth code signing, and even real device testing? Learn more about Bitrise’s iOS specific solutions! This shows the real power of Alamofire as the framework makes a lot of things easier. What is Alamofire? Where URLSession...

Frame vs Bounds in iOS

This article is a repost of an answer I wrote on Stack Overflow . Short description frame = a view’s location and size using the parent view’s coordinate system ( important for placing the view in the parent) bounds = a view’s location and size using its own coordinate system (important for placing the view’s content or subviews within itself) Details To help me remember frame , I think of a picture frame on a wall . The picture frame is like the border of a view. I can hang the picture anywhere I want on the wall. In the same way, I can put a view anywhere I want inside a parent view (also called a superview). The parent view is like the wall. The origin of the coordinate system in iOS is the top left. We can put our view at the origin of the superview by setting the view frame’s x-y coordinates to (0, 0), which is like hanging our picture in the very top left corner of the wall. To move it right, increase x, to move it down increase y. To help me remember bound...