Procurando na documentação do ADK (hoje), não encontrei nenhum conteúdo sobre como fazer a integração do Google ADK com um fastAPI (pra subir em um container seu) para as requisições. Se alguém precisar, tá aí!

Meu objetivo não é nem explicar o que é o fastapi e nem o que é o adk, você pode consultar os links para buscar mais informações:

• FastAPI: https://fastapi.tiangolo.com
• Google ADK (Agent Development Kit): https://google.github.io/adk-docs/

Esta documentação foi feita em 15/dezembro/2025, então, e como as coisas estão evoluindo, pode acabar ficando defasada bem rápido. hehe

Este é o tree do projeto:

.
├── README.md
├── api.py
├── main.py
├── requirements.txt
└── root_agent
    └── agent.py

Dependencias

Pra começar tudo, eu não consegui instalar as dependências com o resolver padrão pip -r requirements.txt, ele da um problema em uma biblioteca que não consegue se resolver, a versão aceita pelo fastAPI não é aceita pelo google-adk, vc vai ficar recebendo este erro:

The conflict is caused by:
    google-adk 1.21.0 depends on starlette<1.0.0 and >=0.49.1
    fastapi 0.115.0 depends on starlette<0.39.0 and >=0.37.2

Neste caso, instalei as duas libs manualmente, e tudo funcionou muito bem. Não sei dizer qual é o problema de compatibilidade entre elas…

pip install google-adk
pip install fastapi

Agora o coding…

Meu root_agent/agent.py ficou assim:

from google.adk.agents.llm_agent import Agent

# Mock tool implementation
def get_current_time(city: str) -> dict:
    """Returns the current time in a specified city."""
    return {"status": "success", "city": city, "time": "10:30 AM"}

root_agent = Agent(
    model='gemini-2.5-flash',
    name='root_agent',
    description="Tells the current time in a specified city.",
    instruction="You are a helpful assistant that tells the current time in cities. Use the 'get_current_time' tool for this purpose.",
    tools=[get_current_time],
)

Meu api.py ficou assim:

from fastapi import APIRouter
from pydantic import BaseModel
from google.genai import types

# Use InMemoryRunner para facilitar, pois ele já configura serviços em memória
#   Também tem uma classe de runner, que você pode usar para plugar storage 
#   de sessão, conversa e etc.
from google.adk.runners import InMemoryRunner
from root_agent.agent import root_agent


router = APIRouter()

runner = InMemoryRunner(agent=root_agent)

class ChatRequest(BaseModel):
    message: str
    session_id: str = "default_session" # A sessão tem que vir do frontend, 
                                        # pra manter o historico para aquele
                                        # chat especificamente
    user_id: str = "default_user"


@router.post("/chat")
async def chat(req: ChatRequest):
    # Cria a mensagem no formato esperado pelo ADK
    new_message = types.UserContent(parts=[types.Part(text=req.message)])

    # Verifica s a sessão existe, senão, ele precisa criar ela
    session = await runner.session_service.get_session(
        app_name=runner.app_name,
        user_id=req.user_id,
        session_id=req.session_id
    )
    if not session:
        await runner.session_service.create_session(
            app_name=runner.app_name,
            user_id=req.user_id,
            session_id=req.session_id
        )

    response_text = ""

    # Usa run_async para processar a mensagem
    # O run_async retorna um gerador assíncrono de eventos, desta forma,
    # ele não bloqueia o event loop do fastapi, e permite várias requests
    # simultaneamente
    async for event in runner.run_async(
        user_id=req.user_id,
        session_id=req.session_id,
        new_message=new_message
    ):
        # Captura o texto da resposta do modelo
        # O evento pode conter várias coisas, aqui focamos no conteúdo de texto
        if event.content and event.content.parts:
            for part in event.content.parts:
                if part.text:
                    response_text += part.text

    return {
        "response": response_text
    }

E o meu main.py está assim:

from fastapi import FastAPI
from api import router

app = FastAPI(title="ADK API")

app.include_router(router)

Executando

Para executar ele, você precisará de uma API key do Google Cloud para poder fazer uma request para o Gemini (no meu exemplo é o 2.5 flash) como ENV GEMINI_API_KEY.

