Maintaining state is the main cause of complexity and headaches in software development: without a careful consideration of state, our projects will inevitably become impossible to understand. In fact, various development techniques and programming styles are mainly there to handle state in a responsible way: for example, monads, as used in functional programming, are often employed for this very task. A good general way of managing state is trying to make it immutable, either through the use value types, that is, types which instances are passed around with deep copy semantics, or simple immutable objects, which have reference semantics but because they’re immutable their state is fixed.
Articles in category: Functional programming
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.
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.
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.
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.