Skip to main content

Access control trong lập trình iOS

Hôm nay mình sẽ nói về các quyền truy cập trong lập trình iOS, cụ thể là ngôn ngữ Swift. Hiện tại phiên bản mình đang sử dụng là Swift 3.1 trên Xcode 8.3
Đầu tiên để hiểu về các quyền truy cập, mọi người cần phân biệt được các thành phần trong 1 project iOS, đó là module và file
- Module là thành phần riêng biệt trong mỗi project iOS, để liên kết các module với nhau, chúng ta sử dụng từ khoá "import". Example: import UIKit. Để tạo một module mới, bạn chọn New -> Project -> Cocoa Touch Framework
- File thì đơn giản rồi, chắc không cần phải giải thích nữa :))
Hiện tại, Swift cung cấp cho lập trình viên 5 quyền truy cập khác nhau theo thứ tự từ cao đến thấp về mức độ truy cập như sau:
  • Open
  • Public
  • Internal
  • Fileprivate
  • Private
* Với open và public thì đơn giản bạn có thể truy cập từ mọi nơi, kể cả khác module. Chỉ cần bạn khai báo module mình sử dụng là có thể gọi các class, các function tương ứng. Tuy nhiên để phân biệt được open và public, có thể mọi người không để ý. Đó là với các class bạn để là open thì khi sử dụng ở module khác, bạn có thể kế thừa lại các class đó. Trong khi nếu bạn sử dụng public class, bạn chỉ có thể sử dụng trực tiếp nó mà không thể kế thừa để tái sử dụng. Đó là điểm khác biệt của 2 quyền truy cập này.
Ví dụ: Ở đây mình có 2 module: module 1 chứa 2 class là OpenClass và PublicClass
Ở module 2, mình import Module1, sau đó tạo class Test kế thừa từ 2 class của module1. Kết quả như sau:

* Khi khai báo class, function mà bạn không khai báo quyền truy cập, thì mặc định nó là internal. Tức là bạn chỉ được sử dụng các internal class, internal function trong chính module của nó mà không được sử dụng ở các module khác.
* Cuối cùng là fileprivate và private, cả 2 quyền truy cập này đều hạn chế khả năng truy cập đến các thành phần trong một module. Tức là khi bạn khai báo một function là private hoặc fileprivate, bạn chỉ có thể sử dụng nó trong chính file đó mà thôi. Còn điểm khác biệt giữa fileprivate và private chính là với fileprivate, bạn hoàn toàn có thể kế thừa lại lại các class, function. Tuy nhiên các class con cũng phải ở cùng 1 file với class cha. Còn đối với private thì bạn hoàn toàn không thể làm được như vậy.
Ví dụ ở đây mình có 1 class Test1 chứa 2 function: 1 là fileprivate và 1 là private
Mình tiếp tục tạo 1 class Test 2 trong cùng 1 file swift, sau đó override lại các function trên, kết quả là chỉ function khai báo là fireprivate có thể override lại được.
Như vậy trên đây mình đã giải thích về các quyền truy cập trong Swift. Hy vọng sẽ giúp các bạn giải đáp được thắc mắc.

Comments

Post a Comment

Popular posts from this blog

Alamofire vs URLSession

Alamofire vs URLSession: a comparison for networking in Swift Alamofire and URLSession both help you to make network requests in Swift. The URLSession API is part of the foundation framework, whereas Alamofire needs to be added as an external dependency. Many  developers  doubt  whether it’s needed to include an extra dependency on something basic like networking in Swift. In the end, it’s perfectly doable to implement a networking layer with the great URLSession API’s which are available nowadays. This blog post is here to compare both frameworks and to find out when to add Alamofire as an external dependency. Build better iOS apps faster Looking for a great mobile CI/CD solution that has tons of iOS-specific tools, smooth code signing, and even real device testing? Learn more about Bitrise’s iOS specific solutions! This shows the real power of Alamofire as the framework makes a lot of things easier. What is Alamofire? Where URLSession...
Post a Comment
Read more

Swift Tool Belt, Part 1: Adding a Border, Corner Radius, and Shadow to a UIView with Interface Builder

During my iOS work, I’ve assembled a set of code that I bring with me on every iOS project. I’m not talking about large frameworks or CocoaPods here. These are smaller Swift extensions or control overrides that are applicable to many projects. I think of them as my tool belt. In this post, I’ll show you an extension that will add a border, a corner radius, and a shadow to any UIView, UIButton, or UILabel and allow you to preview what it will look like in Interface Builder. Back in 2014, I wrote a blog post on Expanding User-Defined Runtime Attributes in Xcode where I added a border, corner radius, and shadow to a UIView using Interface Builder’s user-defined runtime attributes. This solution had no type checking—you had to type the property you wanted to modify by hand and often had to look up what it was called. You also had to run your project in order to see the effect of the runtime attribute. Starting with Xcode 6 , there is a new mech...
Post a Comment
Read more

Frame vs Bounds in iOS

This article is a repost of an answer I wrote on Stack Overflow . Short description frame = a view’s location and size using the parent view’s coordinate system ( important for placing the view in the parent) bounds = a view’s location and size using its own coordinate system (important for placing the view’s content or subviews within itself) Details To help me remember frame , I think of a picture frame on a wall . The picture frame is like the border of a view. I can hang the picture anywhere I want on the wall. In the same way, I can put a view anywhere I want inside a parent view (also called a superview). The parent view is like the wall. The origin of the coordinate system in iOS is the top left. We can put our view at the origin of the superview by setting the view frame’s x-y coordinates to (0, 0), which is like hanging our picture in the very top left corner of the wall. To move it right, increase x, to move it down increase y. To help me remember bound...
Post a Comment
Read more