Author Archives: Octavio Turra

K.O. – Javascriptality

Boas práticas, HTML, Javascript 1 Reply

Olá, tudo bom?

Sabe, eu mexo há muito tempo com site, sistema Web e essas parafernálias todas, porém sempre há coisas desagradáveis para fazer. Graças ao advento de frameworks bizonhos que vem acontecendo nos últimos tempos, a vida vai ficando mais fácil.

Apesar de eu ter outras paixões, vou falar um pouco de Knockout.js.

Bom, quem já criou um projeto em Microsoft MVC 4 com aqueles templates disponíveis, é possível reparar a biblioteca do KO “largada” lá na pasta scripts. Sabe como é né, eu estava lá, o arquivo também, não tínhamos muito o que fazer e eu estava meio carente de uns CRUDs e pensei: “por que não?”

O Knockout é um framework javascript MVVM (Model View View Model) que se baseia principalmente no conceito de atualização da view e no bind de valores. Fornece uma estrutura para template e ajuda na hora de trabalhar com formulários e transformações. Pense que o seu foco é ajudar na criação de aplicações web, mas, ao contrário de outras ferramentas mais monstruosas e complexas, o KO é de fácil utilização e encaixa bem na hora de brincar com coisas mais simples, sites ou até mesmo no apoio ao desenvolvimento com .NET (como foi meu caso).

Dentre as diversas funcionalidades, o KO trabalha com 3 que acho especialmente bacanas e é delas que vou escrever um pouco. E, não esquecendo, o que mais me atraiu foi a documentação, que é simples, direta e sem firulas, então, aproveite e dê uma olhada para conhecer também.

Two-way data binding

Essa facilidade é voltada para você fazer uma conexão entre propriedades do DOM e variáveis ou objetos. Através da função “ko.observable()”, ao alterar um valor, por exemplo em um input, automaticamente é atualizado na variável ou objeto. O acesso às variáveis, após o observable ser configurado, será feito através de função homônima, esse foi um detalhe que meio que me deixou estranho, mas com o tempo acostuma.

Binding Array e Event Function

Do mesmo jeito que dá para fazer o bind com uma propriedade, é possível fazê-lo com arrays. Isso fica legal para as clássicas listas e trabalhar com aplicações mais complexas, que carregam coisas do banco de dados e disponibilizam em uma tabela, lista ou qualquer coisa assim. Utilizando o bind de array, logo que haja uma modificação no seu conteúdo, o DOM pode sensibilizado. Para isto, utiliza-se também uma propriedade de bind bacana que é o “foreach”.

Só essa facilidade já é legal porém, para ter um pouco mais de tempero, a gente faz o bind também de um evento com uma função. (tudo isso sem jQuery). Através dos bindings de evento, alguns pré prontos e outros que você pode chamar via propriedade “event”, é possível fazer o equivalente ao $(…).on, mas configurando direto no HTML.

Vantagens

Certo, vendo a aplicação assim, pense que, se você estiver trabalhando com jquery e quiser mudar todo seu layout, há uma certa amarração entre o HTML e o código javascript. Esse tipo de vínculo acaba sendo separado ao fazer uso dos observables e dos binds de funções, já que a configuração é feita na sua view, enquanto o seu javascript só vai entender e procurar o que estiver configurado na página.

Outra coisa é a repetição. Ao invés de fazer um código 10 vezes, uma função bem feitinha pode ser útil e trabalhar independente, facilitando na manutenção.

Enfim, o KO tem uma documentação bacana, funcionalidades úteis, outras que nem abordamos aqui e até casa bem com outros frameworks, para fazer mais bruxarias.

Concluindo

A ideia de se utilizar uma ferramenta destas é facilitar a vida e tornar o código limpo. Fica muito mais fácil de codificar quando as coisas fluem. Pense que você tem uma aplicação complexa, uma alteração afetando outro lado da página, diversos bindings, 10 dias de texto com $ aqui $ ali. O knockout.js serve justamente para evitar retrabalho e tornar a aplicação sólida. Lembrando que:

Pra cada código que você faz, um coitado vai ter que dar manutenção e ler 10 vezes mais

Enfim, visite o site e brinque um pouco com o código. Tem tutoriais lá explicando passo a passo como utilizar algumas das principais funcionalidades e, como disse antes, o KO vem junto com alguns templates de aplicação MVC 4, então, não custa dar uma testada.

Até mais ^^.

Legibilidade, nomes e if

Boas práticas, C# 1 Reply

Olá, tudo bom?

Hoje vou falar sobre Legibilidade. No dicionário: s.f. Qualidade do que é legível.

Vamos começar com uma contextualização do que é legível e depois passamos para a parte de código.

Contexto dia-à-dia

Bom, para começar, temos que pensar no nosso cotidiano. Vamos entender que, o que escrevemos é para outras pessoas lerem.

“Mas Octávio, e o que eu escrevo no meu diário pessoal e nos bilhetes grudados no monitor?”

Pense o seguinte: “Amanhã você será outra pessoa” (Momento motivacional). Assim sendo, você vai ter que entender o que escreveu e entender o motivo. De preferência também vai ter que lembrar o que estava acontecendo naquele momento, logo, para um texto ficar bom tem que expressar claramente o contexto em que foi escrito e seu objetivo de ser.

Um texto legível portanto, é aquele que deixa claro que você não está subentendendo que a pessoa tenha poderes alienígenas de ler a mente de ninguém, nem uma máquina do tempo para perguntar o que você estava querendo dizer no momento (afinal, isso também muda).

Enfim, se quiser que o que você escreva seja fácil dos outros lerem e entenderem de verdade, imagine que está escrevendo para uma criança que, de preferência, não seja superdotada.

Código

Ok, eu estou aqui para falar de código. Eu estou escrevendo baseado em textos que li e conteúdo que estudei, portanto, é a minha visão e interpretação, ficando a brecha para ser aplicado^^.

Nomes

Isso é um tema para livros, então vou tentar ser simples:

O nome do que quer que você esteja escrevendo deve, no mínimo, significar o que você quer que seja.

Uma função que carrega os dados da tabela pessoas não vai se chamar “GerarVerdeComBolinhas”. Portanto, busque representar o significado das coisas pensando que:

  • Métodos fazem algo portanto, uso verbos
  • Atributos representam algo portanto, uso substantivos
  • Classes também represento algo portanto, uso a lógica de cima
  • Não tenha medo de nomes grandes e sim de códigos gigantes por causa de uma toupeira que não sabia que o método já fazia isso

É simples: o código de um programador deve ser tão fácil e agradável de ler quanto um livro infantil.

Métodos e Classes

Um método faz o que seu título está dizendo que faz, o mesmo acontece nas classes. Se um código está contendo mais do que uma atividade então é simples, divida-o ou se a classe chama Ovo, os atributos de pintinho ficam na classe Pintinho. Seus métodos e seu código, quanto mais específicos, melhores de se entender, pois é um inferno ficar inferindo o que alguém está querendo dizer com as 2000 linhas de uma função “CriarConta”. Não preciso dizer o que ela deveria fazer né?

Propriedades, atributos, variáveis e parâmetros

Em C#, propriedades e atributos começam com letras maiúsculas, enquanto variáveis e parâmetros usam minúsculas. Isso é importante pra diferenciar seu objetivo, mas não só, para entender o que é privado, o que é do escopo, quem está dentro e quem está fora. Os seus nomes devem representar o que irão conter, pois todos representam caixinhas, que terão um conteúdo específico.

Condição If

A coisa mais usada na lógica é o tratamento de condição, assim como também deve ser a mais evitada. Entretanto, sendo um mal necessário, temos que fazer o máximo para ser compreensível de se ler e prático de dar manutenção.

