Padrão arquitetural “Visitor” nos universos “iOS” e “Swift”

“Visitor” é um dos padrões de comportamento descritos no livro “Gang of Four”, “GoF”, “Design Patterns: Elements of Reutilizável Software Orientado a Objetos ”) .

Em resumo, o modelo pode ser útil quando você precisar executar qualquer ação do mesmo tipo em um grupo de objetos de tipos diferentes não conectados entre si. Ou, em outras palavras, expandir a funcionalidade dessa série de tipos com uma determinada operação do mesmo tipo ou com uma única fonte. Ao mesmo tempo, a estrutura e a implementação de tipos extensíveis não devem ser afetadas.

A maneira mais fácil de explicar a ideia é com um exemplo.

Gostaria imediatamente de fazer uma reserva de que o exemplo é fictício e composto para fins acadêmicos. I.e. este material pretende introduzir a recepção do POO, e não discutir problemas altamente especializados.

Também gostaria de chamar a atenção para o fato de o código nos exemplos ter sido escrito para estudar a técnica de design. Estou ciente de suas deficiências (de código) e das possibilidades de aprimorá-lo para uso em projetos reais.

Exemplo

Suponha que você tenha um subtipo de UITableViewController que use vários subtipos de UITableViewCell :

 class FirstCell: UITableViewCell { /**/ } class SecondCell: UITableViewCell { /**/ } class ThirdCell: UITableViewCell { /**/ } class TableVC: UITableViewController { override func viewDidLoad() { super.viewDidLoad() tableView.register(FirstCell.self, forCellReuseIdentifier: "FirstCell") tableView.register(SecondCell.self, forCellReuseIdentifier: "SecondCell") tableView.register(ThirdCell.self, forCellReuseIdentifier: "ThirdCell") } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { /**/ return FirstCell() /**/ return SecondCell() /**/ return ThirdCell() } } 

Suponha que células de diferentes subtipos tenham diferentes alturas.

Obviamente, o cálculo da altura pode ser colocado diretamente na implementação de cada tipo de célula. Mas e se a altura da célula depender não apenas de seu próprio tipo, mas também de quaisquer condições externas? Por exemplo, um tipo de célula pode ser usado em diferentes tabelas com diferentes alturas. Nesse caso, absolutamente não queremos que as subclasses UITableViewCell estejam cientes das necessidades de sua "superview" ou "view controller".

Em seguida, o cálculo da altura pode ser executado nos métodos UITableViewController : inicialize o UITableViewCell com o valor da altura ou UITableViewCell instância UITableViewCell em um subtipo específico e retorne valores diferentes no método tableView(_:heightForRowAt:) . Mas essa abordagem também pode se tornar inflexível e se transformar em uma longa sequência de operadores "if" ou em uma construção volumosa de "switch".

Resolvendo o problema usando o modelo "Visitante"

Obviamente, não apenas o modelo "Visitante" é capaz de resolver esse problema, mas ele é capaz de fazê-lo com bastante elegância.

Para fazer isso, em primeiro lugar, criaremos um tipo que será, de fato, um "visitante" dos tipos de células e um objeto cuja responsabilidade é apenas calcular a altura da célula da tabela:

 struct HeightResultVisitor { func visit(_ ell: FirstCell) -> CGFloat { return 10.0 } func visit(_ ell: SecondCell) -> CGFloat { return 20.0 } func visit(_ ell: ThirdCell) -> CGFloat { return 30.0 } } 

O tipo está ciente de cada subtipo usado e retorna o valor desejado para cada um.

Em segundo lugar, cada subtipo de UITableViewCell deve poder "receber" este "visitante". Para fazer isso, declararemos um protocolo com esse método de "recebimento", que será implementado por todos os tipos de células usados:

 protocol HeightResultVisitable { func accept(_ visitor: HeightResultVisitor) -> CGFloat } extension FirstCell: HeightResultVisitable { func accept(_ visitor: HeightResultVisitor) -> CGFloat { return visitor.visit(self) } } extension SecondCell: HeightResultVisitable { func accept(_ visitor: HeightResultVisitor) -> CGFloat { return visitor.visit(self) } } extension ThirdCell: HeightResultVisitable { func accept(_ visitor: HeightResultVisitor) -> CGFloat { return visitor.visit(self) } } 

Dentro da subclasse UITableViewController , a funcionalidade pode ser usada da seguinte maneira:

 override func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { let cell = tableView.cellForRow(at: indexPath) as! HeightResultVisitable return cell.accept(HeightResultVisitor()) } 

Poderia ser melhor!

