The Codest
  • Sobre nós
  • Serviços
    • Desenvolvimento de software
      • Desenvolvimento de front-end
      • Desenvolvimento backend
    • Staff Augmentation
      • Programadores Frontend
      • Programadores de back-end
      • Engenheiros de dados
      • Engenheiros de nuvem
      • Engenheiros de GQ
      • Outros
    • Aconselhamento
      • Auditoria e consultoria
  • Indústrias
    • Fintech e Banca
    • E-commerce
    • Adtech
    • Tecnologia da saúde
    • Fabrico
    • Logística
    • Automóvel
    • IOT
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • A nossa equipa
  • Case Studies
  • Saber como
    • Blogue
    • Encontros
    • Webinars
    • Recursos
Carreiras Entrar em contacto
  • Sobre nós
  • Serviços
    • Desenvolvimento de software
      • Desenvolvimento de front-end
      • Desenvolvimento backend
    • Staff Augmentation
      • Programadores Frontend
      • Programadores de back-end
      • Engenheiros de dados
      • Engenheiros de nuvem
      • Engenheiros de GQ
      • Outros
    • Aconselhamento
      • Auditoria e consultoria
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • A nossa equipa
  • Case Studies
  • Saber como
    • Blogue
    • Encontros
    • Webinars
    • Recursos
Carreiras Entrar em contacto
Seta para trás VOLTAR
2018-12-14
Desenvolvimento de software

Linguagem específica do domínio Ruby

Bartlomiej Maziarz

De acordo com a definição, DSL (Domain Specific Language) é uma linguagem informática especializada num determinado domínio de aplicação. Isto significa que é desenvolvida para satisfazer necessidades específicas.

Ao ler este artigo, ficará a saber o que é a DSL e o que tem em comum com Rubi.

DSL, diz bem-vindo!

De acordo com a definição, DSL (Domain Specific Language) é uma linguagem informática especializada num determinado domínio de aplicação. Isto significa que é desenvolvida para satisfazer necessidades específicas. Existem dois tipos de DSL:

  • Um externo DSL que requer o seu próprio analisador sintático. Um bom exemplo conhecido é a linguagem SQL - permite interagir com a base de dados numa linguagem em que a base de dados não foi criada.

  • Um interno DSL que não tem a sua própria sintaxe, mas que utiliza a sintaxe de uma determinada linguagem de programação.

Como deve calcular, vamos concentrar-nos no segundo tipo de DSL.

O que é que faz?

Basicamente, ao utilizar a metaprogramação do Ruby, permite criar a sua própria mini-linguagem. A metaprogramação é uma técnica de programação que permite escrever uma código dinamicamente em tempo de execução (on the fly). Pode não ter conhecimento disto, mas provavelmente utiliza muitas DSLs diferentes todos os dias. Para compreender o que uma DSL pode fazer, vejamos alguns exemplos abaixo - todos eles têm um elemento comum, mas consegue identificá-lo?

Roteamento de Rails

Carris.application.routes.draw do
root to: 'home#index'

recursos :utilizadores do
get :search, on: :coleção
fim
fim
```

Todas as pessoas que já usaram Rails conhecem um config/routes.rb onde definimos as rotas da aplicação (mapeamento entre verbos HTTP e URLs para acções do controlador). Mas já se perguntou como é que isto funciona? De facto, é apenas código Ruby.

Fábrica de Bot

 FactoryBot.define do
   fábrica :utilizador do
     empresa
     sequence(:email) { |i| "user_#{i}@test.com" }
     sequence(:first_name) { |i| "Utilizador #{i}" }
     apelido 'Teste
     função 'manager' (gestor)
   fim
 fim

Escrever testes requer muitas vezes a fabricação de objectos. Assim, para evitar uma perda de tempo, seria realmente uma boa ideia simplificar o processo tanto quanto possível. É isso que o FactoryBot faz - palavras-chave fáceis de memorizar e uma forma de descrever um objeto.

Sinatra

requerer 'sinatra/base'

classe WebApplication < Sinatra::Base
get '/' do
'Olá mundo'
end
fim
```

Sinatra é uma estrutura que permite criar aplicações Web a partir do zero. Poderia ser mais fácil definir o método de pedido, o caminho e a resposta?

Outros exemplos de DSL podem ser Ancinho, RSpec ou Registo ativo. O elemento-chave de cada DSL é a utilização de blocos.

Tempo de construção

É altura de perceber o que se esconde por detrás do capô e como pode ser a implementação.