O problema de um If é que “se alguém entender errado, todo o resto vai ser interpretado errado”. Certa vez discordei muito de pessoas que reclamavam disso, mas hoje eu entendo que há peculiaridades (bonito né) que desenvolve um belo “macarrão” em códigos com “ifs estranhos”.

Comparação negativa

Comparação negativa é feita com “== false” e não com “!”, pois se eu estou fazendo tudo correndo (como normalmente fazemos), eu NÃO VOU REPARAR EM UMA MINHOCA COM UM PINGO DEPOIS DE UM PARÊNTESE. Fica difícil parar para identificar os caracteres e quanto mais claro estiver na tela, melhor para identificar.

Chaves

Eu coloco “{” depois da condição e “}” no fim da condição, pois sempre vai ter uma toupeira que irá fazer algo assim:

Outra coisa é “onde enfiar as chaves”. Se você está programando em Java, use o padrão de Java, se for C#, use o padrão de C#, assim por diante, pois o programador tem que sentar na máquina e saber o que está fazendo e é a pior coisa do mundo ficar reaprendendo padrões mundiais por frescuras internas.

If com else ou return?

Busque um padrão!!! If com else tem duas opções dentro de uma função, ou você usa o else, ou você da um retorno:

E qual é o melhor modelo? Não importa, os dois são bacanas, mas deve haver um padrão. Não comece com else e termine com return, seu código deve ser consistente, ler tem que ser algo que siga uma linha e não uma feira cultural.

Encadeamento

Noooooooooooooo! Se seu if puder ser separado, melhor. O cérebro não é feito para tratar tantas condições de uma vez de forma consciente. Imagine que uma coisa é encadear uma vez, a outra é fazer o sistema todo encadeado (Neste momento eu passo a ser fã do modelo “return” citado anteriormente). Quebre seu encadeamento, nem que seja com outros métodos afinal, se existem tantas condições em um método, tem algo de errado com a lógica do “faça apenas uma coisa” e não ficar assim:

Na versão que costumo fazer, uso bastante do return e separo funções, para tentar tornar o código mais linear:

Claro, há quem não goste disso, mas a essência é ceifar encadeamento abusivo.

And e Or

Não adianta, or é difícil de processar, tanto para o computador, quanto para a nossa cabeça. Lidar com os || do C# é complicado e fica ainda mais difícil quando a condição fica muito grande. Assim, se puder, migre seus Ors para Ands. Tente inverter a condição, pensar do outro lado ou usar alguma coisa mais complexa, como um array, pois além de tirar a condição literal do Or, ainda torna a condição mais flexível e reutilizável:

 

Concluindo…

É isso aí, estas são as coisas que eu acho que mais pegam no cotidiano do leitor de código e que eu, também como desenvolvedor, acabo usando como ferramenta de tortura com nomes e ifs (todos erramos na pressa). Enfim, o que se pode tirar disso é que um código é um texto e deve ser escrito como um “O pequeno príncipe” e não  “Senhor dos anéis” ou “Prolegômenos a toda metafísica futura”, pois seu objetivo é funcionar e ser mantido exigindo que seja o mais rápido de entender possível.

Até mais,

 

Do-it-youself & Manaus

Coisas aleatórias, Experiência do usuário 1 Reply

Olá, tudo bem?

Hoje vou falar um pouco de um artigo que participei da autoria e de uma experiência bacana: Apresentar num workshop em Manaus.Como?

Vista do Hotel Monaco

Vista do Hotel Monaco com o Rio negro e a floresta amazônica ao fundo.

Então, contextualizando, a Ana Carolina, eu e o nosso professor Ecivaldo Matos decidimos pegar nosso trabalho de conclusão e transformar em um artigo, pra submetermos à algum congresso, workshop ou algo assim.

Foi difícil, trabalhamos duro, mas escrevemos e fomos aceitos no WAIHCWS 2013, e vocês podem conferir aqui.