Provavelmente, não queremos que esse código esteja rigidamente anexado a uma funcionalidade específica. Talvez desejemos poder adicionar novas funcionalidades ao nosso conjunto de células, mas não apenas em relação à sua altura, mas, digamos, a cor do plano de fundo, o texto dentro da célula, etc., e não estar vinculado ao tipo do valor de retorno. Os protocolos com o tipo associatedtype ( "Protocolo com tipo associado", "PAT" ) ajudarão aqui:

 protocol CellVisitor { associatedtype T func visit(_ cell: FirstCell) -> T func visit(_ cell: SecondCell) -> T func visit(_ cell: ThirdCell) -> T } 

Sua implementação para retornar a altura da célula:

 struct HeightResultCellVisitor: CellVisitor { func visit(_ cell: FirstCell) -> CGFloat { return 10.0 } func visit(_ cell: SecondCell) -> CGFloat { return 20.0 } func visit(_ cell: ThirdCell) -> CGFloat { return 30.0 } } 

No lado “host”, basta ter apenas um protocolo comum e sua única implementação - para qualquer “visitante” desse tipo. Somente as partes "visitantes" estarão cientes dos diferentes tipos de valores de retorno.

O protocolo para o "visitante receptor" (no livro "GoF" deste lado é chamado "Elemento") do tipo terá a seguinte forma:

 protocol Visitableell where Self: UITableViewCell { func accept<V: CellVisitor>(_ visitor: V) -> VT } 

(Pode não haver restrições para o tipo de implementação. Mas neste exemplo, não faz sentido implementar esse protocolo pelas subclasses de UITableViewCell .)

E sua implementação nos subtipos de UITableViewCell :

 extension FirstCell: Visitableell { func accept<V: CellVisitor>(_ visitor: V) -> VT { return visitor.visit(self) } } extension SecondCell: Visitableell { func accept<V: CellVisitor>(_ visitor: V) -> VT { return visitor.visit(self) } } extension ThirdCell: Visitableell { func accept<V: CellVisitor>(_ visitor: V) -> VT { return visitor.visit(self) } } 

E, finalmente, use:

 override func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { let cell = tableView.cellForRow(at: indexPath) as! Visitableell return cell.accept(HeightResultCellVisitor()) } 

Assim, poderemos criar, usando diferentes implementações do “visitante”, em geral, quase tudo, e nada será necessário do “lado receptor” para suportar a nova funcionalidade. Essa festa nem mesmo saberá o que exatamente o "convidado" concedeu.

Outro exemplo

Vamos tentar alterar a cor de fundo da célula usando um "visitante" semelhante:

 struct ColorResultCellVisitor: CellVisitor { func visit(_ cell: FirstCell) -> UIColor { return .black } func visit(_ cell: SecondCell) -> UIColor { return .white } func visit(_ cell: ThirdCell) -> UIColor { return .red } } 

Um exemplo de uso deste visitante:

 override func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) { cell.contentView.backgroundColor = (cell as! Visitableell).accept(ColorResultCellVisitor()) } 

Algo neste código deve ser confuso ... No início, foi dito que o "visitante" é capaz de adicionar funcionalidade à classe de fora. Portanto, é possível "ocultar" nele toda a funcionalidade de alterar a cor de fundo da célula, e não apenas obter o valor dela? Você pode. Em seguida, o tipo associatedtype assumirá o valor Void (aka () - uma tupla vazia) :

 struct BackgroundColorSetter: CellVisitor{ func visit(_ cell: FirstCell) { cell.contentView.backgroundColor = .black } func visit(_ cell: SecondCell) { cell.contentView.backgroundColor = .white } func visit(_ cell: ThirdCell) { cell.contentView.backgroundColor = .red } } 

Uso:

 override func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) { (cell as! Visitableell).accept(BackgroundColorSetter()) } 

Em vez de uma conclusão

Você pode gostar do padrão quase à primeira vista, no entanto, deve usá-lo com cuidado. Sua aparência no código geralmente pode ser um sinal de falhas mais gerais na arquitetura. Talvez você esteja tentando conectar coisas que não deveriam estar conectadas. Talvez a funcionalidade adicionada valha a pena elevar um nível de abstração de uma maneira ou de outra.

De uma forma ou de outra, quase qualquer padrão tem suas vantagens e desvantagens e, antes de usá-lo, você deve sempre pensar e tomar uma decisão conscientemente. Os padrões são, por um lado, uma maneira de generalizar as técnicas de programação para facilitar a leitura e a discussão do código. E por outro lado - uma maneira de resolver um problema (às vezes introduzido artificialmente). E, é claro, de qualquer forma, não traga fanaticamente o código para todos os padrões conhecidos apenas pelo fato de seu uso.

Acho que terminei! Todo o código bonito e menos "bugs"!

Meus outros artigos sobre padrões de design:

• “O padrão arquitetural do iterador no universo rápido”
• Método de fábrica e fábrica abstrata no universo Swift e iOS
• "Padrão arquitetural" Builder "no universo de" Swift "e" iOS "/" macOS "