Escrever seus substantivos, verbos e adjetivos é uma ótima abordagem, mas eu prefiro pensar no design de classe como fazer a pergunta que dados devem ser ocultados ?
Imagine que você tinha um Queryobjeto e um Databaseobjeto:
O Queryobjeto ajudará você a criar e armazenar uma consulta - armazenar, é a chave aqui, pois uma função pode ajudá-lo a criar uma com a mesma facilidade. Talvez você poderia ficar: Query().select('Country').from_table('User').where('Country == "Brazil"'). Não importa exatamente a sintaxe - esse é o seu trabalho! - a chave é que o objeto está ajudando a ocultar algo , neste caso os dados necessários para armazenar e gerar uma consulta. O poder do objeto vem da sintaxe de usá-lo (neste caso, um encadeamento inteligente) e da necessidade de não saber o que ele armazena para fazê-lo funcionar. Se feito corretamente, o Queryobjeto pode gerar consultas para mais de um banco de dados. Internamente, ele armazenava um formato específico, mas poderia ser facilmente convertido para outros formatos ao produzir (Postgres, MySQL, MongoDB).
Agora vamos pensar no Databaseobjeto. O que isso esconde e armazena? Bem, claramente, ele não pode armazenar todo o conteúdo do banco de dados, pois é por isso que temos um banco de dados! Então qual é o ponto? O objetivo é ocultar como o banco de dados funciona das pessoas que usam o Databaseobjeto. Boas classes simplificarão o raciocínio ao manipular o estado interno. Para esse Databaseobjeto, você pode ocultar como as chamadas de rede funcionam, ou consultas em lote ou atualizações, ou fornecer uma camada de armazenamento em cache.
O problema é que esse Databaseobjeto é ENORME. Ele representa como acessar um banco de dados; portanto, por baixo das cobertas, ele pode fazer tudo e qualquer coisa. Claramente, é difícil lidar com redes, cache e lotes, dependendo do sistema, portanto, escondê-los seria muito útil. Mas, como muitas pessoas observam, um banco de dados é incrivelmente complexo e, quanto mais longe das chamadas brutas de banco de dados que você recebe, mais difícil é ajustar o desempenho e entender como as coisas funcionam.
Essa é a troca fundamental da OOP. Se você escolher a abstração correta, simplificará a codificação (String, Matriz, Dicionário), se você escolher uma abstração muito grande (Banco de Dados, EmailManager, NetworkingManager), poderá se tornar muito complexo para realmente entender como funciona ou o que Espero. O objetivo é ocultar a complexidade , mas é necessária alguma complexidade. Uma boa regra é começar a evitar Managerobjetos e, em vez disso, criar classes parecidas structs- tudo o que eles fazem é armazenar dados, com alguns métodos auxiliares para criar / manipular os dados para facilitar sua vida. Por exemplo, no caso de EmailManageriniciar com uma função chamada sendEmailque pega um Emailobjeto. Este é um ponto de partida simples e o código é muito fácil de entender.
Como no seu exemplo, pense em quais dados precisam estar juntos para calcular o que você está procurando. Se você quisesse saber a que distância um animal estava andando, por exemplo, você poderia ter AnimalStepe AnimalTrip(coleção de AnimalSteps) classes. Agora que cada viagem tem todos os dados da etapa, deve ser capaz de descobrir coisas sobre isso, talvez AnimalTrip.calculateDistance()faça sentido.