Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Stylishly Swift

DZone's Guide to

Stylishly Swift

Want to keep in touch with the evolution of the Swift language? Here are some links to help.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

Good talk and links here to keep you abreast of evolving Swift paradigms:

Swifty? Emerging patterns and idioms

Last Tuesday I gave a talk at Swift London called Swifty? looking at interesting patterns emerging from the community, as well as how Swift 3 will shape idiomatic code. You can see my slides on Speaker Deck.

The talk covered several topics, so I thought I’d link to some examples for those who want to learn more.

This is an even better post on namespacing:

Dear Erica: No-case Enums?

Dear Erica, Why would you create an enum with no cases?

This is such a great question! No-case enumerations represent a fairly obscure Swift “power tool”, and one that most developers are unaware of.

The answer, in a nutshell, is that they enable programmers to establish a mini-namespace with little overhead and an assurance that you can’t accidentally create type instances. Under their umbrella, you can group static members into namespaces, build singletons, create cohesive collections of functionality with a minimum surface eliminating freestanding functions, and in one outlier case provide services built around generic types…

And this is an interesting pattern for applying private type extensions which suits well our predisposition towards exposing only designated functionality, a position which is subject to some full and frank discourse over where they’re considering it as not just a style choice but an enforced language construct, if you’ve picked up on that brouhaha; if not, we’ll put an addendum here if/when something actionable happens. In the meantime, check out

Concealment design pattern in Swift

This article introduces a design pattern that I call Concealment, and demonstrates how to use the pattern in Swift code.

Purpose

The Concealment pattern enables types to support novel, related functionality without adding nonessential members to their interface.

Motivation

User-defined types can easily be overused in a codebase, giving more prominence to things than necessary. A common example is having a data model entity be involved with tangentially related concerns; such as validation checks, business rule processing, and display formatting. It is preferable to conceal the augmentation and usage of your types behind an API expressly built for a single responsibility, rather than expose those implementation details to all the types’ consumers…

Yep, we agree there; anything that reduces cognitive load is a Good Thing!

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
swift

Published at DZone with permission of Alex Curylo, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}