Você pode criar uma API key aqui no https://aistudio.google.com. (Para produção e uso em massa, é recomendado usar a API do vertex IA por estabilidade).

Para executar, suba o seu servidor:

uvicorn main:app --reload

E pode fazer a request com o curl:

curl -X POST "http://127.0.0.1:8000/chat" \
     -H "Content-Type: application/json" \
     -d '{
           "message": "Que horas são em Nova York?",
           "session_id": "teste_123",
           "user_id": "usuario_teste"
         }'

Percepções e cuidados

Eu não achei esta forma de executar o servidor documentado em nenhum lugar da doc oficial do ADK (talvez foi falha minha ao ler ela), então, tenha cautela se for usar isso em produção, pode ser que não seja uma API estável.

O google orienta na doc deles fazer deploy nas clouds deles diretamente, ou kubernetes, mas a vida pode ser um pouco mais simples, né.

No mercado, existem vários modelos e diagramas de trade-off que ajudam arquitetos de software a tomarem decisões estratégicas. Aqui estão os mais relevantes:

Trade-off Quadrant (Matriz de Trade-off)

📌 O que é?
• Um gráfico cartesiano onde cada eixo representa dois critérios opostos.
• Exemplo clássico: Escalabilidade vs. Simplicidade.

📌 Exemplo:
• Sistemas altamente escaláveis tendem a ser mais complexos.
• Sistemas simples geralmente sacrificam escalabilidade.
• A decisão depende do que é mais importante no momento.

🔹 Exemplo de matriz:

👉 Usado para: Decidir entre arquiteturas monolíticas, microsserviços, serverless, etc.

Architecture Decision Records (ADR) — Registro de Decisões Arquiteturais

📌 O que é?
• Um documento estruturado para registrar trade-offs e justificar escolhas arquiteturais.

Normalmente, segue o formato:
• Contexto: Qual o problema?
• Opções: Quais alternativas foram consideradas?
• Decisão: O que foi escolhido?
• Justificativa: Por quê?
• Consequências: Impactos positivos e negativos.

📌 Exemplo de decisão:
• Problema: Precisamos decidir entre GraphQL ou REST para uma API pública.
• Opções:
• GraphQL → Flexível para os consumidores, mas aumenta complexidade do backend.
• REST → Simples e bem documentado, mas menos flexível.
• Decisão: REST, porque nossos clientes já estão acostumados e a mudança para GraphQL teria um custo alto.

👉 Usado para: Documentar e justificar decisões técnicas dentro de times e empresas.

Trade-off Sliders (Deslizadores de Decisão)

📌 O que é?
• Uma escala visual para avaliar prós e contras de diferentes soluções.
• Cada critério é representado como um slider de 0 a 10.

📌 Exemplo:
Decisão entre SQL vs. NoSQL pode ser representada assim:

👉 Usado para: Comparar tecnologias e frameworks de maneira visual.

The Architecture Tradeoff Analysis Method (ATAM)

📌 O que é?
• Um método formalizado para avaliar arquitetura baseado em cenários, atributos e trade-offs.
• Ajuda times a prever riscos e entender impactos de decisões arquiteturais.

📌 Passos principais:
1. Definir objetivos e critérios (Exemplo: “queremos um sistema escalável e seguro”).
2. Listar atributos arquiteturais (Exemplo: disponibilidade, desempenho, manutenibilidade).
3. Criar cenários de avaliação (Exemplo: “Se um servidor cair, quanto tempo o sistema leva para se recuperar?”).
4. Identificar trade-offs (Exemplo: “Se aumentarmos a segurança, podemos impactar a performance?”).
5. Gerar recomendações para ajustes.

👉 Usado para: Analisar impactos de arquiteturas antes de implementá-las.

The Software Architecture Properties Table (SAPT)

📌 O que é?
• Uma tabela de trade-offs que avalia diferentes atributos de qualidade da arquitetura.
• Criada pelo SEI (Software Engineering Institute) para balancear performance, manutenibilidade, escalabilidade, etc.

📌 Exemplo:

👉 Usado para: Comparar arquiteturas em um formato estruturado.

