{
  "$type": "site.standard.document",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihdwjjsewwuyzjje24dfhbaqbj2qfdu42fvtrq2oqwtxtfofa6kaa"
    },
    "mimeType": "image/png",
    "size": 61301
  },
  "description": "<p>Use composition over inheritance. Pass values into functions.</p>",
  "path": "/se0117-has-the-power-to-change-sdk-design",
  "publishedAt": "2016-07-19T00:00:00.000Z",
  "site": "at://did:plc:wm37qzgdjvwztq6loytrtpul/site.standard.publication/3mgjrev2z22sw",
  "textContent": "A lot of conversation has been going around about\nSE-0117\nthis week, as the proposal has entered its Active Review stage.The tl;dr on this proposal is that all classes that are marked as public will\nnot be able to be subclassed unless also marked open. Additionally, it’s\nfunctions, variables, and subscripts would also not be overridden unless\nexplicitly marked as open. This means that classes will end up having behavior\nthat some have dubbed \"final by default\" for any publicly available class.\nThis behavior would eliminate the need for the compiler to generate dynamic\ndispatching for methods and properties since their implementation cannot be\nchanged after compiletime. While the elimination of dynamic dispatch is a\nperformance boost, this means extra care and attention will be required to turn\ndynamic dispatch back on for those who want consumers to override the\nfunctionality of of their publicly exposed classes.The changes here are quite interesting. People have taken to blogs and Twitter\nto express their opinions about how this will affect their development and\nworkflow.One argument against the proposal that I’ve often heard has been that been that\nthis reduces, if not entirely eliminates, the dynamism of a language like\nObjective-C. There’s no getting around that elephant in the room; this is a\nmajor change.However, I do think there are some resulting behaviors that have the power to\npush some core values forward in a way that will make Swift an even better\nlanguage to work in.Lean on Protocols to Define the Behavior You ExpectAPIs that expose functions that take in protocols rather than classes or\nsubclasses will flourish. We don’t need to wrap up our intended behavior or\nproperties into a class just to get the code we need run, but rather we can\nmake the decision to use a struct or class, choosing value vs reference\nsemantics.This means that no matter what type we pass in, we’ll be able to get some\nproperty or call some function, regardless of what class, subclass, or\nsubsubsubclass with its subsubclasses pass in.This will lead to SDKs that don’t make you subclass XYZModel for their\nbehavior and will allow you to create beautiful, testable, understandable,\ncomprehensible code. The extraction of MTLModel in\nMantle from a class to a protocol\nin this PR is almost a case study\nin the benefits of this type of API design. By moving the behaviors of\nMTLModel off to protocol implementations, consumers of Mantle were no longer\nforced into making their types inherit from MTLModel, but let them choose\ntheir type that implemented the behavior. Craziest part of all? This\nconversation was happening in Objective-C-land, not Swiftopia.Arguments against this proposal that circle around “subclassing lets me write\ncode that I can test” are immediately moot if the API that they are trying to\ntest takes in a protocol rather than a class.For more about this, watch me wax poetic about\nMocks in Swift via Protocols.Encourage Composition over InheritanceClamping down on how classes’ behaviors can be modified or extended means that\ndevelopers will need to find other ways to get the results they need.Creating types that compose other types will be one opportunity Subclassers™\ncan use to create types that give the behavior they’re looking for. Packaging\ntheir final class into another type that executes the final class’s behavior\nand then returns its own behavior based on the results of that.This will lead us towards a clearer business logic in types, that are more\nflexible and have less responsibilities. Gone will be the\ngod/Grob Gob Glob Grod\nobjects that have subclasses on subclasses just to get the behaviors they want.\nA series of classes that compose together can more clearly define intention and\nresponsibility.Alternatives ConsideredI would have loved to seen this implemented as an opt-in compiler-time flag,\nrather than a syntactical level keyword. As a language feature, some may want\nit, and benefit from it, while others may shy away or not understand it’s\nconsequences. By having the compiler determine at compile time, with a flag such\nas Disable subclassing on public classes, we could still write the code we\nwant, while being flexible enough to generate code and interfaces that we need.While I may not be a ?? on the semantic implementation, I’m ?x? on the value\nthat final by default would bring.",
  "title": "SE-0117, API Design, and You"
}