Como evitar anti-padrões em aplicativos iOS - manequins

Se você usar o processo padrão e as regras do design Object-oriented (OO) para a criação do aplicativo iOS, seus projetos devem ser robustos; no entanto, mesmo com um processo de som e diretrizes apropriadas você poderia criar um anti-padrão. Os anti-padrões ocorrem quando uma classe herda funcionalidade através de uma conexão inadequada.

Mesmo se você é um desenvolvedor experiente, você poderia obter coisas erradamente erradas resultando em um design não funcional. O seguinte aborda formas específicas de fazer coisas erradas.

Anti-padrões cobrem uma série de armadilhas do design organizacional e gerenciamento de projetos para a programação. Aqui estão alguns anti-padrões relevantes para o design OO:

• O chamado anti-padrão Bean Base: Aqui é onde uma classe herda de outra classe porque a superclasse contém a funcionalidade necessária na subclasse.

  Suponha que você esteja implementando uma classe de dicionário onde você pode procurar os significados das palavras. Uma tabela de hash, onde as palavras são hash para localizar seus significados é uma estrutura de dados razoável para usar dentro de um dicionário.

  No entanto, fazer o seu dicionário herdar de uma tabela de hash não é um bom design. Seu dicionário acaba tendo métodos em sua interface que não têm conexão com palavras e seus significados. Por outro lado, sua classe possui métodos que têm tudo a ver com os dicionários, mas nada a ver com as tabelas hash.

  O Bean Base geralmente ocorre quando um desenvolvedor de software confunde um relacionamento IS-A, que é apropriado para representar uma verdadeira subclasse via herança, com um relacionamento HAS-A, que é melhor servido por uma relação de contenção. Em outras palavras, um dicionário pode ter uma tabela Hash, mas não é uma tabela Hash.

  Observe que o processo de design OO descrito exige que você tente concordar com uma definição curta e nítida para cada classe potencial antes de elevá-la para se tornar uma classe candidata. Isso ajuda você a evitar o anti-padrão do Bean Base.

• O modelo de domínio anêmico: Alguns grupos, em particular a comunidade Enterprise Java, pensam em classes de modelos de domínio como simplesmente consistindo em getters e setters para os atributos na classe, sem nenhum comportamento de domínio na classe (por exemplo, validações, cálculos, regras de negócios e similares). Esse tipo de design é contrário ao pensamento da OO.