A linguagem ajuda a revelar nossos pressupostos mais arraigados. Pense nestas frases reveladoras: quando realizamos algo importante, dizemos que exigiu “sangue, suor e lágrimas”. Afirmamos que grandes feitos são “duramente conquistados”, quando poderíamos dizer apenas “conquistados”.

A linguagem também denuncia nossa desconfiança da facilidade. Quando falamos de “dinheiro fácil”, insinuamos que foi obtido por meios ilegais ou questionáveis. Usamos a expressão “falar é fácil” como crítica, em geral, quando buscamos invalidar a opinião de alguém.

Acho curioso recorrermos a frases como “Não vai ser fácil, mas vai vale a pena” ou “será bem difícil conseguir isso, mas temos que tentar”. É como se todos aceitássemos automaticamente que o jeito “certo” é, de forma inevitável, o mais difícil.

Em minha experiência, raramente isso é questionado. Na verdade, se uma pessoa desafiar esse dogma, pode até pegar mal para ela. Nem paramos para pensar que algo essencial e valioso pode ser feito com facilidade.

Se o maior impedimento para fazermos o que importa for o falso pressuposto de que aquilo envolve um esforço imenso? E caso passarmos a pensar que se algo parece difícil, é porque ainda não encontramo o jeito mais fácil de fazê-lo?

Retirado do Livro: Sem esforço: Torne mais fácil o que é mais importante de Greg Mckeown

Recentemente estive lendo o livro “Your teams loves mondays? (…right?)” da Kristin Sherry, e encontrei um trecho que me chamou muita atenção, que a autora as chama de os desvirtuadores de carreira.

O que são os desvirtuadores de carreira?

Os desvirtuadores de carreira são alguns conjuntos de comportamentos nocivos para as pessoas, e principalmente para suas equipes, que dissipam a capacidade de trabalho em equipe.

Às oito características que apresentaremos a seguir estão relacionadas à estagnação na carreira de uma pessoa em todos os níveis. Estes são os comportamentos com maior probabilidade de deter o crescimento profissional.

• Incapacidade de se adaptar às mudanças: quando a pessoa tem problemas para atuar ou se adequar a novos chefes, estratégias, planos ou programas;
• Excesso de ambição: quando a pessoa olha apenas “para o seu próprio umbigo”, frequentemente, gerando prejuízo aos colegas;
• Arrogância: quando a pessoa pensa que tem sempre a resposta certa para todos os problemas, e descarta a opinião dos outros. Esta atitude gera sentimentos de inferioridade nos colegas, e acaba afastando-os, se tornando frio e arrogante;
• Desleal: quando a pessoa diz uma coisa e faz outra de maneira imprevisível, normalmente, estas pessoas também são inconsistentes e não honram seus compromissos, quebrando qualquer planejamento que se conte com elas para execução. Falta de transparência e confiança são grandes ofensores para o trabalho em equipe de qualquer organização.
• Falta de compostura: quando a pessoa é hostil ou sarcástica em momentos de estresse, ou quando algo foge do planejado. Estes comportamentos aumentam a quantidade de decisões erradas e precipitadas sob pressão, além de ser menos produtivo em momentos difíceis;
• Defensividade: quando a pessoa não está aberta a críticas, nega os próprios erros e falhas, culpa os outros, não aceita feedbacks negativos e não compartilha suas limitações pessoais.
• Insensibilidade: quando a pessoa é intimidadora, faz com que sua equipe se sinta mal, não se importando sobre a forma que a afeta ou com as necessidades alheias.
• Microgerenciamento: quando a pessoa interfere sem necessidade na rotina, removendo a autonomia de seus colegas. Algumas das causas deste problema é a incapacidade de delegar eficazmente atividades e falta de auto-confiança.

Conclusão

Acredito muito no desenvolvimento pessoal e autoconhecimento. Saber como você age em cada um destes cenários, fará toda a diferença para que nossa carreira não seja sabotada por nós mesmos.

Caso já recebeu alguma devolutiva, ou percebeu que fez algum destes comportamentos, é importante para, refletir e buscar melhorá-los, pois em algum momento sua carreira pode ser inibida de crescer por qualquer um deles.

