Articles in category: Swift
Last time we looked at the Signal class, that is, a simple, reusable way of encapsulating the observer pattern. There are many use cases for a signal, and I’m going to show one possible application, spawned from a real-world problem. View controllers’ composition and decoupling is hard: we often need an input from a view controller, that has to send its input back to its creator, while handling the back navigation somehow. We often find ourselves in a situation in which several different responsibilities are all expressed in a single view controller, with the effect of creating a gigantic class, full of entangled imperative statements, hard-to-understand sequencing and general complexity. We’ll use the Signal class to assign the various responsibilities to different classes, and write cleaner, more declarative code. The core of this architectural pattern lies in inverting the way in which objects communicate, view controller or other: instead of asking objects to do things, we’re going to observe what objects are doing, and react accordingly. Observe and React are the cornerstones of the programming paradigm known as functional reactive programming(FRP); the present article is not going to talk about FRP as a whole, nor to present shared FRP techniques; the point is to discuss an architectural pattern for decoupling view controllers from responsibilities not strictly related to user interaction, by leveraging some basic FRP tools.
Last time we looked at a possible implementation for the Optional type in Objective-C; while the main point was to port to Objective-C a tool that’s frequently used in Swift, making use of the Optional class can be considered an application of a much more general concept: code reuse. In fact, Optional is not tied to a particular domain, and can be reused over and over again in multiple projects: that’s what actually happens in Swift. But, to think about it, that’s what happens for a wide range of classes in Objective-C, or types in Swift: for example, NSArray and Array are both constructs that expose a certain interface, have a certain implementation, and are reused multiple times within methods and functions. And again, NSArray and Array are not tied to a particular domain, and have two important properties:
L’ultima volta abbiamo visto una possibile implementazione del tipo Optional in Objective-C; l’obiettivo primario dell’articolo era quello di importare in Objective-C uno strumento frequentemente utilizzato in Swift, ma usare una classe come Optional può essere considerato un’applicazione di un concetto molto più generale: il riutilizzo del codice. In effetti, Optional non è legato a un particolare dominio, e può essere riutilizzato più e più volte in molti progetti: questo è esattamente ciò che accade in Swift. Ma a pensarci bene, questo è ciò che accade per una grande varietà di classi in Objective-C (e di tipi in Swift): ad esempio, NSArray e Array sono entrambi costrutti che espongono una specifica interfaccia, possiedono una certa implementazione, e vengono riutilizzati continuamente in metodi e funzioni. NSArray e Array non sono legati a un particolare dominio, e possiedono due importanti caratteristiche:
Objective-C is not going anywhere. While Swift is most certainly the new hotness for iOS and OS X programming, there are some concrete reasons to stick with Objective-C for a while:
- Objective-C based projects still need maintenance and new features to be added, and mixing Swift and Objective-C, while possible, can be tricky and possibly unconvenient, due to the dynamic nature of the latter;
- Swift is changing rapidly, has still some bugs and performance problems, and still lacks some features that professionals need, while Objective-C is mature and has a strong community;
- some may prefer a more dynamic language, and Objective-C support from Apple is still strong;
Personally, while I naturally lean towards a more static, type-first approach to programming, from time to time I like to work in a more dynamic environment, so both for preference and for business needs, I still didn’t put Objective-C completely away. But just after a few weeks of Swift I found myself missing one of the most powerful features of the language: Optionals.
Objective-C vivrà ancora per molto. Nonostante Swift sia il nuovo punto di riferimento per lo sviluppo iOS e OS X, ci sono ragioni concrete per scegliere di continuare a sviluppare in Objective-C, almeno per un po':
- progetti esistenti basati su Objective-C richiedono ancora mantenimento e probabile aggiunta di nuove funzionalità, e anche se è tecnicamente possibile mescolare i linguaggi, la cosa può risultare poco conveniente per via della natura molto dinamica di Objective-C;
- Swift sta cambiando rapidamente, presenta ancora alcuni bug e problemi di performance, e il suo workflow manca ancora di alcune feature fondamentali per i professionisti, mentre Objective-C è un linguaggio maturo, con una community molto vivace;
- alcuni possono preferire un linguaggio più dinamico, e il supporto di Apple su Objective-C è ancora forte;
Personalmente ho la tendenza a preferire linguaggi più statici, e un approccio type-first alla programmazione, ma di tanto in tanto mi piace lavorare in un ambiente più dinamico, quindi, sia per preferenza personale che per esigenze di business, non ho ancora messo Objective-C da parte. Ma dopo poche settimane di Swift, mi è mancata subito una delle sue funzionalità più potenti: gli Optionals.
