OOP, responsabilidade...

[criatividade zero 17]

estou com uma duvida a algum tempo sobre responsabilidade

tenho o nucleo da aplicação que é responsavel pela identificação da rota, controller e afins... dentro da APP eu rodo a classe request e preciso definir o idioma - pela opção do browser ou pelo cookie['lang']

a duvida é como executar a rotina:

 

passando os atributos para a classe

I18n::set( Request::language() , Cookie::get('language') ) );

nesse caso ele usa o primeiro atributo que bater, se encontrar na Request, o atributo cookie será passado em vão

 

ou acessando-os dentro da classe

I18n::set();

 

 

qual é a melhor forma de fazer isso?

manter a responsabilidade dentro da classe I18n?

[Bruno Augusto 417]

Eu vejo como melhor um método I18n::setDefault() que pode usar Cookie::get(), sendo invocado dentro da Request, antes de o dispatch do COntroller ser feito.

 

Nesse método você setaria o idioma partindo de vários pontos:

 

- Existe cookie? Ele quem manda.

 

- Não existe Cookie, então existe parâmetro GET? Então ele quem manda.

 

- Não existe Cookie e nem parâmetro GET, então use o idioma padrão definido na classe.

[visitante_php 0]

qual framework eh este? isso ajudaria um pouco...

[criatividade zero 17]

é meu mesmo

[João Batista Neto 448]

estou com uma duvida a algum tempo sobre responsabilidade

 

É complicado dizer qualquer coisa sobre responsabilidade sem ver o código.

 

Mas, pelo nome da classe, estou supondo que isso aqui seja uma violação:

 

Cookie::get('language')

 

Poste seu código, fica mais fácil ajudar e evita suposições erradas.

[criatividade zero 17]

a classe Cookie não esta feita ainda, mas o metodo get() me retorna o valor de um determinado indice do cookie

estava de olho na classe cookie do Cake

[João Batista Neto 448]

Certo, mas quando ela for construída, qual será o objetivo da classe Cookie?

[criatividade zero 17]

Certo, mas quando ela for construída, qual será o objetivo da classe Cookie?

se quer saber os metodos, serão basicamente

read, write, delete, e outras para verificação

 

era isso?

[João Batista Neto 448]

Nãaaaaaao,

 

Pergunta: Qual será o objetivo do Carro?

 

Sua resposta: Dar partida, engatar marcha....

 

Resposta correta: Locomover de um lugar para outro.

[criatividade zero 17]

vá com calma, fico com medo quando você faz pergunta

ahahahah :)

 

a classe vai criar cookie quando necessário, verificar os existentes, verificar salt, etc

vai ficar disponivel sempre que precisar trabalhar com alguma informação do cookie

[Bruno Augusto 417]

Então, na verdade você tem um Cookie Manager que trabalha com vários Cookies, certo?

[João Batista Neto 448]

hummmmm,

 

Programar orientado a objetos é muito fácil, basta enxergar os objetos que o resto é simples. Difícil é quando você não consegue vê-los, ai sua modelagem vai se parecer com a imagem abaixo:

 

 

No começo, ver os objetos é a parte mais difícil de se programar orientado a objetos, é preciso muito treino para conseguir vê-los. Mas isso não é tão problemático se você conversar com seu código. Imagine que você seja cego, como um bom cego, sua audição é aprimorada, então converse com seu código, ouça o que ele tem para lhe dizer.

 

Imagine que a imagem acima seja uma sala escura, você está lá dentro e sabe que os participantes da sua aplicação estão ali também.

 

Como você sabe que o participante Cookie está ai, converse com ele:

 

CZ:-- Hey Cookie, você está ai?

Co:-- Opa criatividade zero, estou aqui sim.

CZ:-- Então cara, um doido lá do Fórum iMasters me perguntou qual era seu objetivo, mas eu não soube responder.

Co:-- criatividade zero, meu objetivo é bem simples: Eu contenho informação.

CZ:-- Só isso???!!

Co:-- Bom, não é bem só isso. Muitas vezes, quando a aplicação no servidor precisa gravar uma informação no user agent do usuário, ela envia um cabeçalho HTTP na resposta com uma informação, então eu costumo ser muito importante para várias coisas.

CZ:-- Ah, e essa informação é para sempre? Serve para qualquer lugar?

Co:-- Nãaaaaaao, a informação tem data de validade, e serve para um domínio e caminho específico.

CZ:-- Poxa, que legal, e quando você chega no user agent do usuário, o que acontece?

