Por que devemos preferencialmente usar coleções de primeira classe?

De acordo com a regra número 4 de Object Calisthenics, de Jeff Bay ^(RTF) na The ThoughtWorks Anthology, recomenda-se que "se use coleções de primeira classe ".

Regra 4: Coleções de primeira classe

A aplicação desta regra é simples: qualquer classe que contenha uma coleção não deve conter outras variáveis ​​de membro. Cada coleção é agrupada em sua própria classe, então agora os comportamentos relacionados à coleção têm uma casa. Você pode achar que os filtros se tornam parte dessa nova classe. Além disso, sua nova turma pode lidar com atividades como juntar dois grupos ou aplicar uma regra a cada elemento do grupo.

O que eu pude entender disso foi que devemos usar uma classe separada para encerrar a coleção e com métodos para adicionar e excluir dados de modificação dessa coleção.

e Precisamos disso para ter certeza de que tipo de dados entra na coleção e o que sai.

Caso usemos coleção genérica (nos idiomas em que é aplicável), precisamos seguir esta regra?

Se estiver faltando um significado importante, esclareça.

A segurança de tipo é um motivo muito menor para usar coleções de primeira classe. Do seu link:

Regra 4: Coleções de primeira classe A aplicação desta regra é simples: qualquer classe que contenha uma coleção não deve conter outras variáveis ​​de membro. Cada coleção é agrupada em sua própria classe, então agora os comportamentos relacionados à coleção têm uma casa. Você pode achar que os filtros se tornam parte dessa nova classe. Além disso, sua nova turma pode lidar com atividades como juntar dois grupos ou aplicar uma regra a cada elemento do grupo.

A idéia aqui é que, se você estiver pesquisando, filtrando, validando ou qualquer coisa além de adicionar / remover / iterar a semântica em uma coleção, o código solicitará que você a coloque em sua própria classe. Se você precisar atualizar apenas um valor (após uma pesquisa), isso provavelmente estará na classe de coleção.

O raciocínio para isso é bastante simples, as coleções tendem a ser repassadas. Em breve, 4 classes diferentes terão seu próprio SearchByID()método. Ou você obtém valores de retorno como Map<Integer, String>com o contexto do que é armazenado nesse mapa retirado. Uma coleção de primeira classe é uma solução simples que custa um único arquivo de origem. Na prática, uma vez implementados (também é muito fácil escrever testes de unidade), é fácil lidar com qualquer alteração relacionada à coleção, como quando é SearchByIDnecessário ter um GUID em vez de um int.

... use uma classe separada para finalizar a coleção e com métodos para adicionar, excluir dados modificados dessa coleção

Isso faz muito mais do que garantir o tipo de objetos armazenados nas coleções, mas também garante quaisquer invariantes da coleção.

As árvores (vermelho-preto, AVL etc.) são sensíveis a pedidos e seu comportamento depende do reequilíbrio, quando apropriado. O desempenho da tabela de hash também dependerá do re-hash apropriado. Deseja se lembrar de verificar o fator de carga toda vez que você inserir um mapa de hash?

FWIW, o texto é bastante claro sobre isso (e vou editar a coisa toda em sua pergunta, para que ninguém mais precise baixar o RTF):

Cada coleção é agrupada em sua própria classe, portanto, agora os comportamentos relacionados à coleção têm um lar

Nada a ver com tipos (ou, portanto, genéricos), tudo a ver com a associação do comportamento da coleção com seus dados.

A resposta simples é "Não" se você estiver usando um idioma compatível com genéricos. Porque não há necessidade de verificar o tipo, pois o próprio recurso de linguagem faz um bom trabalho nisso (da minha experiência genérica em Java).

Mas se você tiver alguma situação em que deseja personalizar a estrutura de dados fornecida no idioma, poderá criar uma classe de wrapper em torno da estrutura de dados original e expor suas próprias APIs e ainda usar a implementação subjacente da estrutura de dados original.