Vamos supor que temos uma aplicação que armazena dados sobre diferentes produtos. Queremos alargá-la, dando-lhe a possibilidade de importar dados de um ficheiro definido pelo utilizador. Além disso, o ficheiro deve permitir calcular valores dinamicamente, se necessário. Para o conseguir, decidimos criar uma DSL.

Um simples produto A representação pode ter os seguintes atributos (produto.rb):

 class Produto
   attr_accessor :nome, :descrição, :preço
 fim

Em vez de utilizarmos uma base de dados real, limitar-nos-emos a simular o seu funcionamento (base_de_produtos_falsa.rb):

 class FakeProductsDatabase
   def self.store(produto)
     coloca [produto.nome, produto.descrição, produto.preço].join(' - ')
   end
 end

Agora, vamos criar uma classe que será responsável pela leitura e tratamento do ficheiro que contém os dados dos produtos (dsl/data_importer.rb):

módulo Dsl
classe DataImporter
módulo Sintaxe
def add_product(&block)
FakeProductsDatabase.store product(&block)
fim

  privado

  def produto(&bloco)
    ProductBuilder.new.tap { |b| b.instance_eval(&block) }.product
  fim
fim

incluir Sintaxe

def self.import_data(file_path)
  new.instance_eval File.read(file_path)
fim

fim
fim
```

A classe tem um método chamado dados_importados que espera um caminho de ficheiro como argumento. O ficheiro está a ser lido e o resultado é passado para a função avaliação_de_instância que é chamado na instância da classe. O que é que ele faz? Avalia a cadeia de caracteres como um código Ruby no contexto da instância. Isto significa que próprio será a instância de Importador de dados classe. Graças ao facto de podermos definir a sintaxe/palavras-chave pretendidas (para uma melhor legibilidade, a sintaxe é definida como um módulo). Quando o adicionar_produto é chamado, o bloco dado para o método é avaliado por Construtor de produtos instância que constrói Produto instância. Construtor de produtos é descrita abaixo (dsl/product_builder.rb):

módulo Dsl
classe ProductBuilder
ATRIBUTOS = %i[nome descrição preço].freeze

attr_reader :produto

def initialize
  @produto = Produto.novo
fim

ATRIBUTOS.each do |attribute|
  define_method(attribute) do |arg = nil, &block|
    value = block.is_a?(Proc) ? block.call : arg
    product.public_send("#{attribute}=", value)
  fim
fim

fim
fim
```

A classe define a sintaxe permitida dentro de adicionar_produto bloco. Com um pouco de metaprogramação, adiciona métodos que atribuem valores aos atributos do produto. Estes métodos também suportam a passagem de um bloco em vez de um valor direto, pelo que o valor pode ser calculado em tempo de execução. Utilizando o leitor de atributos, podemos obter um produto construído no final.

Agora, vamos adicionar o script de importação (import_job.rb):

requirerelative "dsl/dataimporter
requirerelative 'dsl/productbuilder' (em inglês)
requirerelative 'fakeproductsdatabase' (base de dados de produtos falsos)
requirerelative 'product' (produto)

Dsl::DataImporter.import_data(ARGV[0])
```

E finalmente - usando a nossa DSL - um ficheiro com os dados dos produtos (dataset.rb):

```ruby
adicionar_produto do
nome 'Carregador'
descrição 'Salva-vidas'
preço 19,99
fim

add_product do
nome 'Naufrágio do carro'
description { "Destruído em #{Time.now.strftime('%F %T')}" }
preço 0,01
fim

