Helge Heß recently posted on Mastodon that he “still find[s] it disturbing how many #SwiftLang devs implement Equatable as something that breaks the Equatable contract, just to please some API requiring it. Feels like they usually should implement Identifiable and build on top of that instead.”
Today was the second time during the development of TableFlip that I started to implement a new feature in the wrong way: starting with an explicit event type that is triggered by pressing a button in the user interface. This is a 1:1 mapping of user intent to an event that performs changes in the model. Next time I’ll start from another point of view instead to not rush too many minuscule changes until I hit a roadblock and hate myself. Here’s what went wrong.
I’m currently reading Object thinking by David West to get more general input on object-oriented programming. So far, it seems that most of the cool stuff I discovered for my coding practice in the past years is actually ages old. (Of course this is my interpretation, based on my current knowledge, re-producing and re-discovering expected results in new words.)
Lammert Westerhoff compared MVVM to Presentation Controls recently. Since nobody likes massive view controllers, I had a look, too, and found a few interesting things. To write a real app with his tips in mind, we’re going to need a bit more, though, and refactor things a bit.
It happens that just yesterday I read about architecture smells in code. Among the examples was “subclasses don’t redefine methods”. In my post about Core Data and expressive domains earlier this week, I did just that: create a Egg subclass of CoreDataEgg to inherit CoreDataEgg’s behavior. That’s not what abstraction to superclasses is meant to do.
I’ve written a whole book on the topic of architecting a Mac app using Core Data. Today I found an approach which doesn’t add lots of overhead and which also doesn’t clutter everything everywhere. It’s pretty simple and involves Swift.
Again I was reminded about the value of service objects to encapsulate sequences in two places: the Domain, where business rules are kept, and in client code, where database management and transactions play a role. This distinction helps create clean code and deliver flexible components. I am building a feature for the Word Counter in a separate “library” project until everything runs smoothly. Then I’ll integrate the code into the main application. Since I consider this to be some kind of library, I thought I wouldn’t need many service objects, but I was wrong.
The other day, I wrote a post about bind() and the >>= operator and how it can help chain function calls together. The example was a bit too contrived and making it fit the requirements left us with really bad code. I came up with an even better implementation: use plain Swift objects and express your intent carefully.
This weekend, I have just released my book on Mac software architecture. It’s called “Exploring Mac App Development Strategies”. In this book, I discuss how one can adopt practices for designing clean code and use it in spite of Apple’s rather invasive framework suggestions.
I’m adding a file monitoring feature to the Word Counter. This is a huge change to the application’s source code. To tackle this problem with style, I mulled things over for a while and considered my existing application’s design. I wanted to try out a few new things, so it was a no-brainer to start a sample project from scratch and fiddle with it.
I’m working on a way to make the Word Counter watch files and folders on a user’s disk. This will enable to measure project progress. Until now, I always used .plist files to store records with the end in mind that I’m going to switch to a better alternative in the future. Since I’m adding all-new data tracking, I thought I might as well try different solutions now.