I probably should have waited for the next iteration, but I was starting a new side-project and, well, there was that checkbox to use SwiftUI staring at me, taunting me, luring me in with the sweet promise of unending UI layout bliss. So I scrunched up my face, clicked the box, waited a minute for the trumpets to die down, and then created the project.
One of the key pillars of good architecture revolves around Interface Design. The reason for this is deceptively simple: software is complex and we want to do everything we can to make it as simple and easy as possible. Part of the entire point of OOP (Object Oriented Programming) is to abstract complicated code into objects and then hide that complexity behind a simplified interface. That way programmers don’t need to know what’s going on behind the scenes, and instead can deal with the abstraction. The interface should be the only thing someone needs to know about that object to use it. The only time someone should even consider the implementation is when they’re modifying it. This is an essential tool in battling the complexity of a codebase.
Now that I’ve spent quite a bit more time implementing a “handler” based development approach, I’m finding that there’s quite a bit I like about it. I still have some frustrations with it, and some unresolved questions, but overall I think this approach has some serious merits that warrant consideration as an Architecture approach to handling complex dependencies.
Lately I’ve been writing a Swift module for a project at work. I decided to branch out a little bit by utilizing a different design philosophy than I’ve used in the past. While Apple sits around and pretends that protocol based development is actually something new and exciting, I’ve been much more interested in the functional abilities that Swift seems to endow us with. To that end, I decided to escew protocols and instead define the dependencies in my objects using handlers1 instead. This means instead of defining a protocol and requiring an object that conforms to this protocol, I simply require the specific behavior itself. An example of a simple handler might be:
Or callbacks, functors, whatever… I’m going to stick with the term “Handler” because it seems to implicate the dependency, like I’m depending on someone else to “handle” the dependent behavior I need. If you want, feel free to copy this and do a search & replace for callback or functor or another term you feel more comfortable with. ↩
There are a lot of blog posts and probably even more opinions about Swift. I will continue this short, but certainly worthy trend.
There are three things I told myself I would not do when I started developing in Swift: