Tutorial 3: My Locations. Solution to Exercise at p. 222

The exercise task at p. 222 to rewrite the logic to use a didSet property observer on the image instance variable so placing the photo into image will automatically update the UIImageView, without needing to call show(image) looks not so clear to me as you either need to call show(image) from the observer or move the logic from that function to the observer so I ended with this:

func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : Any]) {

    image = info[UIImagePickerControllerEditedImage] as? UIImage

    dismiss(animated: true, completion: nil)

var image: UIImage? {
    didSet {
        if let theImage = image {
            show(image: theImage)

Has anyone avoided that calling show(image)?

Have the same question…

@hollance @fahim Can you please help with this one when you get a chance? Thank you - much appreciated! :]

You could try to move the code that is inside show(image:) into the didSet.

Moving logic into the didSet makes no sense from OO point of view because you lose encapsulation.

In what sense do you think we lose encapsulation?

The logic of showing an image is encapsulated in this function. If in the future the requirements will change where or how to show an image you need to change the logic just in one place while all other places simply call this logic. Even if there are two places it’s hard to remember/recollecte where they are which gives you a potential bug.

I don’t agree. By moving the logic for showing the image into the property for the image, you simplify the logic – now the only way to change the contents of the image view is through the image property. Therefore, it hides an implementation detail (the existence of the image view) and actually increases encapsulation.

In the current state of affairs, you’re right. The show(image:) is called in one place and moving in into the didSet is better. What I want to say that decoupling the logic from the didSet has an aim to ease development in the future if requirements change.

Perhaps… it depends on the future. :wink: It’s usually impossible to see into the future, and many would argue that already preparing your code for a future that might never happen is not a good use of your time.

Of course, if you are 99% sure that you’re going to have to add a new feature to the app that requires you to have a separate show(image:) method, then it makes sense to have it as a separate method. But if not, then making it separate method “just in case” is not guaranteed to actually make your code any better.

You’re quite right, my friend. This is the hardest part to find the ‘Golden Spot’ in decoupling and encapsulation. I bet, it’s a skill gained with an experience to predict what parts of your code are possible to be changed in the future.

1 Like

This topic was automatically closed after 166 days. New replies are no longer allowed.