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 regular topic to talk about. It is OOP, 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

Object-oriented programming or OOP is so familiar with you guys. Before Swift, there are a bunch of programming languages which follow up 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. Some are good till now, A few are not good as expected. So I’d like to look at things which have issues


Encapsulation is a very very basic thing which you definitely use whenever define properties/methods of a class.

In swift, open, public, internal, fileprivate, private are common access control keywords. Each keyword defines an access scope to class, property, method, so on.

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 is a huge missing, it limits encapsulation in Swift.
With this missing, I believe that Access control in Swift is not restricted enough.


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 strictly set scope limit on a prop/func for accessing from inheritor but not from outside of class


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 func or prop will make design job become more difficult. Architect guys will lose a powerful tool to enforce developers to conforms their design.

I’ve seen my co-workers and other senior guys reluctantly treat a class is an abstract class on logic, but there’s no way to enforce on physic. That means other guys are able to violate the design somehow intentionally or accidentally.

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 haven’t found anyway.

This missing haven’t been being resolved since Objective-C.


As same as OOP programming languages, Swift implements the same polymorphism. Therefore I have almost nothing to talk about.


Actually Swift has some limits, but this is not the reason to not use it. Most people must use it for making living, some people try to learn. Therefore, knowing the cons will help you use it more efficiently, and if possible contribute or propose the improvement for the next version of Swift

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