Nosso artigo teve um nome muito bizonho e longo, Técnicas de Avaliação de Usabilidade do Tipo Do-It Yourself e seus Impactos no Processo de Desenvolvimento de uma Rede Social na Web e foi sobre avaliações do tipo “Do-it-yourself” durante o processo de desenvolvimento da nossa rede social (que ainda está sendo maturada). No documento analisamos um pouco de como aplicamos algumas das técnicas de “faça você mesmo” para avaliação de experiência do usuário, que baseamos nas ideias de Steve Krug, com o intuito de fazer com que a interface do PetPatinhas (a rede social sendo maturada) fosse mais amigável.

Primeiro a gente questionou se valeria a pena fazer esse tipo de técnica, se serviria para nossa equipe, que não sabia quase nada desse assunto e depois a gente aplica 4 delas:

  1. Análise conceitual
  2. Lista de metas
  3. Teste Remoto
  4. Validação

Foi tudo meio que informal, bem descontraído, o usuário está ajudando a gente a conhecer melhor a nossa interface, seu comportamento, etc. A análise conceitual é mais um bate papo enquanto só tínhamos a ideia, enquanto o que foi mais complexo foi aplicar o teste de lista de metas e a validação, pois foram com a nossa interface já desenvolvida. Tivemos resultados muito bacanas.

Assim, pegamos esse conteúdo, que estava em um trabalho bem maior, e compusemos um artigo curto (6 páginas) e submetemos para revisão pelo pessoal do workshop. Nós fomos aprovados, revisamos o artigo e preparamos a apresentação.

Tivemos 10 minutos para apresentar tudo, a Ana e eu treinamos horas, desde as falas até o tempo de passar os slides, foi suadouro viu. Estudamos pacas e o professor ajudou muito. Ficamos discutindo bastante com ele alguns pontos sobre a apresentação, o que arrumar, o que corrigir, o que ajustar, pois tínhamos que passar a sensação de referência do artigo para pessoas que nem nos conheciam. Era algo totalmente novo afinal, estávamos acostumados a apresentar para pessoas conhecidas, curso, faculdade, mas demos conta do recado e espero ter passado bem a ideia para o pessoal que assistiu.

Foto do Teatro Amazonas

Lustre do Teatro Amazonas

Enfim, se puderem, deem uma olhada no conteúdo, eu achei bem bacana. Apresentamos, participamos de uma dinâmica, encaramos 38 graus em Manaus, horas de voo e um pouco do mercado de peixe. Valeu a pena, se puderem, ousem, nada como fazer o que se gosta em um lugar bizonho.

Até mais ^^

Horizontalização

Coisas aleatórias, Horizontalização Leave a reply

Olá, hoje vou falar sobre um assunto que não é da área da tecnologia, mas gosto muito de discutir: Gestão Horizontal.

Mas o que seria isso? Como isso aqui não é nenhum artigo acadêmico, me dou o direito de não citar fontes e deixar aqui conhecimentos e termos que eu costumo usar, se alguém discordar, ficarei feliz em ler o comentário, até pra ajudar a todos nós né… ^^.

Gestão horizontal seria um perfil administrativo de empresa em que não há uma figura de poder. Não estou dizendo que não há uma figura DECLARADA de poder, mas sim que, realmente não existe uma figura que esteja acima dos outros, ou hierarquia. Como ouvi em uma história uma vez, resumidamente:
“Se você pode me demitir, então você é meu chefe”

Simples assim, se existe alguma pessoa que pode decidir a contratação, a demissão ou tomar decisões sozinha, então ela tem mais poder que você e, nesse caso, não é horizontal.

Mas Octávio, então #comofaz? Eu vou colocar a minha visão como referência (Tipo desfile que veste modelos com abóboras para as outras pessoas pegarem o que é bacana para se inspirarem):

