As aplicações podem obter essas configurações de duas formas:

1. Machine.config – que pode ser acessado por todos as aplicações .NET.
   Caminho do arquivo: %Windir%\Microsoft.NET\Framework\v2.0.50727\Config\Machine.config
2. application-specific.config – pode ser um app.config para desktop application ou web.config para web application.

Pelo fato de impactar em todas as aplicação .NET da máquina, o arquivo Machine.config é dificilmente modificado. A melhor solução é a utilização do application-specific.config, com essa alternativa definimos configurações específicas e unicamente para a aplicação que estamos trabalhando.
A seguir apresentarei as principais funcionalidades do pacote System.Configuration.

Uma das utilizações mais simples do arquivo de configuração é o AppSettings, nela os dados são gravados na estrutura de chave-valor.

AppSettings permite gerenciar uma coleção do tipo NameValueCollection.

Escrevendo Configurações no Application Configuration

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings.Add("MyKey", "MyValue");
config.Save(ConfigurationSaveMode.Modified);

Após a execução do código o arquivo de configuração será modificado da seguinte forma para conter a chave-valor conforme abaixo:

< ?xml version="1.0" encoding="utf-8"?>
<configuration>
   <appsettings>
      <add key="MyKey" value="MyValue" />
   </appsettings>
</configuration>

Dica: Sempre verifique o arquivo de configuração do executável da aplicação. As alterações não são refletidas no arquivo de configuração do código fonte.

Lendo configurações do Application Configuration

Abaixo o arquivo de configuração contem duas chaves (MyKey e Greeting).

< ?xml version="1.0" encoding="utf-8"?>
<configuration>
   <appsettings>
      <add key="MyKey" value="MyValue" />
      <add key="Greeting" value="Hello, world!" />
   </appsettings>
</configuration>

O código a seguir mostra todas as configurações de chave-valor contido no arquivo de configuração.

for (int i = 0; i < ConfigurationManager.AppSettings.Count; i++)
{
   Console.WriteLine("{0}: {1}",
   ConfigurationManager.AppSettings.AllKeys[i],
   ConfigurationManager.AppSettings[i]);
}

Para acessar uma informação, campo value de uma determinada chave (key), podemos proceder da seguinte forma:

Console.WriteLine(ConfigurationManager.AppSettings["Greeting"]);

Utilizando Connection Strings

Para acessar strings de conexão, use a coleção estática ConfigurationManager.ConnectionStrings, o retorno dessa propriedade é um ConnectionStringSettingsCollection.
As três propriedades mais utilizadas da classe Connection-StringSettings são:

• Name - que define o nome da conexão.
• Provider-Name - que define de tipo da conexão com a base de dados.
• ConnectionString - que define como o cliente se conecta com o servidor.

O elemento connectionStrings agrupa as informações de conexão do sistema. Um arquivo de configuração pode contar diversos definições de conexão.

<connectionstrings>
   <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS; Integrated Security=SSPI; AttachDBFilename=|DataDirectory|aspnetdb.mdf; User Instance=true" providerName="System.Data.SqlClient" />
</connectionstrings>

O código a seguir mostra todas as strings de conexão contido no arquivo de configuração.

ConnectionStringSettingsCollection connections = ConfigurationManager.ConnectionStrings;
foreach (ConnectionStringSettings connection in connections)
{
   Console.WriteLine("Name: {0}", connection.Name);
   Console.WriteLine("Connection string: {0}", connection.ConnectionString);
   Console.WriteLine("Provider: {0}", connection.ProviderName);
   Console.WriteLine("Source: {0}", connection.ElementInformation.Source);
}

Para acessar informações de uma conexão especifica, podemos proceder da seguinte forma:

Console.WriteLine(ConfigurationManager.ConnectionStrings["LocalSqlServer"].ConnectionString);

Lendo configurações do Machine Configuration

Como mencionsado, dificilmente iremos manipular um Machine.config. Porem caso se faça necessário, o código a seguir cria o objeto Configuration que representa o arquivo Machine.config.

   Configuration machineSettings = ConfigurationManager.OpenMachineConfiguration();
   ProtectedConfigurationSection pcs = (ProtectedConfigurationSection)machineSettings.GetSection("configProtectedData");
   Console.WriteLine(pcs.DefaultProvider);
   Console.WriteLine(pcs.Providers["DataProtectionConfigurationProvider"].Parameters["description"]);