E não dependa do seu líder, empresa, ou colegas apenas para melhorar… Sua carreira, é sua responsabilidade!

Muito obrigado pelo seu tempo!

Quando Shakespeare escrevia suas peças, as limitações eram apenas a sua imaginação e a ampla gama de possibilidades cênicas. Mas às vezes ele dirigia as suas próprias peças e então, embora pudesse fazer certas escolhas, ele tinha que seguir o roteiro comum usado por todos os atores. Nesse papel, a sua liberdade era reduzida. Em outras vezes ainda, o próprio Shakespeare tornava-se um ator. Então, sua única liberdade era variar a sua interpretação e recitação de suas falas.

Mas em cada um desses papéis, Shakespeare sabia quem ele era. Internamente ele não estava limitado ao papel e ao roteiro.

Na nossa vida haverá períodos em que parece que somos o autor, com grande liberdade de escolher uma direção. E então haverá períodos quando papéis mais limitados devem ser cumpridos: o progenitor, o ganha-pão, o cidadão, o membro da comunidade, o contemplativo, o líder, o liderado. Uma vida madura requer uma capacidade para entrar em cada um dos papéis que nos são dados.

A liberdade surge quando adotamos uma perspectiva leve, quando vemos cada um destes papéis pelo que eles são. Quando entendemos que precisamos nos libertar do nosso próprio “eu”, sem julgamentos. Cumprindo cada papel temporário que a vida nos presenteia, cada um no seu tempo.

“Quando você compreender seu próprio “eu”, verá que você não é nada. E não sendo nada, você é tudo”. Kalu Rinpoche

Retirado do livro “Psicologia do Amor” de Jack Kornfield.

Tenho feito mais de 50 entrevistas no último ano, e algumas características me chamam bastante atenção na seletiva de candidatos para nosso bate-papo.

Vou deixar aqui algumas dicas do que eu fiz a 6 anos atrás quando consegui minha primeira vaga em programação e que percebo que diferenciam bastante no momento de seleção de desenvolvedores para próximas etapas seletivas.

Não se prenda a detalhes

Se atentar a todos os detalhes é importante, mas para um desenvolvedor pleno para sênior.

Quando você utiliza o framework Rails, por exemplo, dificilmente você conseguirá entender a fundo como o Rails funciona no seu primeiro ano de desenvolvimento.

Não se prenda aos detalhes de como as coisas funcionam, se preocupe em aprender a entregar projetos pessoais e mostrar resultados.

Aprenda a usar GIT

Eu sinceramente, não conheço uma empresa hoje em dia que não utilize git para fazer o gerenciamento de versão do código. Recomendo estudar git e saber no mínimo o básico.

Alguns sites que recomendo para estudar git:

• https://www.freecodecamp.org/news/what-is-git-and-how-to-use-it-c341b049ae61/
• https://learngitbranching.js.org/

Crie um repositório pessoal no Github

O Github permite criar repositório pessoal para auto-apresentação.

Aqui você pode colocar links de repositórios pessoais e de coisas que você tem testado, pode ser a sua página de portfólio e blog com coisas que tem estudado. Para configurá-lo, pode acessar esta página, mas várias documentações podem te ajudar com isso.

• https://pages.github.com/

Existem vários modelos prontos na internet, no meu próprio github pages, possui uma documentação. Deixei aqui como exemplo de layout meu Github pessoal:

• https://andreleoni.github.io/

Crie projetos e envie para o Github

Acredito que a melhor forma de mostrar o que tem estudado, é de fato mostrando o que você tem estudado. O Github é uma ferramenta que você pode usar para mostrar isso. Tenha o hábito de submeter seus códigos de cursos e treinamentos que tem feito como portfólio e adiciona os que mais tem orgulho em sua página inicial do github pages.

Brinque com exercícios de lógica

Mostrar que você pratica exercícios de lógica também é um bom caminho para conseguir a tão sonhada primeira vaga de emprego em programação. Tenho algumas plataformas que gosto de brincar com exercícios, como, por exemplo:

• https://codesignal.com/
• https://www.codewars.com/

