Builder Pattern
Construcao fluente de objetos complexos com validacao
O Builder Pattern separa a construção de um objeto complexo da sua representação. Em Swift, é ideal quando um objeto tem muitos parâmetros opcionais e precisa de validação no momento da criação.
Por que Builder Pattern?
| Problema | Solução com Builder |
|---|---|
Muitos parâmetros opcionais no init | Métodos encadeáveis — chame apenas o que precisa |
| Validação espalhada pelo código | Validação centralizada no build() |
| Objeto precisa ser imutável após criação | Builder é mutável, resultado é let |
| Configuração complexa com dependências entre params | Builder pode validar combinações no build() |
| API pouco legível com muitos argumentos | Fluent interface com nomes descritivos |
Anatomia do Builder em Swift
| Componente | Papel | Exemplo |
|---|---|---|
| Product | Objeto imutável final | IdentityKitConfiguration |
| Builder | Classe mutável com setters | IdentityKitConfiguration.Builder |
| @discardableResult | Permite encadear sem warning | @discardableResult func setAPIKey(...) -> Self |
| build() | Valida e cria o produto | func build() throws -> Configuration |
Por que o Builder é
class e não struct? O Builder precisa ser
class para que self retornado nos setters seja a mesma instância (reference type). Com struct (value type), cada setter retornaria uma cópia, e o encadeamento não funcionaria corretamente sem mutating + variável var. Class permite Builder().setA().setB().build() naturalmente.