Co:-- Eu fico no CookieJar, é bem legal o lugar. Sempre que o usuário faz um Request para o servidor, aparece em um telão o destino da requisição. Se o destino for o domínio e caminho que eu sirvo, eu embarco e volto para o servidor.

CZ:-- Então você fica trafegando, Request do usuário, Response do servidor, Request do usuário, igual bola de ping-pong.

Co:-- Mais ou menos isso, quando a informação perde a validade, eu faço checkout do CookieJar e não volto mais. A não ser, é claro, que a aplicação no servidor me mande novamente.

CZ:-- Mas é sempre igual, quando o usuário faz a requisição e quando o servidor dá a resposta, você sempre trafega da mesma forma?

Co:-- É parecido, mas não é igual. Quando o servidor me manda para o user agent do usuário, eu vou pela viação Set-Cookie, quando o usuário me manda para o servidor, eu vou pela Cookie.

CZ:-- Cookie, legal falar contigo, preciso fazer isso mais vezes. t+

 

Veja como a conversa foi produtiva, você identificou nessa conversa:

 

Cookie, CookieJar, Requisição, Resposta e Cabeçalho HTTP.

 

Viu que o Cookie tem um objetivo específico e fica armazenado no CookieJar do U-A e que, quando perde a validade, não é enviado de volta para o servidor.

 

Viu também que o Cookie trafega em um Cabeçalho HTTP que tem tanto na Requisição quanto na Resposta.

 

Olha só como seu modelo já começou a clarear:

 

 

Mas ainda tem algumas lacunas ai, então pode ser interessante você conversar com o Request:

 

CZ:-- Hey Request, você está ai?

Rq:-- Hey criatividade zero, estou sim cara, diga ai.

CZ:-- Então cara, eu estava conversando com o Cookie e ele me disse que quando o usuário faz uma requisição ao servidor, ele vai no meio de alguns cabeçalhos HTTP que você manda. O que mais você manda para o servidor?

Rq:-- Sempre que o usuário faz uma requisição, ele a faz para um domínio e um caminho específico. Existem vários métodos de se fazer uma requisição, pode ser HEAD, GET, POST, PUT, etc.

CZ:-- Ah, então você manda para o servidor um método de requisição, cabeçalhos HTTP e só?

Rq:-- Não, além do método da requisição e dos cabeçalhos HTTP, eu envio também um corpo de requisição, que é como o servidor vai saber o que é que o usuário está requisitando.

CZ:-- Hum, então se não tiver um corpo na requisição o servidor não sabe o que o usuário está querendo?

Rq:-- Algumas requisições não precisam de corpo, mas a grande maioria precisa. Já viu na barra de endereços que tem o domínio/caminho e um monte de par nome=valor separado pelo símbolo &, então, esse é o corpo de uma requisição GET. Quando isso chega no servidor, a aplicação decide o que fazer com isso e manda a resposta para o usuário.

CZ:-- Então o usuário pode, por exemplo, dizer que quer um conteúdo qualquer usando GET ou outro método e o servidor além de responder com a informação que o usuário pediu, ainda mandar um Cookie para o UA do usuário para facilitar a vida dele? Tipo, para que o usuário não tenha que ficar pedindo a mesma informação sempre?

Rq:-- Exatamente, alguns tipos de informação como preferência de usuário pode ser gravada em um Cookie, assim o usuário faz a requisição uma vez escolhendo, por exemplo, o idioma que quer navegar, o servidor pega essa informação e grava um Cookie na máquina do usuário e, com isso, quando o usuário fizer uma nova requisição, o Cookie é enviado para o servidor dizendo o idioma que ele quer ver o conteúdo.

 

Bom, como pode ver, o usuário pode ter preferências de navegação e falar isso para o servidor. Para evitar que o usuário fique dizendo suas preferências sempre que fizer uma requisição, o servidor manda um Cookie na resposta.

 

Não deu para identificar muita coisa nessa conversa, mas descobrimos que uma requisição é feita usando um método para um domínio e um caminho específico e também que uma requisição tem cabeçalhos e corpo:

 

 

Pode ser legal conversar com o Response:

 

CZ:-- Hey Response, você está ai?

Rs:-- Opa, diga lá!

CZ:-- Eu estava falando com o Request agora a pouco, ele disse que tem método, cabeçalhos e corpo de requisição. Disse também que o usuário pode mandar preferências de navegação e que você pode mandar um Cookie e outros cabeçalhos HTTP, como é isso?