Seção customizada - Custom Sections

Definições de configurações de aplicação customizados, podem ser criadas de 2 formas. Implementando inteface IConfigurationSectionHandler ou derivando uma classe de ConfigurationSection.
A segunda opção é recomentada para versões 2.0 ou anteriores, pore esse motivo vou apresentar somente como realizar a primeira implementação pois se aplica a versões mais recentes do Framework.NET.

Criando uma seção Customizado utilizando IConfigurationSectionHandler

Devemos criar uma única classe para a seção customizada na aplicação, essa classe deve implementar a interface IConfigurationSectionHandler.
Implementando a interface, devemos criar um construtor vazio e implementar o método Create. Dos três parâmetros requiridos pelo método, normalmente utilizaremos omente o terceiro, um objeto do tipo System.Xml.XmlNode que contem os dados armazenados no arquivo xml contendo os dados da seção customizada.

Demonstração de como estruturar a seção de configuração customizada no arquivo .config.

<configuration>
   <configsections>
      <section name="customSettings" type="ConfigApp.CustomConfigHandler, ConfigApp"/>
   </configsections>
   <appsettings>
      <add key="Greeting" value="Hello, world!" />
      <add key="Another Key" value="Another value" />
   </appsettings>
   <customsettings>
      <lastuser>Tony</lastuser>
      <lastnumber>32</lastnumber>
   </customsettings>
</configuration>
 
Abaixo o código que permite acessar a seção customizada.

public class MySettings
{
   public string lastUser;
   public int lastNumber;
   public MySettings() { }
}
 
public class CustomConfigHandler : IConfigurationSectionHandler
{
   public CustomConfigHandler() { }
 
   public object Create(object parent, object configContext, System.Xml.XmlNode section)
   {
      MySettings settings = new MySettings();				
      settings.lastUser = section.SelectSingleNode("lastUser").InnerText;
      settings.lastNumber = int.Parse(section.SelectSingleNode("lastNumber").InnerText);
 
      return settings;
   }
}
 
public class Program
{
   public static void Main(string[] args)
   {
      MySettings settings = (MySettings)ConfigurationManager.GetSection("customSettings");
 
      Console.WriteLine(settings.lastUser);
      Console.WriteLine(settings.lastNumber);
   }
}

Observe no arquivo de configuração a seção <configsections>, que declara uma seção customizada e informa se noma na propriedade de name e do método que implementa IConfigurationSectionHandler e o nome do assembly na propriedade type.
Então, podemos criar uma seção de configuração customizada, com elementos para cada valor personalizado.

O método CustomConfigHandler.Create irá ler os valores da sessão customizada e atribuir a uma classe de dados que irá retornar os dados de forma tipada.

A seção <appsettings> está incluído apenas para demonstrar que um arquivo. Config pode conter configurações personalizadas e configurações de aplicativos padrão.

Enjoy

Links: Oracle – Code Conventions

Se você esta se perguntando porque utilizar convenção de código, segue um trecho traduzido:

1. 80% do custo de vida de um componente de software é com manutenção.
2. Dificilmente um software será mantido por seu autor original.
3. Convenções de código melhoram a legibilidade do software, permitindo entendimento mais rápido e claramente.
4. Se enviar o código-fonte como produto, você precisa ter certeza de que esta empacotado e limpo como qualquer outro produto criado.

Até mais

XML Correto

<elemento atributo='Stacem'>Formula matemática do item</elemento>

XML corrompido

<elemento atributo='St'acem'>Valor de X > que valor de Y.</elemento>

Para resolver esse problema, devesse utilizar em campos de informações (valores dos elementos ou atributos) um “encode” para esses caracteres.

Encode XML

Basicamente são 5 valores:

No Framework.NET existem alguns caminhos de aplicar o encode XML:

1. string.Replace()
A maneira mais feia, mas que funciona, seria utilizar o famoso string.Replace().
Repetindo a rotina 5 vezes, uma para cada caracter especial.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = text.Replace("&", "&amp;").Replace("< ", "&lt;").Replace(">", "&gt;").Replace("\"", "&quot;").Replace("'", "&apos;");
// RESULT: Este é um &quot;nó&quot; XML com caracteres &apos;especiais&apos; &amp; &lt;&gt; diferente de tudo!!

