Book Image

Swift 3 Object-Oriented Programming - Second Edition

By : Gaston C. Hillar
Book Image

Swift 3 Object-Oriented Programming - Second Edition

By: Gaston C. Hillar

Overview of this book

Swift has quickly become one of the most-liked languages and developers’ de-facto choice when building applications that target iOS and macOS. In the new version, the Swift team wants to take its adoption to the next level by making it available for new platforms and audiences. This book introduces the object-oriented paradigm and its implementation in the Swift 3 programming language to help you understand how real-world objects can become part of fundamental reusable elements in the code. This book is developed with XCode 8.x and covers all the enhancements included in Swift 3.0. In addition, we teach you to run most of the examples with the Swift REPL available on macOS and Linux, and with a Web-based Swift sandbox developed by IBM capable of running on any web browser, including Windows and mobile devices. You will organize data in blueprints that generate instances. You’ll work with examples so you understand how to encapsulate and hide data by working with properties and access control. Then, you’ll get to grips with complex scenarios where you use instances that belong to more than one blueprint. You’ll discover the power of contract programming and parametric polymorphism. You’ll combine generic code with inheritance and multiple inheritance. Later, you’ll see how to combine functional programming with object-oriented programming and find out how to refactor your existing code for easy maintenance.
Table of Contents (17 chapters)
Swift 3 ObjectOriented Programming - Second Edition
Credits
About the Author
Acknowledgement
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

Organizing classes with UML diagrams


So far, our object-oriented solution includes six classes with their properties and methods. However, if we take another look at these six classes, we will notice that all of them have the same two methods: calculatedArea and calculatedPerimeter. The code for the methods in each class is different because each shape uses a special formula to calculate either the area or the perimeter. However, the declarations, contracts, or protocols for the methods are the same. Both methods have the same name, are always parameterless, and return a floating point value. Thus, all of them return the same type.

When we talked about the six classes, we said we were talking about six different geometrical shapes or simply shapes. Thus, we can generalize the required behavior or protocol for the six shapes. These shapes must define the calculatedArea and calculatedPerimeter methods with the previously explained declarations. We can create a protocol to make sure that the six classes provide the required behavior.

The protocol is a special class named Shape, and it generalizes the requirements for the geometrical shapes in our application. In this case, we will work with a special class, but in the future, we will use protocols for the same goal. The Shape class declares two parameterless methods that return a floating point value: calculatedArea and calculatedPerimeter. Then, we will declare the six classes as subclasses of the Shape class, which will inherit these definitions, and provide the specific code for each of these methods.

The subclasses of Shape (Square, EquilateralTriangle, Rectangle, Circle, Ellipse, and RegularHexagon) implement the methods because they provide code while maintaining the same method declarations specified in the Shape superclass. Abstraction and hierarchy are two major pillars of object-oriented programming.

Object-oriented programming allows us to discover whether an object is an instance of a specific superclass. After we change the organization of the six classes and after they become subclasses of Shape, any instance of Square, EquilateralTriangle, Rectangle, Circle, Ellipse, or RegularHexagon is also a Shape class. In fact, it isn't difficult to explain the abstraction because we speak the truth about the object-oriented model when we say that it represents the real world. It makes sense to say that a regular hexagon is indeed a shape and therefore an instance of RegularHexagon is a Shape class. An instance of RegularHexagon is both a Shape (the superclass of RegularHexagon) class and a RegularHexagon (the class that we used to create the object) class.

The following figure shows an updated version of the UML diagram with the superclass or base class (Shape), its six subclasses, and their attributes and methods. Note that the diagram uses a line that ends in an arrow that connects each subclass to its superclass. You can read the line that ends in an arrow as the following: the class where the line begins is a subclass of the class that has the line ending with an arrow. For example, Square is a subclass of Shape and EquilateralTriangle is a subclass of Shape:

Note

A single class can be the superclass of many subclasses.

Now, it is time to have a meeting with a domain expert, that is, someone who has an excellent knowledge of geometry. We can use the UML diagram to explain the object-oriented design for the solution. After we explain the different classes that we will use to abstract behavior, the domain expert explains to us that many of the shapes have something in common and that we can generalize behavior even further. The following three shapes are regular polygons:

  • An equilateral triangle (the EquilateralTriangle class)

  • A square (the Square class)

  • A regular hexagon (the RegularHexagon class)

Regular polygons are polygons that are both equiangular and equilateral. All the sides that compose a regular polygon have the same length and are placed around a common center. This way, all the angles between any two sides are equal. An equilateral triangle is a regular polygon with three sides, the square has four sides, and the regular hexagon has six sides. The following picture shows the three regular polygons and the generalized formulae that we can use to calculate their areas and perimeters. The generalized formula to calculate the area requires us to calculate a cotangent, which is abbreviated as cot:

As the three shapes use the same formula with just a different value for the number of sides (n) parameter, we can generalize the required protocol for the three regular polygons. The protocol is a special class named RegularPolygon that defines a new numberOfSides property that specifies the number of sides with an integer value. The RegularPolygon class is a subclass of the previously defined Shape class. It makes sense because a regular polygon is indeed a shape. The three classes that represent regular polygons become subclasses of RegularPolygon. However, both the calculateArea and calculatedPerimeter methods are coded in the RegularPolygon class using the generalized formulae. The subclasses just specify the right value for the inherited numberOfSides property, as follows:

  • EquilateralTriangle: 3

  • Square: 4

  • RegularHexagon: 6

The RegularPolygon class also defines the lengthOfSide property that was previously defined in the three classes that represent regular polygons. Now, the three classes become subclasses of RegularPolygon and inherit the lengthOfSide property. The following figure shows an updated version of the UML diagram with the new RegularPolygon class and the changes in the three classes that represent regular polygons. The three classes that represent regular polygons do not declare either the calculatedArea or calculatedPerimeter methods because these classes inherit them from the RegularPolygon superclass and don't need to make changes to these methods that apply a general formula:

Our domain expert also explains to us a specific issue with ellipses. There are many formulae that provide approximations of the perimeter value for this shape. Thus, it makes sense to add additional methods that calculate the perimeter using other formulae. He suggests us to make it possible to calculate the perimeters with the following formulae:

  • The second version of the formula developed by Srinivasa Aiyangar Ramanujan

  • The formula proposed by David W. Cantrell

We will define the following two additional parameterless methods to the Ellipse class. The new methods will return a floating point value and solve the specific problem of the ellipse shape:

  • CalculatedPerimeterWithRamanujanII

  • CalculatedPerimeterWithCantrell

This way, the Ellipse class will implement the methods specified in the Shape superclass and also add two specific methods that aren't included in any of the other subclasses of Shape. The following figure shows an updated version of the UML diagram with the new methods for the Ellipse class: