God objects: em geral, uma má prática

Este post é composto de trechos extraídos da Wikipedia.

Em programação orientada a objeto, um God Object (Objeto Deus) é um objeto que sabe muito e faz muito. God Object é um exemplo de anti-pattern.

A idéia básica por trás da programação estruturada é que um problema grande seja quebrado em muitos problemas menores (estratégia dividir e conquistar) e soluções são criadas para cada um destes problemas. Assim que os problemas pequenos são resolvidos, o problema como um todo também será. Portanto, há somente um objeto de quem um objeto precisa saber tudo: ele mesmo. Além disso, há somente um objeto de quem um objeto deve resolver um conjunto de problemas: ele mesmo.

O código baseado em God Object não segue esta abordagem. Em vez disso, a maioria da funcionalidade global é codificada em um único objeto "sabe-tudo", que mantém a maioria das informações do programa inteiro e fornece a maioria dos métodos para manipular os dados. Devido ao fato que este objeto mantém muitos dados e requisita muitos métodos, seu papel no programa se torna como se fosse um "Deus". Em vez de objetos se comunicando diretamente, os outros objetos dentro do programa confiam a um God Object a maioria de suas informações e interações. Uma vez que o God Object é referenciado por muitos outros códigos, a manutenção se torna mais difícil do que em um design dividido de forma mais equilibrada.

God Object é um análogo orientado a objeto de não usar subrotinas em linguagens procedurais, ou em usar muitas variáveis globais para armazenar informação de estado.

Enquanto a criação de um God Object é normalmente considerada uma má prática de programação, esta técnica é ocasionalmente utilizada em certos ambientes de programação (como microcontrollers), onde há um ligeiro aumento de desempenho e a centralização do controle é mais importante que a manutenibilidade e o código elegante.

O que é Code Smell?

Este post é um conjunto de trechos extraídos da Wikipedia.

Em programação, code smell é qualquer sintoma no código fonte que indica um problema mais profundo.

O problema sugerido por um code smell sempre ser descoberto quando o código está sujeito a um pequeno ciclo de feedback, onde é refatorado em etapas pequenas e controladas, e o design resultante é examinado para verificar se há mais code smells que indiquem a necessidade de mais refatoração.

Do ponto de vista de um programador encarregado de realizar a refatoração, code smells são heurísticas que indicam quando refatorar, e quais técnicas específicas de refatoração devem ser usadas.

Determinar o que é ou não um code smell é sempre um julgamento subjetivo, e sempre irá variar de acordo com a linguagem de programação, o desenvolvedor e a metodologia de desenvolvimento.

Existem ferramentas que detectam certos tipos de code smells, como:
Java: Checkstyle, PMD e FindBugs.
Dot Net: ReSharper.

Code smells comuns:

Código duplicado: código idêntico ou muito similar existe em mais de um local.
Método longo: um método, função ou procedure muito extenso.
Classe extensa: uma classe que acabou ficando muito extensa (God Object).
Feature envy (sem tradução): uma classe que utiliza em excesso métodos de outra classe.
Intimidade inapropriada: uma classe que possui dependência de detalhes de implementação de outra classe.
Legado recusado: uma classe que sobrepõe (override) o método da classe genérica de forma que o contrato da classe genérica não é cumprido pela classe derivada.
Classe preguiçosa: classe que faz muito pouco.
Complexidade artificial: uso forçado de design patterns extremamente complicados, onde um design simples seria suficiente.
Identificadores excessivamente longos: em particular, o uso de convenções de nomes para evitar ambigüidades, o que deveria estar implicito na arquitetura do software.

Princípios SOLID: O que são?

SOLID são cinco princípios básicos de programação e design orientados a objeto, introduzidos por Robert C. Martin no início dos anos 2000:

SRP: Single Responsibility Principle (Princípio da Responsabilidade Única). Noção de que um objeto deve possuir uma única responsabilidade.

OCP: Open/Closed Principle (Princípio Aberto / Fechado). Noção de que o software deve ser aberto para extensão, mas fechado para modificação.

LSP: Liskov Substitution Principle (Princípio da Substituição de Liskov). Noção de que objetos devem ser substituídos por instâncias de seus subtipos, sem afetar a correção do programa.

ISP: Interface Segregation Principle (Princípio de Segregação da Interface). Muitas interfaces específicas são melhores do que uma interface de uso geral.

DIP: Dependency Inversion Principle (Princípio de Inversão da Dependência). Noção de que se deve depender de interfaces abstratas e não de classes concretas, uma vez que implementações concretas são mais propensas a mudanças.

Princípios SOLID podem ser aplicados no desenvolvimento de software:

- A fim de remover Code Smells. Desta forma, o desenvolvedor refatora o código fonte do software até que esteja legível e extensível.
- Em conjunto com TDD (Test-Driven Development: desenvolvimento orientado a testes).
- É parte de uma estratégia global de programação ágil e adaptativa.
- Quando os princípios são aplicados em conjunto, aumentam bastante as chances de que o sistema criado seja simples de manter e estender.

Esta foi uma introdução a SOLID. Nos próximos posts farei uma explicação simples de cada um dos princípios aqui mencionados.

Scrum com Team Foundation Server 2010

Uma dica para os amantes do Scrum e do Dot Net é ler o slide abaixo, publicado por Aaron Bjork:

Scrum With Team Foundation Server 2010

View more presentations from Aaron Bjork.

As 10 melhores práticas para se construir software.

Estas são As 10 melhores práticas para se construir software, post escrito por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet:

1 - Desenvolva uma visão do produto.
2 - Trabalhe de modo iterativo e evolutivo.
3 - Envolva o cliente no processo.
4 - Gerencie requisitos.
5 - Acolha mudanças.
6 - Construa o design e a arquitetura incrementalmente.
7 - Diminua o tempo de feedback.
8 - Gerencie riscos.
9 - Aplique técnicas de engenharia.
10 - Confie na equipe.

Clique aqui e leia este e outros posts na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Como trabalham os desenvolvedores profissionais?

O post Como trabalham os desenvolvedores profissionais?, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, lista as características inerentes aos bons desenvolvedores da seguinte forma:

Estudam muito, sempre;
Gostam de compartilhar conhecimento;
Escrevem seus próprios testes;
Escrevem código para pessoas e não para máquinas;
Refatoram de forma disciplinada e habitualmente;
Evoluem com o design tendo o business em mente.

Clique aqui e leia este post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Verdades e Mitos sobre a Programação Orientada a Objetos

O post Verdades e Mitos sobre a Programação Orientada a Objetos, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, divide idéias sobre a programação orientada a objetos em:

Verdades:
O Desenvolvimento OO é mais lento;
Programadores mais antigos têm dificuldades com OO;
A programação OO favorece a reutilização.

Mitos:
Objetos são "abstrações" do mundo real;
Programar em Java ou C# gera automaticamente software OO;
Para aprender OO é preciso antes aprender UML;

Para saber o porquê destas verdades e mitos, clique aqui e leia o post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).