Na minha visão de gestão horizontal, toda tomada de decisão é feita em grupo, com toda equipe ou, em último caso, representantes, podendo ser definidos por unanimidade ou maioria inquestionável. O que isso quer dizer? Caso tenha um time com 20 pessoas e 18 decidam que 1 seja o representante, bom, isso é uma maioria inquestionável. Neste caso, esse 1 ou 2 ou quantos forem necessários, se juntam a vários uns e decide pelo grupo que representa. A definição de quantidade é proporcional à complexidade e importância da decisão, fazendo assim com que o grupo se responsabilize pelas manobras efetuadas pelo grupo.

Assim, basicamente, uma empresa horizontal é aquela em que os interessados e fornecedores tomam as decisões. Isto gera uma cadeia de iniciativa e respeito, fazendo com que os envolvidos participem ativamente em todo o processo de desenvolvimento de um serviço ou produto, fazendo com que a empresa tenha mais porcos do que galinhas.

Com esta forma de trabalho não existem setores, nem cargos, nem nada disso, apenas papéis e equipes. Uma pessoa assume um papel e se responsabiliza pelas coisas que estão atreladas à ela, desta maneira, a mocinha do RH não vai ser cobrada de trabalhos do programador .NET. Um papel é como um grupo de responsabilidades que as pessoas adotam por espontânea vontade ou por acordo. Você não vai atuar em um papel em que não irá se comprometer, portanto, seu trabalho vai ser o melhor que alguém no seu lugar faria e, ao mesmo tempo, não ficará amarrado, preso em obrigações exclusivas de um cargo.

Mas para quê? Sabe aquela situação chata de “isso não é comigo, é com fulano” ou “eu não fiz porque ciclano nao fez”? Acaba aí, você tem um papel com N responsabilidades, e elas são seu alvo, você é o dono delas, e todas devem ser respeitadas e cumpridas, se o fulano não ajudar, vá até o fulano e cobre, ou converse com ele e faça você mesmo, se ciclano não terminou, não importa, aqui não é eu ou você, em uma empresa horizontal, todos tem conhecimento do processo e interesse no sucesso do grupo, todos os comprometidos irão atuar de maneira que obtenham resultados.

A setorização gera a segregação, que faz com que grupos compitam entre si e pessoas tentem derrubar umas às outras e, eliminando isso, funciona como o seu corpo, todas as células são iguais quando nascem, daí vão se especializando e assumindo as responsabilidades que cabem a elas e com a seleção natural, algumas coisas mudam, outras não, mas estão todos fazendo parte de um corpo que, se falhar, todos morrem.

Mas Octávio, toda essa visão é tão utópica, é tão perfeito assim? Sim e não. Sim pois isso é possível, não pois irá gerar alguns agravantes como politicagem, já que o grupo define, aquele que for melhor em “sorrir e acenar” provavelmente irá se dar melhor, podem surgir influenciadores, pessoas fracas, pessoas querendo tomar o poder fingindo que respeitam, quando na verdade só estão assumindo pontos estratégicos para tomarem o poder. Mas tudo isso é inerente às relações sociais portanto, se houver realmente uma coesão no time, ou seja, todos sabem o motivo de estar ali, sabendo que se algo der certo, todos ganham e o oposto também, os políticos e manipuladores pouco a pouco serão mitigados.

Enfim, esse é meu primeiro ponto sobre horizontalização, espero que tenham gostado e que algo ajude em alguma coisa. Lembrem-se, quando você faz o que realmente gosta por um objetivo que acredita, sua vida passa a valer mais a pena.

Até mais,

REST e Estados

Boas práticas 1 Reply

Olá, primeiramente, o que é REST?

Basicamente é um acrônimo para Representative State Transfer, ou seja, uma forma de transferir uma representação de um determinado estado de uma aplicação. Vou explicar com OO pois é como me sinto mais confortável.

Pense em uma classe Pessoa. Ela tem Nome, Sexo e um boolean representando se ela está on-line ou não em um determinado sistema:

Quando instanciamos esta classe, obtemos um objeto que, neste caso, vou chamar de “josecrildo”, ficando da seguinte maneira:

Bom, o objeto josecrildo tem o estado determinado por suas propriedes. Podemos dizer que ele está on-line e tem sexo masculino e nome Josecrildo. Se mudarmos EstaOnline para false, temos outro estado para Josecrildo, pegou a pegada?

Assim, serviços REST foram pensados para transferir representações de estado, através de tecnologias simples, como o protocolo HTTP e pacotes de texto, ao contrário das práticas de serviços SOAP, no qual a complexidade é muito maior. Enquanto neste último é necessário definir um contrato, configurações, eventualmente protocolos específicos e uma certa burocracia, o REST utiliza apenas os mesmos princípios da exibição de páginas web.

Por consequência, um cliente do serviço que irá consumir objetos gerados à partir da classe Pessoa, fará requisições ao servidor, que retornará o conteúdo, normalmente, em função do método. Por ex:

PESSOA -> http://aplicacao/Pessoa

GET /Pessoa -> retorna uma lista de pessoas

GET /Pessoa/:id -> retorna um objeto de pessoas específica de acordo com :id (/Pessoa/10)

POST /Pessoa -> cria um novo objeto de pessoa

PUT /Pessoa/ -> substitui pessoa por outro objeto de pessoa

PATCH /Pessoa/:id -> altera o objeto de pessoa com :id

DELETE /Pessoa/:id -> exclui o objeto de pessoa com :id

OPTIONS /Pessoa -> lista os métodos disponíveis para /Pessoa

O produto resultante dessas requisições pode variar de acordo com o content-type ou ser fixo e, como resposta, o cliente irá receber o conteúdo em formato texto, representando o estado citado acima:

 

Enfim, todo sistema possui estados, que são os valores atuais de seus atributos ou propriedades e eles podem ser representados em modo texto. REST trata de transferir estes estados através de requisições HTTP, permitindo prover serviços simples e de fácil consumo.

Até mais,

Classes em Javascript – Declaração

Boas práticas, Javascript 1 Reply

Quando eu falo classes, na verdade quero dizer “tipo classes”. O javascript é uma linguagem orientada a objetos, porém, baseia-se no princípio prototípico, no qual a herança é, na verdade, uma extensão de um protótipo original e trabalhamos diretamente com os objetos baseados nestes.

Existem diversos frameworks que possibilitam a utilização de classes no modelo padrão, porém, não focarei neles, apenas mostrando, aqui, como ficaria uma classe no modelo básico de protótipos.

Primeiramente, devemos compreender que OO baseia-se em alguns princípios:

  • Encapsulamento
  • Herança
  • Polimorfismo

No caso de linguagens OO difundidas como C# ou Java, temos a declaração de classes e tudo está organizado bonitinho apenas para ser utilizado, porém,  no javascript 1.7-1.8, as coisas são meio diferentes e a utilização é um pouco mais complicada (Irá melhorar nas próximas versões). Basicamente, para criarmos uma estrutura de classes devemos trabalhar com closures, da seguinte maneira:

Bom, nesta declaração, vemos que a estrutura formada é semelhante à classes, com encapsulamento no fechamento de variáveis e funções.

A herança está em dizer que o protótipo do filho é o mesmo que o protótipo do pai, criando uma especialização do pai no filho.

Já o polimorfismo não é muito “necessário”, já que o javascript tem tipagem dinâmica e fraca e podemos utilizar objetos e métodos em vários pontos, mas claro, poderia ser implementado através de algumas coisas um pouco mais complicadas que não vou falara agora, pra não perder a graça.

Para usar o código resultante, devemos instanciar um objeto da classe acima através do new e, por isso, é melhor colocar a primeira letra maiúscula nas classes pois, se você não usar o new para chamar uma classe, this passa a pertencer ao escopo acima, gerando o caos.

Enfim, é desta maneira que criamos, diretamente, classes em javascript, lembrando que as principais vantagens desta prática são a de não sujar o escopo global, deixando fechado em um objeto todos os métodos específicos de uma atividade, tendo um código mais limpo e organizado.