2. System.Web.HttpUtility.HtmlEncode()
É utilizado para codificar textos em HTML, muito utilizado em ASP.NET, porem ele não codifica o apóstrofo e força você utilizar uma referência de pacote Web. Se for uma aplicação desktop, não recomendo sua utilização.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = HttpUtility.HtmlEncode(text);
// RESULT: Este é um &quot;nó&quot; XML com caracteres 'especiais' &amp; &lt;&gt; diferente de tudo!!

3. System.Security.SecurityElement.Escape()
Outra maneiroa é utilizar o comando Escape() que trata os 5 caracteres especiais.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = System.Security.SecurityElement.Escape(text);
// RESULT: Este é um &quot;nó&quot; XML com caracteres &apos;especiais&apos; &amp; &lt;&gt; diferente de tudo!!

Gosto muito da opção de codificar com System.Security.SecurityElement.Escape(), acredito que seja a forma mais estética com relação ao código.
Não sei quanto a desempenho das formas, mas manipulação de string não é a melhor das escolhas.
E a segunda alem de não abranger todos os caracteres especiais, ainda fica limitada a aplicações web.

Espero ter ajudado

O Framework .NET possui o objeto Thread que permite mais flexibilidade e gerenciamento sobre as thread executadas em background do que o objeto ThreadPool.

Thread Priority
Uma das propriedades do objeto Thread á sua prioridade. Após a thread criada, mas antes de iniciar a thread, podemos definir a prioridade da thread com propriedade Thread.Priority usando o enumerador ThreadPriority.
A Thread priority controla como o sistema operacional irá agendar o tempo para a execução da Thread. Geralmente threads com maior prioridade rodam antes das threads com baixo prioridades, por padrão as threads tem o valor de prioridade definida como Normal.

Thread State
Outra propriedade do objeto é Thread.ThreadState pode ser utilizada para verificar o estado das threads em background.
Os estados possíveis são:

• Unstarted: estado inicial da thread (antes de executar o método Thread.Start).
• Running: estado ativo ou executando (após de executar o método Thread.Start).
• Stopped: estado parada.
• WaitSleepJoin: estado esperando outra thread completar.
• SuspendRequested: estado repondendo solicitanção de pausa.
• Suspended: estado suspensa.
• AbortRequested: estado respondendo a solicitanção de abandono.
• Aborted: estado abortado.

Thread com parâmetros e retorno em C#

Para fornecer parâmetros para uma thread, criamos uma classe com um construtor que recebe um ou mais parâmetros e armazena o dado e a usa para criar o objeto ThreadStart.
Para obter o retorno da Thread, criamos um método que recebe o resultado de retorno como uma parâmetro. Depois criamos um delegate para o método e passamos o delegado e próprio método como parâmetro para a classe.

using System;
using System.Threading;
 
namespace ManagerThread
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Calculator calculator = new Calculator("Multiplicador", 15, ResultCallback);
 
            Thread thread = new Thread(calculator.Execute);
            thread.Start();
 
            Console.WriteLine("Main Thread aguarda finalização das threads em background.");
            thread.Join();
            Console.WriteLine("Thread completada.");
            Console.ReadKey();
        }
 
        public static void ResultCallback(int value)
        {
            Console.WriteLine("Resultado: {0}", value);
        }
    }
 
    public class Calculator
    {
        // Delegate que define a assinatura do método de callback (retorno).
        public delegate void ResultDelegate(int value);
 
        private readonly ResultDelegate callback;
        private readonly string message;
        private readonly int value;
 
        public Calculator(string message, int value, ResultDelegate callback)
        {
            this.message = message;
            this.value = value;
            this.callback = callback;
        }
 
        public void Execute()
        {
            Console.WriteLine(message);
 
            if (callback != null)
            {
                callback(value*2);
            }
        }
    }
}

A thread é executada somente após o comando thread.Start(). O comando thread.Join() força a thread principal a ficar aguardando a finalização da thread em background para seguir o processo.

Observações:
Threads podem estar em mais de 1 estado ao mesmo tempo.
Os métodos Thread.Suspend e Thread.Resume são utilizados para pausar e retornar a thread principal. Porem estes métos esta depreciados, e podem causar problemas de execuação, utilize o método Thread.Abort().

Enjoy

No mundo o IE assume o primeiro lugar com 37%, em segundo o Google Chrome com 27%, em terceiro o Firefox com 24%, o Safari com 6% e os outros com 6%.

