In Swift, a general best practice has come about to place protocol conformance for a class into a separate extension. This helps separate out code into logical sections:
class SuperClass: UIViewController {
...
}
extension SuperClass: UITableViewDelegate {
...
}
However, in an app I am currently working on, a base superclass and subclass both need to provide methods for UITableViewDelegate.
To logically separate the code, one would think to do:
class Subclass: SuperClass {
...
}
extension Subclass: UITableViewDelegate {
...
}
However, Swift complains that the class already conforms to the protocol. At the moment, I have simply removed the : UITableViewDelegate part of the extension.
This seems to be a bit of a caveat of using this best practice. Are there any better ways of organising code in this case?
Related
This question already has an answer here:
Extensions in my own custom class
(1 answer)
Closed 6 years ago.
The Alamofire API has extensions such as extension Request in ResponseSerialization.swift. When designing a Swift API why would you take this approach as opposed to just adding these methods to the Request class (Request.swift)?
I understand the use of extensions to extend API's when you don't control the source. This question is about using them to extend your own API.
For cleanliness or adding functionality to other classes you didn't create (i.e. extension UIColor). You can create separate extensions to add in separate bits of functionality.
For example, if you have a UIViewController and you add a table view to it's view, instead of making the declaration of ViewController look like this:
class ViewController : UIViewController, UITableViewDataSource, UITableViewDelegate
you could separate it all with extensions so you don't clutter your ViewController file.
Like so:
extension ViewController : UITableViewDataSource, UITableViewDelegate
which you could separate from the main body of the ViewController class or extract into a new file.
Extensions are one of the best features of Swift programming language and there are several use cases for them. Once you hold a grip of them you can come up with some really good and understandable code. Some of the use cases are:
1. Extending system types
With Swift you can any system type like Int or String to make some code more readable and to get some more functionality you would otherwise have to write on your own. For example, check out following code that repeats some task a number of times:
extension Int {
func repetitions(task: () -> Void) {
for _ in 0..<self {
task()
}
}
}
Instead of creating separate function for task repetition and managing several parameters you can just extend Int and make it more readable:
3.repetitions({
print("Hello!")
})
// Hello!
// Hello!
// Hello!
Everybody can agree that this is the simplest and cleanest code you can ever create.
2. Make messy code readable
Check the following definition:
class MyTableViewController: UIViewController, UITableViewDelegate, UITableViewDataSource, CLLocationManagerDelegate {
// a lot of functions
}
If you put everything inside one class or structure, code will get messy at one point and it'll be hard to track which method belongs to which protocol or class. Instead you should be using this:
class MyTableViewController: UIViewController {
}
extension MyTableViewController: UITableViewDelegate {
}
extension MyTableViewController: UITableViewDataSource {
}
// etc...
3. Protocol extensions
Protocol extension are one of the coolest features of Swift. They enable adding methods to any class that adopts the protocol you are extending. For example let's extend CollectionType protocol.
extension CollectionType {
func printAll() {
print(self)
}
}
Now you can use method printAll() on any structure that adopt this protocol! Some of them are native Swift types like Array, Dictionary or Set.
These are just some of the main usages of extensions and they can do a lot more:
Add computed instance properties and computed type properties
Define instance methods and type methods
Provide new initializers
Define subscripts
Define and use new nested types
Make an existing type conform to a protocol
In order to be a bit more clear I am looking for a solution for the user to pass a class with a specific subclass and protocol, i.e. a class that inherits a viewController and delegate protocol. I know its possible to create a protocol list but cannot find a solution that works correctly. Currently I use a initializer and use the viewcontroller as a parameter and check for delegate inside the function but I would rather if I can have these types in the parameter instead.
EDIT:
Looking to do something similar to this
Protocol prot:Delegate{}
class cla:ViewController{}
class impl{
init(mainUI: cla, prot){
do things
}
}
That way back in the main view controller I can do something like this
class viewController: cla, prot{
var view:impl
override func loadView() {
//Attach to Screen
view = impl(mainUI: self);
}
}
Their is a bit more happening but that's the only part thats really relevant. Currently I use a initializer to just fail if the class doesn't inherit the correct protocols
You could create a dummy type that represents your requirements. A typealias doesn't work in this case, but this might:
class DummyClass: MyViewController, MyDelegateProtocol {}
func needsRequiredClass(input: DummyClass) {...}
With MyViewController and MyDelegateProtocol being the superclass and delegate you mentioned. The DummyClass would have an empty implementation.
Then, make your specific classes sub classes of DummyClass:
class TestClass: DummyClass {...}
And you can pass in that new class:
let test = TestClass()
self.needsRequiredClass(test)
You're asking the wrong question. In other words trying to shoe-horn in a serious design mistake.
A view should not know that its delegate is a UIViewController or a subclass.
A delegate should be any class that obeys (adopts) a specific delegate protocol.
A view should only delegate specific responsibilities. Each of those responsibilities must be described by a protocol method or property.
If you explain what your issue is in more detail (why you think you need direct access to the entire definition of a UIViewController within a UIView), we can help you avoid this mistake.
I don't understand why programmers use the extension keyword in their class implementation. You can read in other topics that code is then more semantically separated and etc. But when I work with my own code, it feels clearer to me to use // MARK - Something. Then when you use methods list (ctrl+6) in Xcode, everything is seen at first look.
In Apple documentation you can read:
“Extensions add new functionality to an existing class, structure, or enumeration type.”
So why not write my own code directly inside my own class? Unlike when I want to extend functionality of some foreign class, like NSURLSession or Dictionary, where you have to use extensions.
Mattt Thompson use extension in his Alamofire library, maybe he can give me little explanation, why he chose this approach.
For me it seems completely reasonable since you can use extensions to expose different parts of logic to different extensions. This can also be used to make class conformance to protocols more readable, for instance
class ViewController: UIViewController {
...
}
extension ViewController: UITableViewDelegate {
...
}
extension ViewController: UITableViewDataSource {
...
}
extension ViewController: UITextFieldDelegate {
...
}
Protocol methods are separated in different extensions for clarity, this seems to be far better to read than lets say:
class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSource, UITextFieldDelegate {}
So, I'd say there's no harm in using extensions to make your own code more readable, not just to extend already existing classes from SDK. Using extensions you can avoid having huge chunks of code in your controllers and split functionality into easily readable parts, so there's no disadvantage of using those.
Using extensions allows you to keep your declaration of protocol conformance next to the methods that implement that protocol.
If there were no extensions, imagine declaring your type as:
struct Queue<T>: SequenceType, ArrayLiteralConvertible, Equatable, Printable, Deflectable, VariousOtherables {
// lotsa code...
// and here we find the implementation of ArrayLiteralConvertible
/// Create an instance containing `elements`.
init(arrayLiteral elements: T…) {
etc
}
}
Contrast this with using extensions, where you bundle together the implementation of the protocols with those specific methods that implement it:
struct Queue<T> {
// here go the basics of queue - the essential member variables,
// maybe the enqueue and dequeue methods
}
extension SequenceType {
// here go just the specifics of what you need for a sequence type
typealias Generator = GeneratorOf<T>
func generate() -> Generator {
return GeneratorOf {
// etc.
}
}
}
extension Queue: ArrayLiteralConvertible {
init(arrayLiteral elements: T...) {
// etc.
}
}
Yes, you can mark your protocol implementations with // MARK (and bear in mind, you can combine both techniques), but you would still be split across the top of the file, where the declaration of protocol support would be, and the body of the file, where your implementation is.
Also, bear in mind if you’re implementing a protocol, you will get helpful (if slightly verbose) feedback from the IDE as you go, telling you what you’ve got left to implement. Using extensions to do each protocol one by one makes it (for me) far easier than doing it all in one go (or hopping back and forth from top to bottom as you add them).
Given this, it’s then natural to group other, non-protocol but related methods into extensions as well.
I actually find it frustrating occasionally when you can’t do this. For example,
extension Queue: CollectionType {
// amongst other things, subscript get:
subscript(idx: Index) -> T {
// etc
}
}
// all MutableCollectionType adds is a subscript setter
extension Queue: MutableCollectionType {
// this is not valid - you’re redeclaring subscript(Index)
subscript(idx: Int) -> T {
// and this is not valid - you must declare
// a get when you declare a set
set(val) {
// etc
}
}
}
So you have to implement both within the same extension.
I need to add some behavior to UICollectionViewDataSource.
If I were to create a Collection View extension, I would do:
extension UICollectionView
{
func thisWorks() {}
}
But attempting to do it for the Data Source causes a "Protocol 'UICollectionViewDataSource' cannot be extended" error.
extension UICollectionViewDataSource
{
func thisDoesntWork() {}
}
Is there a way to add a new func to a protocol?
As reported in Extensions:
Extensions add new functionality to an existing class, structure, or enumeration type
So extending a protocol is not possible - they support inheritance, which means you can subclass a protocol.
However, I think that protocol extension wouldn't make much sense. If you extend UICollectionViewDataSource, it means that all classes adopting it would fail to compile because of the new requirements set by the extensions - including UIKit classes, such as UICollectionViewController, which itself implements UICollectionViewDataSource
In your case, I think that there are 2 solutions:
create a new protocol inherited from UICollectionViewDataSource
create a separated protocol, not linked to UICollectionViewDataSource (but most likely having a similar name)
I would choose option no. 2, because the former makes the code less readable, by hiding the UICollectionViewDataSource name in your class declaration.
In short, no. And you don't need to - anything expecting to work with a UICollectionViewDataSource is only expecting particular methods to be there. Just declare your own custom protocol, conform to that, and then use it in your classes where appropriate:
extension MyCustomCollectionViewDataSource {
func thisWorks() {}
}
For example, these are valid and will compile without (all) protocol stubs
public class ViewController: UIViewController, SFSpeechRecognizerDelegate {
}
class BLEController: CBCentralManager, CBCentralManagerDelegate {
func centralManagerDidUpdateState(_ central: CBCentralManager) {
}
}
Edit: Solved! Creating a class without inheriting from UIViewController or CBCentralManager still does comply with the delegate protocols, but it does not comply with NSObjectProtocol. It just seems to be that I'm attempting to use the frameworks in an unintended way.
Why does my code compile without fulfilling all the protocol requirements?
What you are seeing here are optional protocol requirements. They are here because Swift code needs to interact with Objective-C, and Objective-C has them.
All methods except centralManagerDidUpdateState declared in CBCentralManagerDelegate are optional, from here:
The only required method is centralManagerDidUpdateState(_:); the central manager calls this when its state updates, thereby indicating the availability of the central manager.
And SFSpeechRecognizerDelegate, only contains one optional method, from here:
Use this protocol's optional method to track those changes and provide an appropriate response.
why does the code not compile if you remove the superclasses then?
This is because both of those protocols in your question also inherit from NSObjectProtocol, so they actually also have the additional requirements of NSObjectProtocol. UIViewController and CBCentralManager both inherits from NSObject, so they satisfy the NSObjectProtocol requirements, but your Swift class without a superclass doesn't.
Protocols with optional requirements don't have to inherit from NSObjectProtocol though. It's just that most of them are that way in the framework. You can for example do:
#objc protocol Foo {
#objc optional func foo()
}
class FooClass : Foo {
// compiles fine!
}
It compiles without needing the protocol stubs because all the requirement is optional. Check within the declaration of SFSpeechRecognizerDelegate it has only one requirement for a method called availabilityDidChange and you can see that it's optional from the keyword given at the beginning of the function.
In the second case, the class you have created doesn't inherit from NSObject but the first one does because it's a sub-class of UIViewController which in-turn is a sub-class of NSObject.