Dependency Injection via the Recent "Cake Pattern in Swift" Pattern is Useless in Practice

Dependency Injection means you do not create objects where you use them but "inject" objects a function/method/object depends on from outside. This is a useful trick to make code testable, for example. Once you adopt the mindset, it becomes second nature. From the Java world stems the imperative to program against interfaces, not implementations. In Swift, this means to define injected dependencies not as concrete types but as protocols.

Continue reading …

Shopify's Ruby on Rails app statistics

Shopify published amazing/epic stats for their Ruby on Rails "app":

  • 860k LoC
  • 1:1.3 code–test ratio
  • 2300 model classes
  • most classes <10 methods
  • most methods way <10 lines

Makes you wonder:

  • can you live with more types?
  • can you shrink down existing types?

Swift changed the game a bit. Now it's very convenient to create a new type. You don't need to do the .h/.m file dance anymore but can start a new type declaration wherever you are. (Except when you're inside a generic type.) That makes it more likely we devs stop to shy away from smaller types.

But it's still a job for our community's culture to unlearn coding huge classes (massive view controller syndrome, anyone?) and splitting stuff.

Ruby has a long tradition of super-focused methods and very small classes. Swift is just as terse and powerful in that regard. Now it's your turn to experiment with writing types for very simple tasks. Like the Extract Parameter Object refactoring, where you lift things that go together into a new type.

Can be as easy as writing:

struct DateRange {
    let start: Date
    let end: Date

Et voilà, there you have a new explicit concept in your code base.

Framework Oriented Programming and It's Relation to OOP 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.

Continue reading …

Iteratively Improving Your App: Decoupling Components at Module Seams and Adding Facades

Teaser image

Façades are very important tools when I flesh-out the modules of an application. They turn out to be only the logical consequence of basic object-oriented programming principles, internal cohesion of objects namely, paired with decoupling of application modules (like "model" and "view"). Take a complex view that has many subviews. When you need to update a single piece of the user interface, how do you get there?

Continue reading …

Principles of Object-Oriented Design in Swift 2.2

Understanding Uncle Bob's Principles of Object-Oriented Design (which resulted in the SOLID principles) is super important to really grasp the use of design patterns (like MVVM) and architectural patterns (like VIPER). It's like the grammar for crafting proper object-oriented software.

And now here's the good news: there is a Swift playground (and Markdown file to read online) that illustrates all the principles by Uncle Bob: The Principles of OOD in Swift 2.2

Check it out, take notes, and keep the principles close to your heart. They may save your life someday.

Extract Private Functions as Collaborators

"Using a private function means having a hardwired link to an anonymous collaborator. Over time, this will slowly hurt more." (@jbrains) I was thinking about this the other day when I wrote tests for a presenter. It receives a date, formats it, and makes the view update a label with the result. Simple. (The real thing actually does a bit more, but that doesn't matter much.)

Continue reading …

Always Write Functions to Cope with all Possible Parameter Values

Matt Galagher is back writing at Cocoa with Love. His goal is maintainability, which is the greatest of all, I think. It's easy to copy code samples together to create an app, bur it's hard to create a product you can keep alive and make better over years. In that vein, his first article, "Partial functions in Swift, Part 1: Avoidance", includes a lot of details why partial functions will hurt you. This is a great topic. Read his post for the basic set theory involved.

Continue reading …

ReSwift, Law of Demeter, and Another Level of Indirection

Teaser image

Benjamin Encz's presentation "Unidirectional Data Flow in Swift" about ReSwift features global app state: there's one AppState type that acts as the facade to model and navigation state which is the single point of truth of every state in the app. This is a game changer when you suffer from massive view controller syndrome. In this post, I'd like to show you how he envisions the state of an app and what a next step could look like.

Continue reading …

How to Couple UITableView Cell Identifiers and View Models

Rui Peres proposes to make UITableViewCell view models the topmost model data. Traditionally, Cocoa developers stored something in arrays that corresponded to the indexPath of a cell. In principle, this qualifies as "model" data already, but it's not yet a view model. In practice, it can even be something different than a view model entirely – and make your view controllers slimmer!

Continue reading …

Separating State from State Changes

Reflecting on a recent change of the Word Counter's file monitoring module, I think I re-discovered a commonly advised pattern in my code: to separate state from state changes. There's an object that knows how to handle files based on extension: plain text files's words are counted differently than Word or Scrivener files. Call it Registry. Previously, this was set up once and didn't change. Now I wanted to make this configurable so users can add custom plain text extensions. This means changing that object's state.

Continue reading …

How Closures are a Better Event Handler Protocol Alternative

I don't like the way I tend to create view controller event handlers. They are almost always just a sink for methods which have nothing in common conceptually but are tied together because of the view's capabilities. So I began experimenting. Closures can encapsulate changes. This works well with callbacks for Repositories which fetch entities from your data store. Instead of returning them, you can pass them forward:

Continue reading …

Modeling: From Structured Data Representation to Problem Domain

Teaser image

Recently, I was discussing adding a feature to an application which is about event creation and booking. The project manager has a strong database background and works on the schema himself. The schema is also his go-to tool to express changes in the features. But thinking about the real Domain in terms of objects revealed much, much more.

Continue reading …

Where Instead of Using Functional Bind, I Create an Expressive Model

Teaser image

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.

Continue reading …

Split Commands and Informational Return Values Apart Using Events

When you reason about objects in your system and their means of communication, you can differentiate between three messaging flavors according to Mathias Verraes: imperative, interrogatory, and informational messages. Before we can talk about informational messages and their value, let's recap the other two and see what the difference is, because them calling for being extracted is not easy to spot.

Continue reading …