No mercado brasileiro o Google Chrome é preferência por 43%, em segundo lugar o IE com 32%, em terceiro o Firefox com 22% e os demais browsers ficam com 3%.

Aqui neste site o Google Chrome segue a liderança com 54,47%, o Firefox sobe para segundo com 27,85% e IE cai para terceiro com 14,23%.

Com base nesses dados chego a algumas conclusões:

• Mesmo com todo esforço da Microsoft, o IE nos próximo meses vai perder a hegemonia no mundo.
• O Safari aparentemente começa a crescer, parte por ser mais barato em país outros países (como USA) e outra parte pelos Ipad, Iphone e afins. Apesar de no Brasil ser muito baixo ainda.
• Infelizmente o Firefox esta caindo também. É um excelente browser, mas acho que tem ficado pesado em relação ao Google Chrome, e talvez este seja um dos motivo.
• 82,32% das pessoas que acessam esse site usam Google Chrome ou Firefox, isso quer dizer que, quase ninguém tem dinheiro para Mac (isso foi uma brincadeira rsrsrs ).

Lembre-se: “As estatísticas não mentem…”

Se o computar tem múltiplos processos ou múltiplos núcleos em um único processador, ele pode executar várias threads simultâneas (multithreaded), mesmo que ambos exijam tempo de processamento. Dessa forma podemos adquirir um melhor desempenho da aplicação e melhorar a usabilidade do usuário final.

Definição

Uma linha (em inglês: Thread) ou encadeamento de execução é uma unidade de execução em um processo. Um simples processo pode ter várias threads, no caso este é referido com multithreaded, e em outras palavras, é uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser executadas concorrentemente.
O suporte à thread é fornecido pelo próprio sistema operativo (SO), no caso da linha de execução ao nível do núcleo KLT (Kernel-Level Thread), ou implementada através de uma biblioteca de uma determinada linguagem, no caso de uma ULT (User-Level Thread).

Vantagens

1. Executar diversas tarefas simultaneas.
2. Permitir que aplicação responda (não trave) a solicitações do usuário quando executar processos com longo tempo de processamento.
3. Melhor desempenho em computadores com múltiplos processamentos ou núcleos.

Desvantagens

1. Código de multithreaded é mais complexo.
2. Maior consumo de memória e processamento, podendo reduzir o desempenho em algumas circunstâncias.

Tipos de Thread

As threads podem ser de dois tipos:

• Foreground: thread da aplicação principal. Enquando estiver ativa a aplicação continua rodando. As thread de background serão finalizadas se a thread de foreground for finalizada.
• Background: Qualquer thread que foi inicializada por outra thread.

Exemplificando

Uma das formas mais fáceis de programar multithreaded em .NET é utilizando a classe ThreadPool.

namespace Threading
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Start call multiple times
            Console.WriteLine("Call multiple times.");
            ThreadPool.QueueUserWorkItem(ThreadProc);
            ThreadPool.QueueUserWorkItem(ThreadProc2, "Thread 1");
            ThreadPool.QueueUserWorkItem(ThreadProc2, "Thread 2");
            //Execute foreground
            ThreadProc2("Thread 2.5");
            ThreadPool.QueueUserWorkItem(ThreadProc2, "Thread 3");
            ThreadPool.QueueUserWorkItem(ThreadProc2, "Thread 4");
            Console.WriteLine("Main thread sleeps.");
            Thread.Sleep(1000);
            Console.WriteLine("End call multiple times.");
            Console.WriteLine();
        }
 
        public static void ThreadProc(object state)
        {
            Console.WriteLine("Thread without parameters.");
        }
 
        public static void ThreadProc2(object stateInfo)
        {
            string state = (string) stateInfo;
            Console.WriteLine("Thread: {0}", state);
            Console.WriteLine("Is Background: {0}", Thread.CurrentThread.IsBackground);
        }
     }
}

Para determinar se um thread é foreground ou background podemos utilizar a propriedade Thread.CurrentThread.IsBackground.

Nesse exemplo note que no método ThreadProc temos o object state como parâmetro do método, mas a chamada ao método não utiliza parâmetro.
Obrigatoriamente a assinatura do método esperado por QueueUserWorkItem deve ter um object como parâmetro, porem este é opcional.

