OOP in Swift

(This article is based on Swift 4.x, the content of it could be obsoleted against the later version).

Hi everyone,

This is my very second post, so I pick out a very general topic to talk about. It is OOP (Object Oriented Programming), the stuff which involves me almost every day. I’m telling you from my experience in Swift. If you feel it is true for your case, I’m happy about that. If you like to contribute or correct things, then it is ok to do.

Ok, Let’s get started

OOP or Object-oriented programming is very familiar to us. Before Swift, there are a bunch of programming languages which conform OOP like C++, JAVA, C#, etc…
And also Swift is such an OOP programming language like that, it’s robust, beautiful syntax, faster, better performance but…
In summary, Swift does not fulfill OOP completely. There are some differences and limits We may know.

As you known, The main characteristics of OOP are encapsulation, inheritance, polymorphism, abstraction. In Swift, some are good, some are not as good as expected. Ok, let’s look over them.


Encapsulation is a pretty basic thing which you definitely involve when defining a property or method of a class.

open, public, internal, fileprivate, private are common access in Swift. Each keyword defines a relevant access scope.

According to Apple:

  • Open access and public access enable entities to be used within any source file from their defining module, and also in a source file from another module that imports the defining module. You typically use open or public access when specifying the public interface to a framework. The difference between open and public access is described below.

  • Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an app’s or a framework’s internal structure.

  • File-private access restricts the use of an entity to its own defining source file. Use file-private access to hide the implementation details of a specific piece of functionality when those details are used within an entire file.

  • Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file. Use private access to hide the implementation details of a specific piece of functionality when those details are used only within a single declaration.

fileprivate access is a plus in Swift, it offers full access to everything in one physical file. This is quite flexible when having several definitions ( classes, extensions,…) declared in the same file.
I feel happy on this. Not pretty sure if other OOP programming languages do the same thing till now.

But if There’s something Swift cannot do, that is it cannot apply an access scope between base-class and sub-class only.
Objective-C and other OOP programming can do, but Swift can’t. This huge missing narrows the encapsulation principle in Swift.


You define something (properties, methods) on a base class, and then literally inherit in sub-classes. Overall, So far so good, There’s almost no nothing to complain about. It’s similar and does as well as other OOP programming languages.

There is only limit which I brought up in encapsulation.  You can’t apply an access scope between the base class and the subclass.


In Swift, there’s no such thing as Abstract class as well as abstract method.
An abstract class is able to include abstract methods, and an abstract method forces subclasses to override the method.

For most iOS developers I’ve known so far, they feel kinda ok for coding without abstract class. But from my point of view, missing abstract class, abstract method and prop will make design job become less effective . Architect guys lose a helpful tool to enforce developers to follow the design.

I’ve seen my co-workers and other senior guys reluctantly treat a class is an abstract class logically, but there’s no way to enforce physically. That means any guys can violate the design somehow.

And I’ve seen some guys enforce an abstract func as below

class BaseClass {

func abstractMethod() {
crashTheApp(message: "The subclasses must override this abstractMethod")

func crashTheApp(message: String) {

Such a tricky way! so how about if the subclass overrides the abstract method and inside of it and still need to call the super method to reuse something. I don’t see anyway.

This missing has been seen in Objective-C as well


As same as OOP programming languages, Swift implements the same polymorphism principle.


Although lacking some things, Swift still has its own advantages and specialties. I hope this share can be helpful. If you have any thoughts, please share.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s