Avoiding property/method naming conflicts in Swift

Illustration by Olga P

Modern application development is reliant on code which is written by other people. Most developers today use open source libraries. This can mean that two or more libraries can have the same method/property definition extension on the same object. You don’t want to end up in this situation.

Noooooooooooooooooo

There are a few ways we can deal with this issue, among them there are two I’d like to discuss in this article, prefixed naming and namespaces.

Prefixed naming

Let’s start with something basic. I want to be able to set an image to an UIImageView from a URL. Normally what you’ll have to do is to create a code snippet that will download image data, then convert it into a UIImage. Fortunately, there are libraries out there that do this for us and the code snippet more like this:

Now that’s very easy, but sometimes when we work on larger and larger projects there can be scenarios when one library and another one has the same method definition and that can be a problem.

Some modern iOS libraries prevent the same name extension methods by adding a prefix on their method names. For example, we have AlamofireImage and, SDWebImage. These libraries usually add a prefix that contains a few letters from their name, example:

Now everywhere within your codebase, you’ll have either one of these implementations, and you won’t have to deal with naming issues anymore.

This solution, although it solves the problem, can also prove to be a problem in the future when you would want to remove the specific library, and you would have to refactor tons of lines in your code because of heavy reliance on these methods.

A solution for this is to create your own extension method, which essentially just wraps these methods so when you refactor, all you need is to change one file. For example:

In the future when you would replace this, it can be as easy as changing at least two lines of code. 🎉

Note: Comments are there for the sake of this article.

Great now we don’t have to worry about refactoring!

But what if another library once again has the same method definition as setImage(_:, placeholder:)? Once again it’s the same problem 😫

This solution can further be improved by using Namespaces

Namespaces

Namespaces are used so we can group related methods and properties and avoid naming conflicts between multiple identifiers which may share the same name.

You might not know it but you might already have been using libraries that use this syntax. A few libraries that use namespaces inside extensions include the ff:

• SnapKit
• KingFisher

What I mean by this is that these libraries normally place their implementations on extension containers. Observe the code below for an example.

If you’ve noticed normally the UIImageView object doesn’t have the kf and snp properties. These properties are special namespaces that these libraries have created. There are multiple benefits to this, here are some:

• Lower chance for two libraries to have conflicts: What are the chances that two same libraries would be used for UIKit objects which have the same namespace name snp.
• Better IntelliSense experience: Once they implement this, once you type imageView.snp. you will only get the methods they declared in their namespace.

How do I do this on my own?

1.) Create a container for your namespace. Normally this is done with generics, but we won’t complicate things for now.

2.) Create your preferred namespace as an extension in an object.

3.) Put them together your code should look something like this:

4.) Add your implementations. I chose to use Kingfisher on my implementation.

5.) Finally here’s how to use it.

Conclusion

Property/Method naming can be avoided best by using namespaces. By using namespaces you not only improved code discovery of your end-user, i.e. other coders, but also you made a way to make refactors easier since you only need to edit one location. Other than that, and this is just to repeat what I said earlier, your IntelliSense is a lot more cleaner now! 🎉

If you’re reading this, then you’ve reached the end. Cheers! 🍻

If you have any comments, suggestions, questions, or ideas for new blog posts leave a comment down below. 👇👇

Thank you for taking the time on reading my article. 🎉

Gif from Tenor