O que você descreve é conhecido como modelo de domínio anêmico . Tal como acontece com muitos princípios de design OOP (como a Lei de Demeter, etc), não vale a pena dobrar para trás apenas para satisfazer uma regra.
Nada de errado em ter sacos de valores, contanto que eles não atravancem toda a paisagem e não dependam de outros objetos para fazer as tarefas domésticas que eles poderiam estar fazendo por si mesmos . p>
Certamente seria um cheiro de código se você tivesse uma classe separada apenas para modificar propriedades de Card
- se fosse razoavelmente esperado que ele cuidasse delas por conta própria.
Mas é realmente um trabalho de Card
saber a que Player
é visível?
E por que implementar Card.isVisibleTo(Player p)
, mas não Player.isVisibleTo(Card c)
? Ou vice-versa?
Sim, você pode tentar criar algum tipo de regra para isso - como Player
sendo mais alto que um Card
(?) - mas não é tão fácil adivinhar e eu Teremos que procurar em mais de um lugar para encontrar o método.
Com o tempo, isso pode levar a um comprometimento de projeto podre na implementação de isVisibleTo
em ambos Card
e Player
class, o que acredito ser um não-não. Por quê? Porque eu já imaginei o dia vergonhoso quando player1.isVisibleTo(card1)
retornará um valor diferente de card1.isVisibleTo(player1).
eu acho - é subjetivo - isso deve ser impossível por design .
A visibilidade mútua de cartões e jogadores deve ser melhor governada por algum tipo de objeto de contexto - seja Viewport
, Deal
ou Game
.
Não é igual a ter funções globais. Afinal, pode haver muitos jogos simultâneos. Observe que o mesmo cartão pode ser usado simultaneamente em várias tabelas. Devemos criar muitas Card
instâncias para cada ás de espada?
Eu ainda posso implementar isVisibleTo
em Card
, mas passar um objeto de contexto para ele e tornar Card
delegar a consulta. Programa para interface para evitar alto acoplamento.
Quanto ao segundo exemplo - se o ID do documento consistir apenas em BigDecimal
, por que criar uma classe de wrapper?
Eu diria que tudo que você precisa é de DocumentRepository.getDocument(BigDecimal documentID);
A propósito, enquanto ausente do Java, existem struct
s em C #.
Veja
para referência. É uma linguagem altamente orientada a objetos, mas ninguém faz grande diferença com isso.