preface
I have to mention Objective-C when I talk about Swift.
As a contemporary language of C++, Objective-C was the child of Apple and Smalltalk, and apple had a lot of expectations for it.
However, with the development of times, people have summed up various programming ideas through numerous practices. With its weird brackets and dynamic language flaws, Apple is running up more and more technical debt. Use a trumpet when the big one is broken.
So Apple took all the features of modern languages, all the programming ideas, all the genetic quirks and created Swift. Swift, too, has apple on its back, while still promising not to abandon the Objective-C kid. (Of course, the reality is so cruel, objective-C is doomed to be abandoned, even though there are still a lot of fans, but if the real dad doesn’t want to feed it, it’s not going to work.)
Swift has a lot of genes from other languages, so many people have a lot of misconceptions about Swift. Some people think it is a scripting language, some think it is a grammatical sugar of OC, and some think it is slow.
In fact, it is different from JS, which was born in ten days. Swift contains a lot of detailed design, and every syntax has been carefully studied and rehearsed. Anyone who has been through Swift’s evolution and upgrade to the current stable Swift5 should know.
In these two days, I have tried several companies and found that there are companies that hire Swift programmers on the recruitment software.
But I’ve found that one of the biggest questions interviewers ask is what’s the difference between a class and a structure… What else is protocol oriented. And then it’s gone…
When it comes to distinguishing the capabilities of Swift programmers, these two questions are by no means sufficient. There are many questions to ask (the following questions are in a messy order of depth, not in increasing difficulty) :
1. What is the difference between a class and a structure
This is a question that many interviewers ask and more often want the answer to be
Classes and structs are created one on the heap and one on the stack (structs are generally optimized to be stored on the stack, but not always), or if a class is a reference type and a structure is a value type, any Swifter would know the answer. (Personally, I have tested the speed of struct and class creation. Since struct creation generally does not involve heap memory allocation, it is more than 10W faster than class creation. Earlier versions of Swift may not have been as effective and the 10W number is incorrect, but it is several orders of magnitude faster. Of course, class creation is not slow, but relatively speaking)
However, it is also possible to ask further questions, such as how to distinguish between classes and structs, how to distinguish between classes and classes, and why Swift designs structs and enumerations while having classes. , etc.
2. Copy-on-write mechanism
Swift itself advises programmers to use less classes and more enumerations of structures. But with structs, it’s easy to write code that doesn’t perform very well if you’re not clear about it. A copy-on-write mechanism is a must if you are an algorithmically demanding company.
3. Pattern matching
Unlike other languages that use the Switch syntax with more or less limitations, Swift’s Switch can Switch any object that implements the ~= operator in addition to enumerating numeric strings. It also supports WHERE clauses, match ranges, type inference conversions… And so on. With such a powerful Switch, it would be a pity not to ask in-depth questions during the interview.
4. Agreement
One of the highlights of Swift is its protocol-oriented development, which allows programmers to extend the default implementation. Not only can it achieve the similar effect of multiple inheritance in other languages, but also the protocol oriented development can bring great extensibility to the code.
5. The generic
Swift’s generics feel is really overdone, and the Swift standard library uses a lot of protocols and generics.
If you want to recruit a little level of Swift development, generics can not ask.
In addition to asking where generics constraints, you can also ask why the Swift standard library uses generics for functions such as swap Map, and what are the drawbacks of using only protocols.
You can also ask @_Specialize
Operators, subscripts, literal protocols, trailing closures
These features allow Swift to implement many syntax-level extensions.
7.Optional, variable constants, type checking, extension
Modern language design has many required choices. Kotlin and Swift have a lot in common, and each has its own strengths. However, they designed features like Optional, mainly because these features are the experience of many people who have stepped on the pit. Old age languages are generally fixed and cannot be changed much. New age languages are certainly designed with these features in mind.
8. Functional programming
Questions about functors, lists, and functions as first citizens are also required.
9. Responsive programming
Ask RxSwift or Apple’s new Combine. The idea is the same. For example, reactive programming in network requests, data parsing, UI response and so on
10. One-way data flow mode
Use Redux to ask some process principles for individual data flows. (Swift version has ReSwift or RxFeedback, etc.)
11.MVC, MVVM, Coordinator, one-way data flow
There is no standard answer to these patterns, which can be explored in depth
12.SwiftUI
Apple’s new UI library, combined with Flutter, discusses the benefits of each
13. Swift5.1 new features
For example, @propertyWrapper, @_functionBuilder, and @DynamicMemberLookup are all worth exploring
14.Swift expansion in other areas
For example, it will discuss the ideas of Swift in Web and back-end development, the advantages of Swift grammar in ARTIFICIAL intelligence, and the feasibility of Swift directly using libraries written in other languages.
conclusion
About a dozen questions, and a lot of good features and interview questions, too many to count.
In general, Swift is a difficult language with a small threshold for entry and a large threshold for further learning. It is easy to distinguish between programmers, and it is easy to see the difference in beauty and performance of Swift code written by two different programmers.
But once you figure out what Swift was designed for and why it was designed the way it was, you’ll find that everything works, Swift learns, and other languages are just as well.