Não , um objeto não precisa representar uma entidade.
Na verdade, eu argumentaria que quando você para de pensar em objetos como entidades físicas é quando finalmente obtém os benefícios que o OOP promete.
Este não é o melhor exemplo, mas o design da Cafeteira é provavelmente o local onde a luz começou a acender para mim.
Objetos são sobre mensagens. Eles são sobre responsabilidades. Eles não são sobre carros, usuários ou pedidos.
Sei que ensinamos OO dessa maneira, mas depois de algumas tentativas, fica evidente como é fundamentalmente frustrante descobrir para onde as coisas vão quando você tenta fazer MVC, MVVM ou MVWhatever. Seus modelos ficam ridiculamente inchados ou seus controladores. Para a navegabilidade, é ótimo saber que tudo o que toca em Veículos está no arquivo Vehicle.ext, mas quando seu aplicativo é sobre Veículos, você inevitavelmente acaba com 3000 linhas de espaguete nesse arquivo.
Quando você tem uma nova mensagem para enviar, possui pelo menos um novo objeto e talvez um par deles. Portanto, na sua pergunta sobre um conjunto de métodos, eu argumentaria que você está potencialmente falando sobre um pacote de mensagens. E cada um pode ser seu próprio objeto, com seu próprio trabalho a fazer. E tudo bem. Ficará aparente à medida que você divide as coisas, que realmente precisam estar juntas. E você os junta. Mas você não coloca todos os métodos imediatamente em uma gaveta vagamente apropriada por conveniência, se quiser aproveitar o OO.
Vamos falar sobre bolsas de funções
Um objeto pode ser apenas uma coleção de métodos e ainda ser OO, mas minhas "regras" são bastante rígidas.
A coleção deve ter uma única responsabilidade, e essa responsabilidade não pode ser tão genérica quanto "Faz coisas para os motores". Posso fazer uma fachada de camada de serviço, mas tenho plena consciência de que estou sendo preguiçoso por motivos de navegabilidade / descoberta, não porque estou tentando escrever código OO.
Todos os métodos devem estar em uma camada consistente de abstração. Se um método recuperar objetos Motor e outro retornar Cavalos-força, isso provavelmente está muito distante.
O objeto deve funcionar no mesmo "tipo" de dados. Esse objeto faz coisas com os motores (liga / desliga), este faz coisas com comprimentos de manivela, este lida com o seqüenciamento de ignição, este assume um formato html. Esses dados poderiam ser campos no objeto e pareceriam coesos.
Geralmente construo objetos desse tipo quando estou fazendo transformações, composições ou simplesmente não quero me preocupar com mutabilidade.
Acho que focar nas responsabilidades dos objetos me leva à coesão. Tem que haver alguma coesão para ser um objeto, mas não precisa haver campos nem muito comportamento para que seja um objeto. Se eu estivesse construindo um sistema que precisasse desses 5 métodos motores, começaria com 5 objetos diferentes que fazem essas coisas. Quando encontrei elementos comuns, começava a mesclar as coisas ou usava objetos "auxiliares" comuns. Isso me leva a preocupações abertas / fechadas - como posso extrair esse pouco de funcionalidade para nunca precisar modificar esse arquivo específico novamente, mas ainda usá-lo quando necessário?
Objetos são sobre mensagens
Os campos pouco importam para um objeto - obter e definir registros não muda o mundo fora do programa. A colaboração com outros objetos realiza o trabalho. No entanto, a força do OO é que podemos criar abstrações para não precisar pensar em todos os detalhes individuais de uma só vez. Abstrações que vazam ou não fazem sentido são problemáticas, por isso pensamos profundamente (talvez demais) sobre a criação de objetos que correspondem aos nossos modelos mentais.
Pergunta-chave: Por que esses dois objetos precisam se comunicar?
Pense no objeto como um órgão em uma pessoa - ele tem um objetivo padrão e só muda de comportamento quando recebe uma mensagem específica com a qual se importa.
Imagine um cenário em que você está na faixa de pedestres e um carro está chegando rápido. Como objeto cerebral, detecto um estressor. Eu digo ao hipotálamo para enviar hormônio liberador de corticotrofina. A hipófise recebe essa mensagem e libera hormônio corticotrófico adrenal. As glândulas supra-renais recebem essa mensagem e criam adrenalina. Quando o objeto muscular recebe essa mensagem de adrenalina, ele se contrai. Quando o coração recebe a mesma mensagem, ele bate mais rápido. Há toda uma cadeia de jogadores envolvidos no início do comportamento complexo de correr do outro lado da rua e são as mensagens que importam. O objeto do cérebro sabe como fazer com que o hipotálamo envie o alerta, mas não conhece a cadeia de objetos que eventualmente fará o comportamento acontecer. Da mesma forma, o coração não tem ideia de onde vem a adrenalina,
Portanto, neste exemplo ( simplificado ), o objeto da glândula adrenal precisa apenas saber como tomar ACTH e produzir adrenalina. Ele não precisa de campos para fazer isso, mas ainda parece um objeto para mim.
Agora, se nosso aplicativo for projetado apenas para correr do outro lado da rua, talvez eu não precise da glândula pituitária e dos objetos da glândula adrenal. Ou preciso apenas de um objeto da hipófise que faça apenas uma pequena parte do que conceitualmente podemos ver como o "modelo da hipófise". Todos esses conceitos existem como entidades conceituais, mas é um software e podemos criar o AdrenalineSender ou MuscleContractor ou qualquer outra coisa e não nos preocupar muito com a "incompletude" do nosso modelo.