Programar orientado a objetos é muito mais que construir classes e métodos. Java te força a programar em classes, desde o primeiro contato você vai programar em uma classe, mas nem por isso você está programando orientado a objetos. Programar orientado a objetos é programar códigos como se fossem objetos da vida real. Por exemplo, um objeto ser humano poderia ter os atributos (ou propriedades, se preferir) nome, altura, peso, cor, data de nascimento e métodos andar, correr, saltar, dormir e esse objeto poderia interagir com outros objetos desse mundo.
Objeto é uma instância de uma classe. Classe é uma fábrica de objetos.
Os exemplos que encontramos por ai muitas vezes não fazem muito sentido com o contexto que programamos. Vou focar na web. Onde entraria o objeto ser humano e método correr em um site? Só se disséssemos que correr é o sair (logout) de uma área restrita, que não seria muito legal, mas andar, saltar e dormir continuariam sem fazer sentido. Esses métodos seriam bons para jogos e aplicações gráficas.
Agora, e se convertêssemos o objeto ser humano para usuário, suas propriedades fossem nome, sobrenome, e-mail e senha e métodos nome completo e logout. Faz sentido em um site, não? Se o site for um e-commerce poderíamos adicionar os métodos: adicionar item no carrinho, remover item do carrinho e finalizar compra.
Objetos interagem com outros objetos através de estados (atributos), entradas (parâmetros) e retornos de métodos. No exemplo anterior o objeto usuário adiciona itens em seu carrinho de compras, mas que itens? Objetos do tipo produto e estado tem no estoque.
Herança
Um dos três pilares da programação orientada a objetos é a herança, ou seja, um dia você vai ter que dominar esse conceito e mais dois pra poder dizer que realmente sabe programação orientada a objetos. Os outros dois conceitos, ou pilares são encapsulamento e polimorfismo.
Na herança um objeto herda atributos e métodos de outro objeto. Essa herança deve ser feita com cautela. Para um objeto herdar outro objeto deve haver uma forte relação entre eles. A classe produto, por exemplo, poderia ter os herdeiros CD de áudio, filme DVD e livro. O que esses objetos têm em comum é que todos são produtos, podem ser comprados e adicionados no carrinho, tem preço, peso e dimensões. Cada um desses objetos também tem suas especialidades, senão não justificaria sua existência, apenas um bastaria. O CD de áudio tem faixas, filme tem idiomas de áudio e legenda e duração e livro tem autor, editora e páginas.
Quando um objeto herda outro objeto o herdeiro passa a ter o tipo do objeto herdado. O que isso significa? Imaginemos o método adicionar item no carrinho do objeto usuário. Esse método precisa receber um objeto do tipo produto para então adicionar no carrinho de compras. Um CD de áudio é do tipo CD de áudio, mas a medida que um objeto herda outro objeto e assume o seu tipo, então CD de áudio também é do tipo produto e poderá ser adicionado no carrinho.
Se ainda ficou um pouco confuso, pense em um restaurante que somente aceite pessoas descendentes de sua avó. Sua mãe e você poderão entrar, mas eu não, a menos que sejamos parentes, minha mãe seja irmã de sua mãe ou filha. Isso é o tipo. Objetos herdam e carregam tipos de outros objetos.
E onde entra o produto herdar a classe de banco de dados? Não entra, não há relação nisso! Muitos programadores cometem esse erro por quererem facilitar consultas ou outras operações no banco de dados. Não comenta esse erro. Objetos na vida real herdam objetos quando há uma relação entre eles, faça o mesmo na programação.