Swiftのコードを読んでいると、クラスの前にfinalというキーワードが付いているのを見かけることがあります。このfinal、実は重要な役割を持っています。今回は、finalキーワードの意味と使い方を、実例を交えながらわかりやすく解説します。
finalキーワードとは？
finalは一言で言うと、「これ以上拡張できません」という宣言です。
クラスにfinalを付けると、そのクラスを継承することができなくなります。メソッドに付けると、そのメソッドをオーバーライド（上書き）できなくなります。
// このクラスは継承できない
final class Calculator {
func add(_ a: Int, _ b: Int) -> Int {
return a + b
}
}
// ❌ コンパイルエラー！
// 'Calculator' is 'final' and cannot be inherited from
class ScientificCalculator: Calculator {
// 継承しようとするとエラーになる
}
finalが使える場所
1. クラス全体に付ける
クラス全体を継承不可にする、最も一般的な使い方です。
final class NetworkManager {
func fetchData() {
// ネットワーク処理
}
}
2. 個別のメソッドに付ける
クラス自体は継承可能だけど、特定のメソッドだけオーバーライドを禁止したい場合に使います。
class Animal {
var name: String
init(name: String) {
self.name = name
}
// このメソッドは変更してほしくない
final func breathe() {
print("呼吸しています")
}
// このメソッドはオーバーライド可能
func makeSound() {
print("...")
}
}
class Dog: Animal {
// ✅ これはOK
override func makeSound() {
print("ワンワン！")
}
// ❌ エラー！finalメソッドはオーバーライドできない
override func breathe() {
print("犬の呼吸")
}
}
3. プロパティに付ける
計算プロパティのオーバーライドも防げます。
class Shape {
final var description: String {
return "図形"
}
var area: Double {
return 0.0
}
}
class Circle: Shape {
var radius: Double = 1.0
// ✅ これはOK
override var area: Double {
return Double.pi * radius * radius
}
// ❌ エラー！
override var description: String {
return "円"
}
}
なぜfinalを使うのか？5つの理由
1. パフォーマンスの向上
これは最も技術的な理由です。finalを付けると、Swiftコンパイラはより効率的なコードを生成できます。
継承可能なクラスの場合、メソッド呼び出しは「動的ディスパッチ」という仕組みで処理されます。これは実行時にどのメソッドを呼ぶか判断する必要があるため、わずかにオーバーヘッドがあります。
finalを付けると「静的ディスパッチ」になり、コンパイル時に呼び出し先が確定するため、より高速になります。
// 動的ディスパッチ（継承可能）
class SlowCalculator {
func calculate() -> Int {
return 42
}
}
// 静的ディスパッチ（高速）
final class FastCalculator {
func calculate() -> Int {
return 42
}
}
実際の速度差は小さいですが、頻繁に呼ばれる処理では効果があります。
2. 設計の意図を明確にする
「このクラスは完成品で、継承して拡張する必要はありません」というメッセージを他の開発者（未来の自分を含む）に伝えられます。
// このクラスは単独で完結した機能を提供
final class ImageCache {
private var cache: [String: UIImage] = [:]
func store(_ image: UIImage, forKey key: String) {
cache[key] = image
}
func retrieve(forKey key: String) -> UIImage? {
return cache[key]
}
}
3. 予期しない挙動を防ぐ
重要なロジックを持つクラスが意図しない形で継承されると、バグの原因になることがあります。
// 認証ロジックは継承されるべきではない
final class AuthenticationManager {
private let apiKey: String
init(apiKey: String) {
self.apiKey = apiKey
}
func authenticate(username: String, password: String) -> Bool {
// 重要なセキュリティロジック
return true
}
}
4. 不変性の保証
値を表現するクラスは、継承によって挙動が変わってしまうと困ります。
// 座標を表すクラス（継承不要）
final class Coordinate {
let latitude: Double
let longitude: Double
init(latitude: Double, longitude: Double) {
self.latitude = latitude
self.longitude = longitude
}
func distanceTo(_ other: Coordinate) -> Double {
// 距離計算
return 0.0
}
}
5. コードの可読性向上
finalがあることで、「このクラスのコードを読めば全てがわかる」と確信できます。継承先を探し回る必要がありません。
実際の使用例：よくあるパターン
シングルトンクラス
シングルトンパターンでは、継承されると複数のインスタンスが作られる可能性があるため、finalを付けるのが定石です。
final class AppSettings {
static let shared = AppSettings()
private init() {
// 外部からインスタンス化できない
}
var isDarkMode: Bool = false
var fontSize: CGFloat = 16.0
}
// 使い方
AppSettings.shared.isDarkMode = true
ユーティリティクラス
静的メソッドだけを持つユーティリティクラスも、継承の必要がありません。
final class StringValidator {
// インスタンス化を防ぐ
private init() {}
static func isValidEmail(_ email: String) -> Bool {
let emailRegex = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}"
let predicate = NSPredicate(format: "SELF MATCHES %@", emailRegex)
return predicate.evaluate(with: email)
}
static func isValidPhoneNumber(_ phone: String) -> Bool {
return phone.count >= 10
}
}
// 使い方
if StringValidator.isValidEmail("test@example.com") {
print("有効なメールアドレス")
}
データモデル
SwiftDataの@Modelでも、多くの場合finalを付けます。
import SwiftData
@Model
final class User {
var id: String
var name: String
var email: String
var createdAt: Date
init(id: String, name: String, email: String) {
self.id = id
self.name = name
self.email = email
self.createdAt = Date()
}
}
ViewModelやPresenter
SwiftUIのViewModelも、継承より委譲（delegation）やプロトコルを使う設計が一般的なので、finalを付けることが多いです。
final class ProfileViewModel: ObservableObject {
@Published var userName: String = ""
@Published var email: String = ""
@Published var isLoading: Bool = false
func loadUserProfile() {
isLoading = true
// プロフィール読み込み処理
isLoading = false
}
func updateProfile() {
// 更新処理
}
}
いつfinalを使うべき？使わないべき？
finalを使うべき場合
✅ 継承を想定していないクラス 多くのクラスは実際には継承する必要がありません。
✅ ユーティリティクラス 静的メソッドだけを提供するクラス
✅ シングルトンクラス アプリ全体で1つのインスタンスだけを持つクラス
✅ 値オブジェクト 座標、色、金額など、値を表現するクラス
✅ ViewModelやController 具体的な画面ロジックを持つクラス
✅ データモデル データベースのエンティティなど
finalを使わない方が良い場合
❌ 明確に継承を想定した基底クラス
// これにfinalは付けない
class BaseViewController: UIViewController {
func setupUI() {
// 共通のUI設定
}
}
❌ ライブラリやフレームワークの公開API 利用者が拡張できるようにする場合
❌ テストでモック化したいクラス テスト時にサブクラスを作る必要がある場合（ただし、プロトコルを使う設計の方が良い）
ベストプラクティス：finalファースト
Swiftコミュニティでは、**「デフォルトでfinalを付け、継承が必要になったら外す」**というアプローチが推奨されています。
これを「finalファースト」と呼びます。
// 最初はfinalで始める
final class ProductService {
func fetchProducts() -> [Product] {
// 実装
return []
}
}
// 後で継承が必要になったらfinalを外す
class ProductService {
func fetchProducts() -> [Product] {
return []
}
}
// そして実際に継承する
class MockProductService: ProductService {
override func fetchProducts() -> [Product] {
// テスト用のモックデータ
return [Product(name: "テスト商品")]
}
}
なぜfinalファースト？
- 早期最適化ではなく、良い設計の結果：継承は本当に必要な時だけ使うべき
- リファクタリングが楽：finalを外すのは簡単、後から付けるのは破壊的変更
- パフォーマンスのボーナス：考えなくても最適化される
まとめ
finalキーワードは、Swiftでクラスベースの設計をする上で重要なツールです。
重要なポイント：
finalは継承・オーバーライドを禁止する- パフォーマンス向上、設計意図の明確化、予期しない挙動の防止に役立つ
- シングルトン、ユーティリティ、ViewModel、データモデルなど、多くの場面で有効
- 「finalファースト」のアプローチがおすすめ
継承は強力な機能ですが、使いすぎると複雑になりがちです。finalを適切に使って、シンプルで保守しやすいコードを書きましょう！