Até mais

Entides Html

Coisas aleatórias, HTML, Javascript 1 Reply

Olá,

Há algum tempo (muito), eu estava procurando os simpáticos símbolos de entidades HTML para deixar meu site um pouco mais lúdico e acabei criando uma ferramenta para listar todos os caracteres HTML, com sua forma de escrita.

Utiliza-se o &#..; como entidade HTML, jogando direto no fonte, ou \.. para apresentar via javascript em alerts ou confirms.

https://github.com/octavioturra/HTMLEntityGen

Dêem uma olhada e qualquer coisa, [amq_modal]podem perguntar[/amq_modal]

Até mais

Herança com C# e Entity (Code First)

C# 7 Replies

Olá novamente,

Desta vez decidi falar sobre algo que achei bem bacana e útil para o dia-a-dia: Herança com Entity.

Comumente utilizo uma tabela de abstração para Entidades de sistema e Objetos de valor. Todas as minhas tabelas são de um destes dois tipos, assim, não tenho que ficar replicando as propriedades:

Neste caso, quando eu tiver uma classe que representa uma entidade no banco, irei sempre herdar de um destes dois modelos, permitindo, assim, generalizar a utilização. Bom, para seguir este perfil, devemos mapear nossa coleção em função da classe filho, ou seja, da entidade que representa a “tabela”:

Quando a migração for efetuada, o banco refletirá a entidade User, com suas propriedades, adicionadas das propriedades de AppEntity.

Outra forma de se trabalhar é fazendo o mapeamento da maneira oposta, por exemplo, quando temos uma entidade Profile e uma especificação, como CustomerProfile. Seguindo esta lógica, a regra de negócio está voltada para Profile e CustomerProfile é apenas um desdobramento e queremos refletir isto no desenvolvimento:

Utilizando esta forma, quando o migrations gerar o banco de dados, ele criará a tabela Profiles, com uma coluna adicionada chamada Discriminator, que conterá o nome da especialização que foi adicionada.

Após este processo, a utilização do código resultante fica um pouco diferente do comum, pois a especialização CustomerProfile deverá ser acessada, para consulta, através da coleção Profiles, com o auxílio do método OfType, já a inclusão permanecerá inalterada, assim:

Assim, customerProfiles será do tipo List<CustomerProfile> e a consulta Where poderá tratar seus parâmetros de acordo com a classe CustomerProfiles.

Enfim, a herança é sempre muito bem vinda quando queremos reduzir o acoplamento do código e generalizar melhor nossas abstrações, permitindo uma melhor manutenção do nosso código e facilitando o trabalho. Lembrando que, quando estas técnicas forem utilizadas, as classes devem ter nomes que remetam à sua função, facilitando a compreensão da estrutura aplicada.

Até mais,

 

Closures em C#

C# 1 Reply

!!! Não considerem uma boa prática, utilizem a caráter de conhecimento !!!

Uma coisa bacana é o conceito de closures, em outras linguagens, que nada mais é do que conter uma função dentro de outra, fazendo seu fechamento para o escopo externo. Em javascript é uma prática comum, como no pedaço abaixo:

Neste código, utilizamos esta prática para isolar o nosso código do escopo externo, garantindo não “sujar” o ambiente com funções jogadas e garantir que “$” seja um alias para o jQuery, que pode até ser substituído por uma biblioteca alternativa, como o Zepto, por exemplo.

No caso do C#, podemos fazer algo muito parecido, declarando funções dentro dos métodos, utilizando 2 modelos:

  • Action -> função que recebe um parâmetro e não retorna nada;
  • Func -> função que recebe N parâmetros e retorna 1 valor;

Bom, começando pela Action, ela pode ser útil para alterar um objeto, lembrando que eles são sempre passados como referência e que, neste caso, sua modificação dentro da nossa função seria reproduzida externamente. O código ficaria assim:

Vemos que, neste caso, “modificaTeste” serve apenas para alterar o valor interno de teste.

Já no outro perfil, temos Func<>, que é, particularmente, muito mais divertido. Com ele, trabalhamos pensando que a última definição é sempre o tipo de retorno, portanto Func<int, string> receberá um int e retornará uma string, enquanto Func<int> não receberá parâmetros, retornando apenas um int. Vejamos o código como fica:

“eMaiorDeIdade” poderá ser utilizada em todo escopo da função que for declarada e executará sua atividade normalmente.

Mas para que utilizar isto?

Eu, particularmente utilizo este tipo de truque quando meu método reutiliza muito uma ação que não precisa ser declarado na classe, ou, mais comumente, quando minha view precisa MUITO (veja bem, muito mesmo) de uma execução bem específica e não será reutilizada afora, declaro minhas funções e utilizo com o Razor.

Bom, desta maneira é possível declarar funções dentro de funções e as mesmas estarem fechadas para o escopo externo, deixando claro que o uso é bem específico e se alguém for utilizar, lembre com carinho do resto da equipe.

Até mais,

Interfaces e desacoplamento

Boas práticas 2 Replies

Olá, vamos falar um pouco de desacoplamento do código através do uso de interfaces, afinal, o acoplamento significa uma grande interdependência de código que pode causar danos na aplicação durante o processo de manutenção ou, até mesmo, quando criamos novas funcionalidades.

Mas o que é isso?

Pense que, quando você escreve uma classe e referencia, ela pode seguir o que está escrito no livro do Uncle Bob:

“Converse com amigos não com estranhos”

Devemos pensar que seus métodos podem conhecer as propriedades de seus pais e de seus amigos e, seus amigos, devem lhe ser apresentado, no nosso caso, através do contrutor e nada mais do que isso.

Quando você trabalha com desacoplamento, há conceitos para melhorar a arquitetura da aplicação, como a inversão de controle onde, as classes recebem em seus construtores o que vai ser pertinente às referências “estrangeiras”, como parâmetros e, portanto, conhecerá, exclusivamente, os métodos disponíveis nas interfaces injetadas. Ex.:

Vemos que, neste caso, não importa quem seja MusicPlayer, sabemos que ele possui o método Play() e que este retorna void.

Como fazemos então?

Estamos acostumados a trabalhar com referências diretas das classes que utilizamos e, neste caso, acabemos correndo o risco de modificar alguma coisa e tudo virar um caos. Portanto, utilizando a inversão de controle, a classe conhecerá apenas a interface pertinente á sua regra de negócio:

Depois disto, criamos nossa classe baseada na nossa interface e implementamos seus métodos:

Agora, sabemos que UserManager pode ser utilizado em qualquer lugar que utilize IUserManager e, neste caso, expõe à seus amigos a sua interface e permite sua utilização. Perceba que o DummyMethod não poderá ser utilizado enquanto não fizer parte de uma interface, já que ele não está assinado em IUserManager.

AnyClass pode ter acesso à todos os métodos de userManager que estejam destritos e, caso seja necessário dar manutenção em nosso código, enquanto a interface for respeitada, o funcionamento da aplicação estará intacto e estaremos felizes por mais tempo.

Concluindo

A utilização de interfaces no desacoplamento permite ao desenvolvedor codificar pensando apenas no que é pertinente à regra de negócio e garante que, enquanto as interfaces estiverem sendo respeitadas, o código de suas implementações poderá mudar e a aplicação continuará funcionando. Enfim, não devemos nos esquecer que, neste ponto, paramos de pensar nas classes  e seu código, mas devemos analisar bem as nossas interfaces.

Obs. Para a devida implantação da inversão de controle em um ambiente produtivo, podemos utilizar diversas ferramentas que criam e gerenciam os contextos da aplicação, injetando e controlando todas as interfaces e suas instâncias.

Até mais,