add_product do
nome 'Lockpick' (chaveiro)
descrição 'As portas não se fecham'
preço 7.50
fim
```

Para importar os dados, só precisamos de executar um comando:

 ruby import_job.rb dataset.rb

E o resultado é...

 Carregador - Salvamento de vidas - 19.99
 Destruição de carro - Destruído em 2018-12-09 09:47:42 - 0.01
 Chave de fechadura - As portas não fecham - 7.5

... sucesso!

Conclusão

Observando todos os exemplos acima, não é difícil perceber as possibilidades oferecidas pela DSL. A DSL permite simplificar algumas operações de rotina, ocultando toda a lógica necessária e expondo ao utilizador apenas as palavras-chave mais importantes. Permite-lhe obter um nível mais elevado de abstração e oferece possibilidades de utilização flexíveis (o que é especialmente valioso em termos de reutilização). Por outro lado, adicionar DSL ao seu projeto deve ser sempre bem considerado - uma implementação que utiliza metaprogramação é definitivamente muito mais difícil de entender e manter. Além disso, requer um conjunto sólido de testes devido ao seu dinamismo. Documentar a DSL facilita a sua compreensão, pelo que vale mesmo a pena fazê-lo. Embora a implementação da sua própria DSL possa ser gratificante, é bom lembrar que tem de compensar.

Ficou interessado no tema? Se sim, diga nós sabe - vamos falar-lhe da DSL que criámos recentemente para satisfazer os requisitos de um dos nossos projectos.

Artigos relacionados

Ilustração de uma aplicação de cuidados de saúde para smartphone com um ícone de coração e um gráfico de saúde em ascensão, com o logótipo The Codest, representando soluções digitais de saúde e HealthTech.
Desenvolvimento de software

Softwares para o setor de saúde: Tipos, casos de uso

As ferramentas em que as organizações de cuidados de saúde confiam atualmente não se assemelham em nada às fichas de papel de há décadas atrás. O software de cuidados de saúde apoia agora os sistemas de saúde, os cuidados aos doentes e a prestação de cuidados de saúde modernos em...

OCODEST
Ilustração abstrata de um gráfico de barras em declínio com uma seta ascendente e uma moeda de ouro que simboliza a eficiência ou a poupança de custos. O logótipo The Codest aparece no canto superior esquerdo com o slogan "In Code We Trust" sobre um fundo cinzento claro
Desenvolvimento de software

Como dimensionar a sua equipa de desenvolvimento sem perder a qualidade do produto

Aumentar a sua equipa de desenvolvimento? Saiba como crescer sem sacrificar a qualidade do produto. Este guia cobre sinais de que é hora de escalar, estrutura da equipe, contratação, liderança e ferramentas - além de como o The Codest pode...

OCODEST
Desenvolvimento de software

Construir aplicações Web preparadas para o futuro: ideias da equipa de especialistas do The Codest

Descubra como o The Codest se destaca na criação de aplicações web escaláveis e interactivas com tecnologias de ponta, proporcionando experiências de utilizador perfeitas em todas as plataformas. Saiba como a nossa experiência impulsiona a transformação digital e o negócio...

OCODEST
Desenvolvimento de software

As 10 principais empresas de desenvolvimento de software sediadas na Letónia

Saiba mais sobre as principais empresas de desenvolvimento de software da Letónia e as suas soluções inovadoras no nosso último artigo. Descubra como estes líderes tecnológicos podem ajudar a elevar o seu negócio.

thecodest
Soluções para empresas e escalas

Fundamentos do desenvolvimento de software Java: Um Guia para Terceirizar com Sucesso

Explore este guia essencial sobre o desenvolvimento de software Java outsourcing com sucesso para aumentar a eficiência, aceder a conhecimentos especializados e impulsionar o sucesso do projeto com The Codest.

thecodest

Subscreva a nossa base de conhecimentos e mantenha-se atualizado sobre os conhecimentos do sector das TI.

    Sobre nós

    The Codest - Empresa internacional de desenvolvimento de software com centros tecnológicos na Polónia.

    Reino Unido - Sede

    • Office 303B, 182-184 High Street North E6 2JA
      Londres, Inglaterra

    Polónia - Pólos tecnológicos locais

    • Parque de escritórios Fabryczna, Aleja
      Pokoju 18, 31-564 Cracóvia
    • Embaixada do Cérebro, Konstruktorska
      11, 02-673 Varsóvia, Polónia

      The Codest

    • Início
    • Sobre nós
    • Serviços
    • Case Studies
    • Saber como
    • Carreiras
    • Dicionário

      Serviços

    • Aconselhamento
    • Desenvolvimento de software
    • Desenvolvimento backend
    • Desenvolvimento de front-end
    • Staff Augmentation
    • Programadores de back-end
    • Engenheiros de nuvem
    • Engenheiros de dados
    • Outros
    • Engenheiros de GQ

      Recursos

    • Factos e mitos sobre a cooperação com um parceiro externo de desenvolvimento de software
    • Dos EUA para a Europa: Porque é que as empresas americanas decidem mudar-se para a Europa?
    • Comparação dos centros de desenvolvimento da Tech Offshore: Tech Offshore Europa (Polónia), ASEAN (Filipinas), Eurásia (Turquia)
    • Quais são os principais desafios dos CTOs e dos CIOs?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Direitos de autor © 2026 por The Codest. Todos os direitos reservados.

    pt_PTPortuguese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese es_ESSpanish nl_NLDutch etEstonian elGreek cs_CZCzech pt_PTPortuguese