Nous y voilà ! 36e jour de formation et c’était aujourd’hui le 13e jour des 100DaysofSwiftUI.

Je suis content d’avoir eu l’intuition d’attendre la fin de la première partie des 100 jours SwiftUI avant de me lancer dans mes projets Xcode. Il y a vraiment des concepts super intéressants à voir et à connaître, comme les protocoles qu’on a vus aujourd’hui !

Si tu envisages de faire des petits projets en plus de ceux proposés par la formation, mieux vaut attendre la fin de la première quinzaine. Après ces 15 premiers jours de Swift, tu auras de bonnes bases pour commencer à apprendre à faire des interfaces.

# Apprentissages du jour : protocoles, extensions et plus

## Les protocoles : des contrats pour structurer le code

Les protocoles sont des contrats qui permettent de créer des prototypes pour les structs, classes et enums. Ce ne sont pas des éléments obligatoires, mais ils sont largement utilisés dans SwiftUI.

### Qu’est-ce qu’un protocole ?

Un protocole définit des méthodes et propriétés minimales que doit contenir un type. C’est comme dire : “Si tu veux être un véhicule, tu dois au minimum avoir ces caractéristiques.”

protocol Vehicle {
    var name: String { get }
    var currentPassanger: Int { get set }
    
    func estimate(for distance: Int) -> Int
    func travel(distance: Int)
}

### Propriétés dans les protocoles

Pour les propriétés, on définit le type et les getters/setters :

• get seul = propriété en lecture seule (constante)
• get set = propriété modifiable (variable)

Important : On ne peut pas définir uniquement un setter sans getter !

### Protocoles multiples

Un type peut se conformer à plusieurs protocoles simultanément :

struct Car: Vehicle, CanBeElectric {
    // Implémentation des deux protocoles
}

### Pourquoi utiliser les protocoles ?

L’avantage principal : au lieu de créer plusieurs fonctions pour différents types ayant des comportements similaires, on peut passer le protocole comme paramètre. Swift comprend alors qu’on attend “ce type de comportement” plutôt qu’un struct spécifique.

## Types de retour opaques (Opaque Return Types)

Les types de retour opaques sont des concepts complexes mais essentiels. Paul Hudson les a survolés car on les voit immédiatement en ouvrant un nouveau projet Xcode.

### Le mot-clé “some”

Dans SwiftUI, tu verras souvent some View. C’est un type opaque qui cache certaines informations pour rendre le code plus lisible.

Pourquoi cacher ? Au lieu de définir précisément tous les types possibles d’une vue (bouton, texte, image centrée avec bordure, etc.), on dit simplement qu’on attend “quelque chose qui est une vue”.

Le langage Swift utilise le mot some suivi du protocole attendu. Par exemple :

• some View pour les interfaces
• some Equatable pour les éléments comparables

## Extensions : étendre les fonctionnalités

Les extensions permettent d’ajouter des fonctionnalités aux protocoles, classes et types existants.

### Étendre les types Swift existants

extension String {
    func trimmed() -> String {
        self.trimmingCharacters(in: .whitespacesAndNewlines)
    }
    
    var isNotEmpty: Bool {
        !isEmpty
    }
}

### Avantages des extensions

• Code completion intégré automatiquement
• Organisation du code plus lisible
• Gestion d’accès interne simplifiée

### Limitations importantes

Dans les extensions, on ne peut créer que des propriétés calculées (computed properties), pas de propriétés stockées. C’est pour éviter les impacts sur les performances.

### Astuce pour les initialiseurs

Si tu veux garder l’initialiseur automatique d’un struct ET en créer un personnalisé, place le personnalisé dans une extension :

extension Book {
    init(title: String, pageCount: Int) {
        self.title = title
        self.pageCount = pageCount
        self.readingHours = pageCount / 50
    }
}

## Programmation Orientée Protocole (POP)

Les extensions de protocoles constituent ce qu’on appelle la Protocol Oriented Programming.

### Exemple concret

extension Collection {
    var isNotEmpty: Bool {
        !isEmpty
    }
}

Cette extension ajoute la propriété isNotEmpty à tous les types qui héritent du protocole Collection (Array, Set, Dictionary).

### Protocoles avancés : Self

On peut utiliser Self (avec majuscule) pour indiquer que le type d’entrée est le même que celui de sortie :

extension Numeric {
    func squared() -> Self {
        self * self
    }
}

Swift est assez intelligent pour comprendre que si on applique cette méthode à un Int, elle retourne un Int, et si c’est un Double, elle retourne un Double.

## Protocoles Equatable et Comparable

### Equatable

Permet de comparer deux instances avec == et !=

### Comparable

Permet d’utiliser <, >, <=, >=. Bonus : si un type adopte Comparable, il hérite automatiquement d’Equatable !

struct User: Comparable {
    let name: String
    
    static func <(lhs: User, rhs: User) -> Bool {
        lhs.name < rhs.name
    }
}

# Exercices pratiques

J’ai travaillé sur le checkpoint 8 qui demandait de créer un protocole Building avec des propriétés et méthodes spécifiques, puis d’implémenter House et Office.

Ensuite, j’ai créé des exercices supplémentaires avec Claude pour approfondir les concepts vus aujourd’hui. C’était plus complexe que prévu, j’en ai fait deux au lieu de cinq, mais cela m’a permis d’intégrer les protocoles, extensions et structures de manière plus solide.

# Réflexions sur le parcours

C’est en forgeant qu’on devient forgeron ! Aujourd’hui était vraiment plus intense et spécifique à Swift. On découvre des concepts qui n’existent pas dans d’autres langages, ce qui rend l’apprentissage passionnant mais exigeant.

## Expérience avec Claude pour le développement

J’ai continué à travailler sur mon projet de refactoring avec mes anciens collègues. Une chose que j’ai remarquée : Claude est puissant quand on sait ce qu’on fait. Pour faire du “vibe coding” efficace, il faut quand même savoir ce qu’on veut faire.

Tu ne peux pas courir un marathon si tu n’as jamais couru, et c’est pareil avec le code assisté par IA. Je pense que ce concept s’adapte aussi au développement : c’est très fort, mais il faut des bases solides.

## Planification des projets portfolio

J’étais censé commencer le codage aujourd’hui, mais je n’ai pas encore terminé la partie théorique. J’ai donc créé la structure du troisième projet portfolio (une application météo) pour continuer d’avancer.

Une réflexion me traverse : ne devrais-je pas commencer par l’application de quiz plutôt que celle de cartes de fidélité ? Elle semble beaucoup plus simple avec moins d’écrans à gérer.

J’espère pouvoir commencer à coder la semaine prochaine, une fois que j’aurai consolidé ces fondamentaux Swift qui s’avèrent être vraiment cruciaux pour la suite !

À demain pour de nouveaux apprentissages !