Repare que utilizamos o comando Thread.Sleep(1000) para a thread principal aguardar a execução das threads em paralelo. Se comentarmos essa linha threads que estão em execução em background serão abortadas automaticamente.

Para podemos visualizar melhor a melhora de desempenho que podemos obter, criei o seguinte exemplo:

namespace Threading
{
    public class Program
    {
        public static void Main(string[] args)
        {
            List<string> urls = new List</string><string>();
            urls.Add(@"http://sylverio.com.br/blog/2009/08/requisicao-http-com-java-application-parte-1/");
            urls.Add(@"http://sylverio.com.br/blog/2009/09/requisicao-http-com-java-application-parte-2/");
 
            Console.WriteLine("Start time foreground: {0}", DateTime.Now.ToString("HH:mm:ss"));
            foreach (string url in urls)
            {
                GetPage(url);
            }
            Console.WriteLine("End time foreground: {0}", DateTime.Now.ToString("HH:mm:ss"));
 
            Thread.Sleep(20000);
        }
 
        private static void GetPage(object data)
        {
            string url = (string) data;
            Console.WriteLine("Start time background: {0}", DateTime.Now.ToString("HH:mm:ss"));
 
            WebResponse wr = WebRequest.Create(url).GetResponse();
            if (wr != null)
            {
                Console.WriteLine("{0}: {1}", url, wr.Headers["Content-Length"]);
                wr.Close();
            }
 
            Console.WriteLine("End time background: {0}", DateTime.Now.ToString("HH:mm:ss"));
        }
    }
}
</string>

Resultado:

Agora vamos realizar a chamada do método GetPage por uma thread:

namespace Threading
{
    public class Program
    {
        public static void Main(string[] args)
        {
            List<string> urls = new List</string><string>();
            urls.Add(@"http://sylverio.com.br/blog/2009/08/requisicao-http-com-java-application-parte-1/");
            urls.Add(@"http://sylverio.com.br/blog/2009/09/requisicao-http-com-java-application-parte-2/");
 
            Console.WriteLine("Start time foreground: {0}", DateTime.Now.ToString("HH:mm:ss"));
            foreach (string url in urls)
            {
                ThreadPool.QueueUserWorkItem(GetPage, url);
            }
            Console.WriteLine("End time foreground: {0}", DateTime.Now.ToString("HH:mm:ss"));
 
            Thread.Sleep(20000);
        }
 
        private static void GetPage(object data)
        {
            string url = (string) data;
            Console.WriteLine("Start time background: {0}", DateTime.Now.ToString("HH:mm:ss"));
 
            WebResponse wr = WebRequest.Create(url).GetResponse();
            if (wr != null)
            {
                Console.WriteLine("{0}: {1}", url, wr.Headers["Content-Length"]);
                wr.Close();
            }
 
            Console.WriteLine("End time background: {0}", DateTime.Now.ToString("HH:mm:ss"));
        }
    }
}
</string>

Resultado:

Conclusão

A utilização de thread é um recurso que pode e deve ser utilizado em diversos momentos dentro do desenvolvimento de software pois melhora drasticamente o desempenho da aplicação. Levamos 18 segundos para realizar a requisição de uma página web, contra 4 segundos do processamento paralelo. Porem deve ser avaliado seus benefícios, pois sua complexidade aumento muito assim como o consumo de recursos da máquina.

Espero ter ajudado

Apesar do desenvolvimento de sorftware ser uma ciência exata, muitos desenvolvedores consideram algumas dessas soluções como mágicas devido a sua complexidade. Primeiramente gostaria de salientar que não existe mágica, e sim o emprego metódico de técnicas e princípios para o projeto de software que boa parte dessa “mágica” pode ser atribuído ao polimorfismo.

O que é Polimorfismo?

“Um conceito em teoria de tipo, no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes” (Booch, 2000).
Em outras palavras, possibilita que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que as referenciam, esse comportamento também é conhecido como Generalização-Especialização.

Polimorfismo é uma solução para um problema comum em ciência da computação: “Variação condicional“.
Quando um programa é projetado com lógica condicional de estrutura if-else ou instrução case, quando surgir uma nova variação, ela exigirá uma modificação da lógica desses comandos, freqüentemente em vários lugares. Causando o aumento da complexidade ciclomática e manutenibilidade no sistema e diminuição do reuso de componentes.

