The metaphor of the “black box” is very common in programming. It is so general that it’s nearly meaningless; but it summarizes a lot of specialized principles nicely and shows a unifying principle. A black box is characterized by: It can be applied to “modules” on all levels of abstraction.
frameworkoriented.io hosts a text on “Framework Oriented Programming” (FOP). That title already looks similar to “Object-Oriented Programming”. But it’s not a replacement, mind you; it surely means the same for our cause as Cocoa UIKit/AppKit developers. The shift in perspective from object to framework works very well to illustrate the problem of designing large code bases.
Did you know you can import only parts of a module? Found this in the Swiftz sample codes:
let xs = [1, 2, 0, 3, 4]
import protocol Swiftz.Semigroup
import func Swiftz.sconcat
import struct Swiftz.Min
//: The least element of a list can be had with the Min Semigroup.
let smallestElement = sconcat(Min(2), t: xs.map { Min($0) }).value() // 0
import protocol or even import func were very new to me. Handy!
In a post about the Swift reflection API, I found the conversion code from a Bookmark struct to a Core Data object interesting. Let’s call the latter ManagedBookmark.
What puzzles me: which object should be responsible for the adaptation from one to the other?
Bookmark converts itself to a NSManagedObject using a NSManagedObjectContext you also have to pass in. (That’s what Benedikt did in his post.)ManagedBookmark provides an initializer or other factory taking in a Bookmark and, as always with managed objects, a NSManagedObjectContext.Option 2 is pretty clear. Using Bookmarks public interface, the managed object will set its attributes. This requires a NSManagedObject subclass wheras option 1 can work with a dictionary of values.
My main worry is that in option 1 Bookmark, a value type of the application, has to have knowledge about Core Data. Usually we’d fare better if we separate Core Data from our own model.
With extensions in Swift (and categories in Objective-C) we have the power to add new behavior to existing types in other locations. Does this help?
Extending a type in a different file hides that detail at first sight – but the extension, when it’s not private, is available in the rest of the code base, too. It just appears as if you put the code in the type definition itself.
Now if Bookmark is included in a “Bookmarking” module you import, an extension can add behavior without mixing Core Data visibly into the model layer. The Bookmarking module will not get altered when you extend one of its types in the client code.
I like organizing Swift code in modules because the boundaries are very strict. You cannot cheat yourself into mixing responsibilities and blurring boundaries that easily.
The Word Counter is my biggest software project so far, and it’s growing. To add features, I discovered the use of Swift modules with joy. I can write code for all levels of the new feature in isolation in a new project that compiles fast. Later I plug the resulting project and module into the Word Counter, et voilà: feature finished.