Como explicar a alguém que uma estrutura de dados não deve se desenhar, explicando a separação de preocupações?

Question

Tenho outro programador que estou tentando explicar por que um componente da interface do usuário também não deve ser uma estrutura de dados.

Por exemplo, diga que você obtém uma estrutura de dados que contém um conjunto de registros do "banco de dados" e deseja exibir esse conjunto de registros em um componente da interface do usuário no seu aplicativo.

De acordo com esse programador (que permanecerá sem nome, ele é jovem e eu estou ensinando a ele ...), devemos subclasse a estrutura de dados em uma classe que atrairá o componente da interface do usuário em nosso aplicativo !!!!!!

E assim, de acordo com essa lógica, o recorde deve gerenciar o desenho da interface do usuário.

****** mesa de cabeça *****

Sei que pedir a um recorde para desenhar está errado, porque, se você deseja renderizar a mesma estrutura de dados em mais de um tipo de componente na sua interface do usuário, terá uma bagunça real em suas mãos; Você precisará estender mais uma classe para cada componente de interface do usuário que você renderiza da classe base do seu registro;

Estou bem ciente da "limpeza" do padrão do MVC (e com isso que realmente quero dizer é que você não confunde seus dados (o modelo) com sua interface do usuário (a visualização) ou as ações que ocorrem no Dados (o controlador mais ou menos ... ok, não é realmente a API realmente deve lidar com isso ... e o controlador deve fazer o máximo de chamadas possível, dizendo qual visão renderizar)), mas certamente é muito mais limpo do que usar estruturas de dados para renderizar componentes da interface do usuário!

Há algum outro conselho que eu poderia enviar do seu caminho além do exemplo acima? Entendo que, quando você aprende opa pela primeira vez, você passa por "um estágio", onde você só quer estender tudo.

Seguido por um estágio quando você pensa que os padrões de design são a solução todos os problemas ... que também não está totalmente correto ...Obrigado Jeff.

Existe uma maneira de eu poder cutucar gentilmente esse garoto na direção certa? Você tem mais exemplos que podem ajudar a explicar meu ponto para ele?

Answer 1

Você já ouviu falar de Martin Fowler?

Separando o código da interface do usuário

De qualquer forma, se ele quiser ir mais longe nessa direção de adicionar métodos de renderização aos seus controles de dados, faça com que ele olhe para o "acoplamento solto". Não há problema em criar algum tipo genérico de interface que o coloque no meio do caminho, mas o componente da interface do usuário deve levá -lo pelo resto do caminho.

Answer 2

Isso se resume a responsabilidades funcionais versus não funcionais. O que a estrutura de dados faz e como é visualizada são duas coisas completamente separadas - essencialmente a raiz do padrão MVC.

Há também uma noção de dependências circulares aqui. Como a interface do usuário deve saber sobre as estruturas de dados, se você permitir que as estruturas de dados dependam da interface do usuário, você terá uma bela bola de lama.

Answer 3

Geralmente no ponto de desacoplar:

1. Não apenas pode haver diferentes componentes da interface do usuário, renderizando a mesma estrutura de dados. Você pode até ter UIs completamente diferentes (web, aplicativo de desktop, ...) agora, é claro, você pode subclasse Person com WebPerson e DesktopPerson (Isso já parece errado, não é? A nomeação simplesmente não é sobre o tipo de pessoa - é sobre outra coisa).

2. Cada interface do usuário poderia funcionar em diferentes tipos de pessoas, por exemplo, Teacher e Student. Então nós conseguimos WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher e DesktopStudent.

Agora digamos, WebPerson Define o método "drawAddressfields ()" para desenhar uma versão da web dos campos de endereço. Mas desde WebTeacher tem que derivar de Teacher Para usar o campo de dados adicionais "salário" (e vamos assumir a herança única), ele deve implementar "drawaddressfields ()" mais uma vez!

Então, talvez o argumento de "isso causará muito mais trabalho" ajude a criar alguma motivação :-)

BTW, ele levará automaticamente à criação de alguns delegados que implementam o código do drawAddressfield (), que evoluirá para criar um componente que faça o desenho separadamente da estrutura de dados.