Problema: Como tratar alternativas (variações condicionais) com base no tipo? Como criar componentes de software interconectáveis?

Solução: Quando alternativas ou comportamentos relacionados variam segundo o tipo (classe), atribua a responsabilidade pelo comportamento aos tipos para os quais o comportamento varia, usando operações polimórficas.

Exemplificando

Como caso de estudo, vou criar um simples sistema de exame virtual, onde iram existir 2 tipos de questões, numéricas e textos (descritivas).
Abaixo temos o modelo de domínio de nossa aplicação.

namespace Poliformismo
{
    public abstract class Question
    {
        public string Description { get; set; }
        public string Answer { get; set; }
        public bool Correct { get; set; }
 
        public abstract void AssessingAnswer();
    }
 
 
    public class Numeric : Question
    {
        public int CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            int number;
 
            bool isNumeric = int.TryParse(Answer, out number);
 
            if (isNumeric)
            {
                Correct = Equals(CorrectAnswer, number);
            }
        }
    }
 
 
    public class Text : Question
    {
        public string CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            Correct = Equals(CorrectAnswer.ToUpper(), Answer.ToUpper());
        }
    }
}

Vamos pensar no seguinte problema, as regras de avaliações de respostas para perguntas em texto se diferem das numéricas.
Seguindo o princípio do polimorfismo, devemos atribuir a responsabilidade de quem deve conhecer as regras aos tipos (no nosso caso a classe Text e Numeric ) utilizando operações polimórficas.
Para isso criamos a classe abstrata Question (Questão) é conceito geral, que pode representa qualquer um dos tipos de suas implementações (numérica ou texto).

using System;
using System.Collections.Generic;
 
namespace Poliformismo
{
    public class Exam
    {
        public Exam()
        {
            Questions = new List<question>();
            Questions.Add(new Numeric {Description = "Com quantos anos Nostradamos morreu?", CorrectAnswer = 47});
            Questions.Add(new Text {Description = "Qual a cor do cavalo branco de Napoleão?", CorrectAnswer = "Branco"});
        }
 
        public List</question><question> Questions { get; set; }
        public string Name { get; set; }
        public int Result { get; set; }
 
        public void ShowQuestions()
        {
            foreach (Question question in Questions)
            {
                Console.WriteLine(question.Description);
                string answer = Console.ReadLine();
 
                question.Answer = answer;
                question.AssessingAnswer();
            }
        }
 
        public void ShowResult()
        {
            Console.WriteLine();
            Console.WriteLine();
 
            Console.WriteLine("Correções da avaliação.");
 
            foreach (Question question in Questions)
            {
                Console.WriteLine("A resposta {0} esta: {1}", question.Answer, (question.Correct ? "Certa" : "Errada"));
            }
 
            Console.WriteLine();
            Console.WriteLine();
        }
    }
}
</question>

Reparem que para a classe Exam a manipulação das questões é transparente, nesse nível de abstratação, não importa se é uma questão do tipo numérica ou textual.
No método ShowQuestions quando o usuário digita a resposta, a classe Exam delega a classe Question a responsabilidade de verificar se a mesma esta correta. Assim cada tipo da operação aplica suas regras para validar a pergunta.

namespace Poliformismo
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Exam exam = new Exam {Name = "Carlos Fernando"};
            exam.ShowQuestions();
            exam.ShowResult();
        }
    }
}

Esse princípio traz diversas vantagens para a arquitetura da aplicação. Além de diminuir a complexidade ciclomática da aplicação porque não utilizamos instruções condicionais (if-else) para tratar as variações condicionais (“se for questão do tipo texto ou se for questão do tipo numérica”). Também auxilia na arquitetura, pois facilita a extensão de novas funcionalidades. Se caso em momento futuro surja a necessidade de criar questões de múltiplas escolhas, não teremos que alterar o exame (Exam), e sim implementar uma nova classe onde implemente a abstração de questão.
Nesse exemplo, tratamos alternativas com base no tipo, para soluções de componentes de software interconectáveis, será realizado em um próximo post.

Conclusão

Polimorfismo é um princípio fundamental no projeto e desenvolvimento de um sistema, diminui a complexidade ciclomática de uma aplicação e ainda permite que seja facilmente estendido para tratar novas variações.
Esse princípio deve ser muito bem compreendido por desenvolvedores, pois muitos design patterns utilizam seus conceitos para implementações de soluções.

