Monthly Archives: setembro 2013

Classes em Javascript – Declaração

Octavio Turra setembro 29, 2013 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:

var MinhaClasse = (function(){
    var atributo_privado;

    function MinhaClasse(){};

    //Herança básica
    MinhaClasse.prototype = ClassePai.prototype;

    var metodoPrivado = function(){}

    MinhaClasse.prototype.metodoPublico = function(){};

    return MinhaClasse();
})();

var MinhaClasse = (function(){

var atributo_privado;

function MinhaClasse(){};

//Herança básica

MinhaClasse.prototype = ClassePai.prototype;

var metodoPrivado = function(){}

MinhaClasse.prototype.metodoPublico = function(){};

return MinhaClasse();

})();

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.

var minhaClasse = new MinhaClasse();

1	var minhaClasse = new MinhaClasse();

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

Octavio Turra setembro 24, 2013 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)

Octavio Turra setembro 23, 2013 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:

public class AppEntity<KeyType>{
  	public SystemEntity(){
  	Active = true;
  	CreationDate = DateTime.Now;
  	}

	 [Key]
  	[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
  	public KeyType Id{get;set;}

  	[DataType.DateTime]
  	public DateTime CreationDate{get;set;}

  	public bool Active{get;set;}
}

public class ValueObject<KeyType>{
 	[Key]
	[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
  	public KeyType Id{get;set;}
}

public class AppEntity<KeyType>{

public SystemEntity(){

Active = true;

CreationDate = DateTime.Now;

}

[Key]

[DatabaseGenerated(DatabaseGeneratedOption.Identity)]

public KeyType Id{get;set;}

[DataType.DateTime]

public DateTime CreationDate{get;set;}

public bool Active{get;set;}

}

public class ValueObject<KeyType>{

[Key]

[DatabaseGenerated(DatabaseGeneratedOption.Identity)]

public KeyType Id{get;set;}

}

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”:

public class User : AppEntity<int>{
	[StringLength(256)]
	[DataType(DataType.EmailAddress)]
	public string Email{get;set;}

	[StringLength(64)]
	[DataType(DataType.Password)]
	[MinLenght(6)]
	public string Password {get;set;}
}
//Na declaração do context
public DbSet<User> Users{get;set;}

public class User : AppEntity<int>{

[StringLength(256)]

[DataType(DataType.EmailAddress)]

public string Email{get;set;}

[StringLength(64)]

[DataType(DataType.Password)]

[MinLenght(6)]

public string Password {get;set;}

}

//Na declaração do context

public DbSet<User> Users{get;set;}

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:

public class Profile : AppEntity<int>{
	[StringLength(64)]
	public string Description{get;set;}

	[DataType(DataType.Url)]
	public string HomeUrl{get;set;}
}

public class CustomerProfile : Profile{
	public CustomerProfile{
		Carts = new HashSet<Cart>();	
	}

	public virtual ICollection<Cart> Carts{get;set;}
}

//Na declaração de context
public DbSet<Profile> Profiles{get;set;}

public class Profile : AppEntity<int>{

[StringLength(64)]

public string Description{get;set;}

[DataType(DataType.Url)]

public string HomeUrl{get;set;}

}

public class CustomerProfile : Profile{

public CustomerProfile{

Carts = new HashSet<Cart>();

}

public virtual ICollection<Cart> Carts{get;set;}

}

//Na declaração de context

public DbSet<Profile> Profiles{get;set;}

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:

//Inclusão de novos CustomerProfile
db.Profiles.Add(new CustomerProfile...);

//Consulta de CustomerProfiles
var customerProfiles = db.Profiles.OfType<CustomerProfile>.Where(...).ToList();

//Inclusão de novos CustomerProfile

db.Profiles.Add(new CustomerProfile...);

//Consulta de CustomerProfiles

var customerProfiles = db.Profiles.OfType<CustomerProfile>.Where(...).ToList();

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#

Octavio Turra setembro 22, 2013 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:

var main = (function($){
   var fazAlgumaCoisa = function(){
      //O código aqui de dentro bem como esta função estão escondidos para o escopo externo
   }
})(jQuery);

var main = (function($){

var fazAlgumaCoisa = function(){

//O código aqui de dentro bem como esta função estão escondidos para o escopo externo

}

})(jQuery);

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:

public class Test
{
	public class Teste{
		public int Valor{ get; set; }	
	}
	public static void Main()
	{
		var teste = new Teste();

		Action<Teste> modificaTeste = (t)=>{
			t.Valor = 10;
		};

		modificaTeste(teste);

		Console.Write(teste.Valor);
	}
}

public class Test

{

public class Teste{

public int Valor{ get; set; }

}

public static void Main()

{

var teste = new Teste();

Action<Teste> modificaTeste = (t)=>{

t.Valor = 10;

};

modificaTeste(teste);

Console.Write(teste.Valor);

}

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:

Func<int, bool> eMaiorDeIdade = (idade)=>{
			if(idade>=10){
				return true;
			}
			return false;
		}

Func<int, bool> eMaiorDeIdade = (idade)=>{

if(idade>=10){

return true;

}

return false;

}

“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

Octavio Turra setembro 21, 2013 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.:

public interface IMusicPlayer{
   void Play();
}

public class MusicPlayer : IMusicPlayer{
   public void Play(){
     ...
   }
}

public class AnyApp{
   public IMusicPlayer musicPlayer;
   ...
   public void AnyMethod(){
      musicPlayer.Play();
   }
}

public interface IMusicPlayer{

void Play();

}

public class MusicPlayer : IMusicPlayer{

public void Play(){

...

}

public class AnyApp{

public IMusicPlayer musicPlayer;

...

public void AnyMethod(){

musicPlayer.Play();

}

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:

public interface IUserManager{
  ICollection<User> Get();
  User Get(int id);
  void Create(User user);
  void Update(User user);
  void Remove(int id);
}

public interface IUserManager{

ICollection<User> Get();

User Get(int id);

void Create(User user);

void Update(User user);

void Remove(int id);

}

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

public class UserManager : IUserManager{
  public ICollection<User> Get(){...}
  public User Get(int id){...}
  public void Create(User user){...}
  public void Update(User user){...}
  public void Remove(int id){...}

  public void DummyMethod(User user){...}
}

public class UserManager : IUserManager{

public ICollection<User> Get(){...}

public User Get(int id){...}

public void Create(User user){...}

public void Update(User user){...}

public void Remove(int id){...}

public void DummyMethod(User user){...}

}

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.

public class AnyClass{
   private IUserManager userManager;

   public AnyClass(IUserManager userManager){
     this.userManager = userManager;
   }
   ...
}
----
var userManager = new UserManager();
var anyClass = AnyClass(userManager);

public class AnyClass{

private IUserManager userManager;

public AnyClass(IUserManager userManager){

this.userManager = userManager;

}

...

}

----

var userManager = new UserManager();

var anyClass = AnyClass(userManager);

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

Octavio Turra setembro 21, 2013 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,