Rs:-- Cara, eu sou bem parecido com o Request, tenho cabeçalhos HTTP, corpo de resposta mas, além disso, tenho também um código e uma mensagem de status. As vezes o usuário faz umas khdas sabe, ai eu preciso dar uma dura nele dizendo que a requisição não é válida, que o acesso é restrito, enfim. Agora, se a requisição estiver certinha, eu respondo Ok e entrego o conteúdo que ele pediu.

CZ:-- kkkkk, pois é, usuário é cheio de atrapalhar a vida do desenvolvedor. Mas e como você decide, por exemplo, qual o idioma vai entregar para o usuário quando ele faz uma requisição?

Rs:-- Eu não decido nada, só entrego o conteúdo. Quem decide isso é a Application, e se a Application vacilar, eu cagueto para o usuário mandando um código de status 500, heheheh.

CZ:-- Poxa, valeu Request, vou ver se consigo falar com a Application então.

 

Bom, agora sabemos que o Response é bem parecido com o Request:

 

 

Descobrimos também que a questão do idioma é problema da Application, então vamos conversar com ela:

 

CZ:-- Application, você está ai?

Ap:-- Ocupado!

CZ:-- É rapidinho, prometo.

Ap:-- Diga rápido então. ¬¬

CZ:-- Falei com o Request e ele disse que o usuário pode escolher preferências de navegação, mandando a informação na requisição. O Response disse que pode entregar o conteúdo no idioma que o usuário preferir, mas que é responsabilidade sua decidir qual idioma entregar. Como funciona isso?

Ap:-- A primeira vez que o usuário acessa a aplicação, eu tento identificar a localização dele, se eu conseguir eu mando o conteúdo internacionalizado mais adequado para aquela localização, se tiver um é claro, do contrário, eu mando o conteúdo no idioma padrão. Se o usuário preferir outro idioma, ele precisa me dizer. Quando o usuário me disser eu mando o conteúdo internacionalizado segundo a preferência dele.

CZ:-- Mas quando você tenta identificar a localização dele, como você faz?

Ap:-- Ocupado! ¬¬

CZ:-- Só mais essa, vai!

Ap:-- Quando o usuário manda a requisição pelo UA, um cabeçalho HTTP é enviado com algumas informações, por exemplo, o idioma que está configurado no UA dele. Além disso, tem o IP que dá para usar também. Então a primeira coisa que eu faço é ver na requisição se tem um Cookie, se não tiver, eu vejo nos cabeçalhos HTTP se tem um Accept-Language, enfim, se eu encontro alguma coisa que me leve a supor que o usuário prefere determinado idioma, eu vejo com na internacionalização se existe um pacote para aquela localização ou preferência do usuário. Se não tiver, mando o padrão e pronto.

CZ:-- Poxa, valeu, se eu tiver mais alguma dúvida posso perguntar?

Ap:-- Ocupado!!!!! ¬¬

 

Bom, Application recebe uma requisição, verifica se existe alguma coisa nessa requisição que ajude a identificar a localização, seleciona o pacote de internacionalização e entrega uma resposta:

 

 

Se você continuar conversando, você vai perceber o tanto de informações úteis que você vai obter.

 

;)

[gremio10 14]

:clap:

[Suissa 1]

PQP essa foi fóda hein! Da para você lançar um quadrinho desse naipe explicando aplicações Web com personagens hehehhehe

[Alaerte Gabriel 662]

Clássico.

[advaldomesquita 93]

Se superando nas explicações a cada post.

 

Resta saber se o user criatividade zero conseguiu achar as respostas para as duvidas:

qual é a melhor forma de fazer isso?

manter a responsabilidade dentro da classe I18n?

[João Batista Neto 448]

qual é a melhor forma de fazer isso?

manter a responsabilidade dentro da classe I18n?

 

Bom, é fácil perceber isso na conversa com Application. Porque acham que Application está tão ocupado????

 

Simples, porque as decisões acontecem ali.

 

;)

[Bruno Augusto 417]

Impressionante! :clap:

 

Até eu que ainda estou engatinhando na coisa entendi direitinho. E o que é melhor, mesmo sem ter conhecimento profundo da coisa, percebi que estou fazendo certo. :grin:

 

Já para o Suissa, teria que ver com os cartunistas de plantão. Mas pelo visto o RAN sumiu do fórum...

[Giovani 104]

Concordo :)

PQP essa foi fóda hein! Da para você lançar um quadrinho desse naipe explicando aplicações Web com personagens hehehhehe

[Suissa 1]

Se eu soubesse fazer um mínimo de desenho ja estaria começando =p