Padrões relacionados:

• Variações protegidas
• Vários padrões de projetos GOF

Solução: Atribua a responsabilidade a uma classe que representa uma das seguintes escolhas:

• Representa o “sistema global”, um “objeto raiz”, um dispositivo dentro do qual o software está sendo processado, ou um subsistema importante – essas são todas variantes de um controlador fachada (facade controller)
• Representa um cenário de um caso de uso dentro do qual ocorre o evento do sistema, frequentemente denominado TratadoDo<nomedecasodeuso>, CoordenadorDe<nomedecasodeuso> ou SessaoDo<nomedecasodeuso>
  • Use a mesma classe controladora para todos os eventos do sistema do mesmo cenário do caso de uso.
  • Informalmente, uma sessão é uma instância de convenção com um ator. Sessões podem ser de qualquer tamanho, mas frequentemente são organizadas em casos de uso.

Um controlador é o primeiro objeto além da camada de UI que é responsável por receber ou tratar uma mensagem de operação do sistema. Esse é um padrão de delegação, de acordo com a premissa que a camada de UI não deve conter a lógica da aplicação, os objetos da camada de UI precisam delegar essa solicitação a outra camada.

Quando e como utilizar!
Os Controladores Fachada são adequados quando não exitem “demasiados” eventos de sistema.
Nesse caso pode-se optar por Controladores de Caso de Uso para evitar tonar os controladores fachada sobrecarregado com excesso de responsabilidade, evitando a baixa coesão e alto acoplamento.

Em 1967 Ivar Jacobson desenvolve uma metodologia onde existem os conceitos (opcionais) de classes de fronteira, classes de controle e classes de entidade. Os objetos de fronteiras, são abstrações das interfaces. Os objetos de entidade são objetos do domínio. E os objetos de controles são tratadores de caso de uso.

Conceito X Tecnologia
O Princípio Controlador apresentado difere de controladores de tecnologias como ASP.NET MVC, ASP.NET WebForms, Struts (JAVA) entre outras.
O code behind do WebForms ou são tratadores de eventos do navegador, já os controllers (Action) do MVC são controladores de interação e fluxo de página. Estes deveram obter uma referência para objetos controladores do domínio a fim de obter uma Separação Modelo-Visão.

Vantagens

• Aumento da possibilidade de reutilização e de interfaces “plugáveis” – essa vantagem garante que logica de aplicação não seja tratada na interface.
• Melhora a forma de gerenciamento de sobre o estado do caso de uso – permite garantir que uma determinada chamada (método) não irá ocorrer até que outra tenha sido executada.

Padrões Relacionados

• Commando
• Fachada
• Camadas
• Invenção Pura

Problema: Como manter os objetos bem focados, inteligíveis, gerenciavéis e como efeito colateral apoiar o baixo acoplamento?
Solução: Atribuir uma responsabilidade de forma que a coesão permaneça alta.

Em outras palavras, são classes de difícil entendimento e manutenção consequentemente de difícil reutilização, executam atividades que deveriam ser delegadas para outros objetos, ou apresentam um nível de abstração alto.

Para exemplificar vou apresentar uma situação fictícia, de um sistema de atendimento de chamados, e esses atendimentos podem esta relacionados a vários clientes.

Considere a seguinte situação, o usuário adiciona um cliente ao atendimento. O ControladorAtendimento recebe a mensagem, seguindo o princípio criador, ela detêm os dados iniciais de Cliente e se torna uma boa candidata para criar a instância c do Cliente.
Depois a instância ControladorAtendimento envia uma mensagem AdicionarCliente passando a instância c Cliente para o Atendimento.

Nesse caso de forma isolado, não há problemas de coesão, porem se o Controlador continuar a ser responsável pela maioria dos serviços executados pelo gerenciamento de um atendimento ele irá se sobrecarregar de tarefas e perderá sua coesão.

O digrama abaixo apresenta a solução para o problema citado:

O ControladorAtendimento delega para o objeto Atendimento a função de criar a instancia de Cliente.
Dessa forma tornamos a classe Atendimento mais coesa, pois suas atividades estão mais encapsuladas.
Se analisarmos melhor, o princípio criador esta sendo mais bem aplicado nesse caso, pois Atendimento “contém” uma lista Cliente e Atendimento usa Cliente de maneira muito próxima, ou seja, são duas condições que a tonam uma candidata a criação instância Cliente muito melhor que ControladorAtendimento.
Outro princípio que podemos identificar que foi aplicado nessa solução foi a diminuição do acoplamento da classe ControladorAtendimento, pois ela não precisa mais ter conhecimento (ou referência) para do objeto Cliente.