O interessante destes sites, é que você pode criar um perfil e exibir os exercícios que já tem feito.

Escreva o que você aprendeu

Escrever sobre seus aprendizados não é uma prática apenas para pessoas iniciantes, mas para desenvolvedores mais experientes também conseguirem ter uma melhor fixação dos assuntos que tem estudado. No caso de programador júnior, esta prática com certeza mostrará um genuíno interesse por programar, por se autodesenvolver, e por desenvolver as pessoas a sua volta.

Não espere ser um mestre no tema para escrever algo, escrever qualquer coisa pode ajudar alguém a tirar dúvidas simples, o que eu gosto de pensar sempre é: eu escrevo para mim mesmo, e não para os outros.

Meus artigos e repositórios do Github do medium são minha maior fonte de consulta de assuntos que já tenho estudado na vida.

Assista vídeos sobre como se portar em entrevistas

Veja vídeos de simulações de entrevistas para entender como funciona e se preparar para tal. Veja também sobre os requisitos da vaga, pois é o que provavelmente lhe perguntarão na entrevista. Alguns exemplos:

• https://www.youtube.com/watch?v=aI3D5WSX8rE
• https://www.youtube.com/watch?v=P2y1n_NyJy0

Utilize o Heroku como plataforma para publicar seus projetos pessoais

