Monthly Archives: setembro 2013

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,

Ahoj, vitejte, jsem T|Octavio

Coisas aleatórias 1 Reply

Olá, sou T|Octávio.

Demorei anos para criar ânimo para escrever e vou dizer que terei que levar no ritmo de “só por hoje”, pois, para mim, é muito difícil ficar escrevendo hahaha.

Sou desenvolvedor .NET, apaixonado por programação, tecnologia e, é claro, novas práticas e ideias.

Inicialmente este blog conterá posts sobre programação, pois é a área que mais tenho vivido, pelos meus hobbies e pela minha vida profissional. Gosto de linguagens e suas reentrâncias, portanto, falarei um pouco de cada coisa que me apetece.

Ontem estava divagando e montei uma pequena tabela:

Funcional Especifica OOOO OOO OO
Rust R Coffeescript Groovy C#
Haskell Prolog Moonscript Python VB.Net
Erlang Ruby Java
F# Javascript PHP5
Clojure Lua
Scheme Dart

Nela tem todas as linguagens que acho interessantes, às vezes não para mim, talvez não para os outros, mas eu, particularmente, lido mais com as que estão em negrito, portanto, se alguém quiser conversar um pouquinho sobre elas ou falar sobre as outras, ficarei imensamente grato.

Até mais,