A PROMOÇÃO DE INVERNO ESTÁ AQUI! 
Bridge em Ruby
O Bridge é um padrão de projeto estrutural que divide a lógica de negócio ou uma enorme classe em hierarquias de classe separadas que podem ser desenvolvidas independentemente.
Uma dessas hierarquias (geralmente chamada de Abstração) obterá uma referência a um objeto da segunda hierarquia (Implementação). A abstração poderá delegar algumas (às vezes, a maioria) de suas chamadas para o objeto de implementações. Como todas as implementações terão uma interface comum, elas seriam intercambiáveis dentro da abstração.
Complexidade:
Popularidade:
Exemplos de uso: O padrão Bridge é especialmente útil ao lidar com aplicações multi plataforma, oferecer suporte a vários tipos de servidores de banco de dados, ou ao trabalhar com vários provedores de API de um determinado tipo (por exemplo, plataformas em nuvem, redes sociais etc.)
Identificação: O Bridge pode ser reconhecida por uma distinção clara entre alguma entidade controladora e várias plataformas diferentes nas quais ela se baseia.
Exemplo conceitual
Este exemplo ilustra a estrutura do padrão de projeto Bridge. Ele se concentra em responder a estas perguntas:
- De quais classes ele consiste?
- Quais papéis essas classes desempenham?
- De que maneira os elementos do padrão estão relacionados?
main.rb: Exemplo conceitual
# The Abstraction defines the interface for the "control" part of the two class # hierarchies. It maintains a reference to an object of the Implementation # hierarchy and delegates all of the real work to this object. class Abstraction # @param [Implementation] implementation def initialize(implementation) @implementation = implementation end # @return [String] def operation "Abstraction: Base operation with:\n"\ "#{@implementation.operation_implementation}" end end # You can extend the Abstraction without changing the Implementation classes. class ExtendedAbstraction < Abstraction # @return [String] def operation "ExtendedAbstraction: Extended operation with:\n"\ "#{@implementation.operation_implementation}" end end # The Implementation defines the interface for all implementation classes. It # doesn't have to match the Abstraction's interface. In fact, the two interfaces # can be entirely different. Typically the Implementation interface provides # only primitive operations, while the Abstraction defines higher-level # operations based on those primitives. class Implementation # @abstract # # @return [String] def operation_implementation raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'" end end # Each Concrete Implementation corresponds to a specific platform and implements # the Implementation interface using that platform's API. class ConcreteImplementationA < Implementation # @return [String] def operation_implementation 'ConcreteImplementationA: Here\'s the result on the platform A.' end end class ConcreteImplementationB < Implementation # @return [String] def operation_implementation 'ConcreteImplementationB: Here\'s the result on the platform B.' end end # Except for the initialization phase, where an Abstraction object gets linked # with a specific Implementation object, the client code should only depend on # the Abstraction class. This way the client code can support any abstraction- # implementation combination. def client_code(abstraction) # ... print abstraction.operation # ... end # The client code should be able to work with any pre-configured abstraction- # implementation combination. implementation = ConcreteImplementationA.new abstraction = Abstraction.new(implementation) client_code(abstraction) puts "\n\n" implementation = ConcreteImplementationB.new abstraction = ExtendedAbstraction.new(implementation) client_code(abstraction) output.txt: Resultados da execução
Abstraction: Base operation with: ConcreteImplementationA: Here's the result on the platform A. ExtendedAbstraction: Extended operation with: ConcreteImplementationB: Here's the result on the platform B. 