O Heroku (https://www.heroku.com/) é uma plataforma que você pode publicar seus portfólios e publicar até 5 aplicações de graça. É uma boa saída de baixo custo para mostrar seus conhecimentos.

Estude, estude e estude

Um pouquinho da minha história. Programo desde os 12 anos, e consegui um emprego em programação apenas aos 24 anos. Trabalhei por muito tempo em outras funções até conseguir juntar uma grana para me manter por um tempo enquanto estudava.

Quando decidi ir para programação, larguei meu antigo emprego e fiquei 9 meses estudando e criando meu portfólio na época (que não era tão fácil como hoje) para que a tão sonhada vaga viesse.

Em 6 anos de experiência hoje sou líder de uma equipe de cerca de 15 desenvolvedores no Enjoei.

Espero ter ajudado um pouco a explicitar os caminhos com algumas dicas simples.

Muito obrigado pelo seu tempo, e te desejo toda sorte do mundo nesta jornada.

Escolher a área de desenvolvimento em minha carreira foi a melhor decisão que já fiz na vida.

Lendo o livro “Quem mexeu no meu queijo” do Spencer Johnson tive alguns pontos que realmente me chamaram atenção…

O livro conta a história de 2 ratos, Sniff e Scurry, e 2 homenzinhos, Hem e Haw que estão presos em um labirinto, e o seu objetivo é correr atrás de queijo, sim, queijo! O livro faz relação de que o labirinto é a nossa caminhada pela vida, e o queijo é o nosso objetivo de vida (família, amigos, carreira, etc.).

Os ratos logicamente, são movidos pelo extinto, e os homens, inteligentes, pensativos, racionais, calculam o preço, tem poder de mudança, de decisão.

O que aconteceu?

O que acontece, é que ambos saem para procurar o seu queijo, e encontram… Os ratos, saem diariamente de suas casas para comer o queijo, como conta a história, ao chegar no local onde estão os queijos, Scurry, pendura seus tenis sobre o pescoço, para caso ocorra algum problema, ele possa rapidamente calçá-los e ir em busca de um novo queijo, e Sniff, é um farejador nato, ambos juntos, encontram novos queijos com facilidade.

Já os dois homens, são muito mais expertos e inteligentes, resolvem construir uma morada ao lado de onde o queijo está, assim, eles podem acordar um pouco mais tarde, e fazer pouco esforço para alcançá-lo, onde até então, isso é o melhor dos mundos!

O desfecho da história, é que o queijo onde estão os ratos e os homenzinhos, um dia acabou. Os ratos, perceberam que o queijo acabou e saíram rapidamente procurar outro queijo, depois de muito procurarem, acharam e se alimentaram, já os homens, ficaram se lamentando e tentando entender:

Como acabou o queijo?!

Os homens espertos como são, esperaram o queijo voltar “sozinho”, não acreditaram no que aconteceu, porque era tão bom, eles já haviam chegado no objetivo, não tinham o porque sair do lugar e continuar procurando, porque eles já haviam encontrado, estavam perdidos, não sabiam o que fazer, e de repente, Haw da uma gargalhada da situação, e fala “Precisamos sair pelo labirinto, e encontrar mais queijo!”, Hem achou uma péssima ideia, não quis sair da zona de conforto, e aceitar o desafio, afinal de contas, lá SEMPRE teve queijo, não tem porque ele ter sumido! O que os homens não se deram contas… é que o queijo estava acabando aos poucos, e já poderiam ter procurado outros lugares que tinham queijo.

No decorrer da história Hem fica esperando o queijo “voltar sozinho” enquanto Haw, passa por vários conflitos internos sobre ir atráz de um novo lugar com queijos, e com isso, ele anda escrevendo nas paredes frases de estímulo, como por exemplo:

O que você faria se não tivesse medo?

A espera que seu amigo as leia, e isso ajuda tanto ele, quanto seu amigo Hem, que decide ficar no antigo local de queijo, a encontrar a nova jazida de queijo!

Moral da História

Haw supera seus medos, aprende com eles, aprende que deve perceber as mudanças ao seu redor, e que deve se precaver caso aconteca novamente o problema de acabar o queijo, ou seja,

Haw aprendeu a se adaptar as mudanças e aos tempos de crise.

Enquanto isso, a história deixa em off a situação de Hem, como ele ficou?

Certamente, Hem ficou preso em seus medos de mudança, e morreu de fome.

Esta história nos ensina algumas lições:

• A mudança ocorre, continuam a mexer no queijo;
• Antecipe a mudança: prepare-se para caso o queijo não esteja mais lá;
• Monitore a mudança, cheire o queijo com frequência para saber quando está ficando velho;
• Adapte-se rapidamente a mudança, quanto mais rápido você esquece do velho queijo, mais rápido poderá saborear o outro;
• Saia do lugar, assim como o queijo!

O que mais me chamou atenção nesta história é a importância de nos atentarmos quem somos na história… Somos os ratos? Que agem rapidamente as mudanças, e quando acaba o queijo, rapidamente vão PROCURAR outro queijo sem agir precavidamente? Ou somos como Hem, que fica preso em seu medo, no medo de sair do lugar? Porque afinal, sempre deu certo! Ou somos como Haw, que luta com seus medos, vai em frente, aprende as lições, e age precavidamente quanto aos desafios e as mudanças da nossa vida?

Será que quando algo em nossa vida muda, olhamos para a situação e rimos, ou lamentamos? Rir da nossa situação pode ser a cura para o nosso medo, lembre-se que a procura pelo queijo pode demorar, mas o que importa, é que no final:

Você encontrou o seu queijo!

A teoria da janela quebrada afirma que uma janela quebrada, se não consertada, por algum tempo, transmite para as pessoas que ninguém se importa com o prédio. Então, de repente, outra janela é quebrada, se acumulando mais lixo, aparecem paredes pichadas, lixo no quintal, até que o dono não consegue mais dar conta de reparar os danos causados, tornando o que antes era um sentimento de abandono, em um real abandono.

Assim é um código sem testes, o próximo desenvolvedor com certeza terá a impressão de não houve zelo em fazer aquele código, produzindo mais códigos sem testes, ou, mais “Janelas quebradas”.

Com o passar do tempo, já não existem mais códigos com cobertura, todas as janelas foram quebradas, o código já não é mais refatorado, todas as boas práticas de desenvolvimento são quebradas, e todos se acham no direito de continuar quebrando janelas.

Sempre que uma janela é quebrada, abre brecha para que se quebre outra, e outra… Sendo assim, NUNCA quebra uma janela e NUNCA deixe passar uma janela quebrada sem se importar!

Baseado no livro: Agile: Desenvolvimento de software com entregas frequentes e foco no valor de negócio de André Faria Gomes (2013).

Imagine que você está hospedado em um hotel e o ar-condicionado não está funcionando direito. Você chama a recepção para falar sobre o problema, e eles respondem que estão cientes do problema e alguém vai consertar na semana que vem (depois que você for embora). Por enquanto, você poderia abrir a janela (que dá para aquela rua barulhenta e movimentada)? Nem sequer um pedido de desculpas, nem mesmo um tom de culpa.

Bem, o que antes causava apenas um pouco de aborrecimento (afinal, está fazendo 23C e você gosta de dormir a 20C) agora se tornou o fim do mundo! Você vai ficar furioso, jurar que vai escrever uma carta para a gerência e acabar com o hotel na avaliação on-line.

Jean-Louis Gassée, que costumava comandar a Apple France, descreve essa situação como a escolha entre dois botões.

Quando você lida com os problemas dos outros, pode optar por apertar o botão que diz “Não é grande coisa” ou o que diz “É o fim do mundo”. Qualquer que seja o botão escolhido, as pessoas pegam o outro.

A equipe do hotel no exemplo acima escolheu “Não é grande coisa” e, como resultado, foi forçada a lidar com “É o fim do mundo”. Mas poderiam muito bem ter feito a escolha oposta.

Imagine a equipe respondendo algo assim: “Sinto muito. Isso é claramente inaceitável! Posso entender completamente como deve ser quase impossível dormir em um quarto tão quente. Se eu não conseguir consertar esse problema hoje à noite, gostaria que eu reembolsasse sua estadia e o ajudasse a encontrar um quarto de hotel diferente nas proximidades? De qualquer forma, enquanto estamos buscando uma solução, permita-me enviar uma garrafa de agua gelada e sorvete. Nós sentimos muitíssimos por esse problema e faremos todo o possível para resolvê-lo”.

Com uma resposta como essa, você é quase forçado a escolher “Não é grande coisa”. Sim, claro, um pouco de água e sorvete vai ser ótimo!

Todos querem ser ouvidos e respeitados. Geralmente não custa muito fazer isso. E realmente não importa tanto assim se você pensa que está certo ou errado. Argumentar com quem está se sentindo prejudicado só vai aumentar o problema.

Tenha isso em mente na próxima vez que escolher um botão. Qual vai apertar para o seu cliente?

Retirado do livro “O trabalho não precisa ser uma loucura”.

Pedir dados de um objeto para saber se podemos executar uma ação, nos obriga a expor atributos deste objeto de maneira pública, o que, no princípio de orientação a objetos, é sempre algo que devemos evitar.

Partindo para um exemplo prático, um exemplo do que não deveria ser feito:

class Post
  attr_reader :state

  def initialize(state:)
    @state = state
  end

  def publish!
    @state = "published"
  end    
end

#### Example execution

post = Post.new(state: "draft")

if post.state == "draft"
  post.publish!
else
  raise StandardError.new("post not draft to be published")
end

post

Analisando o exemplo acima, temos que perguntar qual é o estado de um atributo a classe para saber seu conteúdo. Isso viola os princípios de encapsulamento e orientação a objetos. Com o passar do tempo, caso, várias rotinas possam publicar o um Post, possivelmente este código deverá ser duplicado entre vários trechos do código.

É aí que o conceito se aplica. Jamais devemos perguntar o valor de um atributo de um objeto para realizar uma ação, “Peça, não pergunte”.

Agora, vamos refatorar o exemplo acima sobre algo que poderia ser feito para melhorar este trecho de código.

Aplicando o conceito de Tell, don’t ask

class Post  
  def initialize(state:)
    @state = state
  end

  def publish!
    raise StandardError.new("post not draft to be published") if state != "draft"
    @state = "published"
  end

  private

  attr_reader :state
end

#### Example execution

post = Post.new(state: "draft")
post.publish!
post

Analisando a classe e o código de execução de teste, podemos perceber que agora não estamos mais perguntando o status do atributo de um objeto (o que podemos permitir que ele seja privado), apenas estamos pedindo para fazer, caso o objeto não consiga executar o que é necessário, ele mesmo levanta uma exceção, protegendo o comportamento de publicação de um Post e evitando possíveis duplicações de código em outros pedaços da aplicação.

Baseei este rápido post no do Martin Fowler.

Muito obrigado pelo seu tempo.