Segundo Grandy Booch, coesão alta existe quando os elementos de um componente “trabalham juntos para fornecer algum comportamento bem delimitado”.

Craig Larman define uma classe com coesão alta da como, “tem um número relativamente pequeno de métodos, com funcionalidade altamente relacionada, e não executa muito trabalho. Se a tarefa for grande, irá colaborar com outros objetos para dividir o esforço”.

Graus de Coesão

1. Coesão Muito Baixa – Uma classe é a única responsável por muitas coisas em áreas funcionais muito diferentes.
2. Coesão Baixa – Uma classe é a única responsável por uma tarefa complexa em uma área funcional.
3. Coesão Alta – Uma classe que tem responsabilidades moderadas em uma área funcional e colabora com outras classes para realizar a tarefa.
4. Coesão Moderada – Uma classe tem peso leve e responsabilidade exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não umas com as outras.

Conclusão

Assim como o Baixo Acoplamento, Coesão Alta é um princípio que devemos ter em mente durante todo o desenvolvimento/projeto de um sistema, pois auxilia a avaliação de alternativas e de tomada de decisão sobre os objetos de software.

Problema: Como apoiar dependência baixa, baixo impacto de modificação e aumentar o reúso?

Solução: Atribuir responsabilidade de modo que o acoplamento permaneça baixo.

Abaixo segue alguns efeitos na arquitetura que uma classes com acoplamento alto (ou forte) pode causar:

• Rigidez: Alteração em uma classe, obriga a alteração em diversas classes relacionadas, gerando uma cadeia de manutenção, conhecidas como “efeito dominó”.
• Fragilidade: Dificuldade de manutenção em um determinado ponto do sistema, pois gera problemas em outro ponto não relacionado, conhecido como “efeito borboleta-maremoto”, nomenclatura extraída da Teoria do Caos. Esta teoria defende que o simples bater de asas de uma borboleta em um extremo do mundo, pode causar um tornado no outro extremo.
• Imobilidade: Dificuldade de reutilização por excesso de dependência entre
  classes, conhecido como “efeito banana-gorila”, pois a dependência é tão grande que solicitar uma banana e é obtido um gorila junto com ela.

Formas comum de acoplamento entre classes:

• Objeto A tem um atributo do que se refere a instância de um objeto B.
• Objeto A chama um serviço de um objeto B.
• Objeto A tem um método que referencia uma instância de um objeto B (seja por parâmetro, variável local ou retorno da mensagem).
• Objeto A é uma subclasse do objeto B.
• Objeto B é uma interface implementada pelo objeto A.

Dica: O nível de acoplamento em si não deve ser considerado isolado de outros princípios tais como Especialista de Informação e Coesão Alta.

Contra-Indicações
Acoplamento forte a objetos estáveis não é um problema. Exemplo: Pode-se acoplar com segurança a biblioteca Java (java.util, etc) ou .Net (System.Collections, etc) pois são estáveis e amplamente disseminadas.

O acoplamento alto não é um problema, mas passa a ser um problema em classes que estão sujeitas a modificações ou entre objetos de pacotes e/ou camadas diferentes. A idéia principal é minimizar os efeitos de dependência excessivo entre objetos a fim de reduzir os impactos de modificações e permitir o reuso de objetos.
Devemos sempre avaliar o grau de acoplamento entre objetos e quais as conseqüências teremos em nosso sistema ao aumenta-lo.
Objetos genéricos devem sempre ter um nível de acoplamento muito baixo possibilitar reutiliza-lo em diversas partes do sistemas sem grandes impactos de dependência.
Por outro lado, objetos com ausência de acoplamento também não são bem vistos no sistema, pois contradiz a metáfora central da tecnologia de objetos: “um sistema é composto por objetos conectados que se comunicam por mensagens”.

Vantagens:

• Não é afetado por mudanças em outros computadores.
• Simples de entender isoladamente.
• É conveniente para reutilização.

Padrões Relacionados

• Variação Protegida

Enjoy