Note que:
a) É necessário usar um timer (para simplificar, usei um javax.swing.Timer). Não se deve usar Thread.sleep nesse caso.
b) Por que é que usei um timer de 0,5 segundo em vez de um de 1 segundo cravado?
Se eu usasse um timer de 1 segundo cravado, às vezes você notaria que ele iria pular um segundo na hora de exibir - isso é porque um timer de 1000 milissegundos pode, por circunstâncias que o Java não pode controlar, ficar um pouco atrasado (mas nunca adiantado). Vá reclamar com o Bill Gates
Usando um timer de 0,5 segundos, além de eu não ter esse problema de ficar pulando segundos, eu teria um erro de no máximo 0,5 segundos na exibição do relógio, o que é normalmente suficiente para a maior parte dos casos.
c) Você pode reaproveitar essa classe Relogio em qualquer lugar onde você precise mostrar a data e hora corrente. No caso do NetBeans você pode até inserir uma instância dessa classe no seu formulário
É importante manter o super() pois ele chama o construtor das classes superiores. Ter funcionado bem sem eles pode ter sido um golpe de sorte.
O @Override não é necessário, mas é fortemente recomendado. Ele indica que aquele método está sobrescrevendo um método da classe pai. Assim, se você cometer um erro de sintaxe como escrever:
public void actionPeformed(ActionEvent arg0) {
O compilador não deixará o código compilar e te dará um erro dizendo que “actionPeformed” não sobrescreve método nenhum.
É útil também para quando você tem o controle da classe pai. Usar o @Override garante que, se você alterar o nome de um método que é sobrescrito no pai, todos os filhos receberão um erro até que alterem o nome do método também.
Note que sem o @Override no lugar do erro, você acabará com dois métodos declarados (o “actionPerformed” e o “actionPeformed”), e obviamente, um programa que não funciona.
[quote=ViniGodoy]É importante manter o super() pois ele chama o construtor das classes superiores. Ter funcionado bem sem eles pode ter sido um golpe de sorte.
O @Override não é necessário, mas é fortemente recomendado. Ele indica que aquele método está sobrescrevendo um método da classe pai. Assim, se você cometer um erro de sintaxe como escrever:
public void actionPeformed(ActionEvent arg0) {
O compilador não deixará o código compilar e te dará um erro dizendo que “actionPeformed” não sobrescreve método nenhum.
É útil também para quando você tem o controle da classe pai. Usar o @Override garante que, se você alterar o nome de um método que é sobrescrito no pai, todos os filhos receberão um erro até que alterem o nome do método também.
Note que sem o @Override no lugar do erro, você acabará com dois métodos declarados (o “actionPerformed” e o “actionPeformed”), e obviamente, um programa que não funciona.[/quote]
O super() também não é necessário, a classe filha sempre chama o construtor da classe pai. Se você não especificar o construtor na filha, ele vai chamar o construtor default, e caso não existe um construtor default na classe pai, ai sim você vai ser obrigado a chamar um explicitamente, senão vai dar erro de compilação.
[quote=dm_thiago]
O super() também não é necessário, a classe filha sempre chama o construtor da classe pai. Se você não especificar o construtor na filha, ele vai chamar o construtor default, e caso não existe um construtor default na classe pai, ai sim você vai ser obrigado a chamar um explicitamente, senão vai dar erro de compilação.[/quote]
Como as regras são um pouco complicadas (você levou mais de duas linhas para explicá-las ), eu prefiro chamar eu mesmo (não, nunca fui programador Cobol e não gosto de escrever coisas a mais). Mas se é possível haver alguma confusão, opto por não haver confusão - é a mesma coisa que omitir as chaves quando o if, ou while, ou do/while; é possível mas costuma dar alguma confusão depois de alguma manutenção no código.
[quote=entanglement]
Como as regras são um pouco complicadas (você levou mais de duas linhas para explicá-las ) [/quote]
hauhauhauahuahauhauhau
[quote=entanglement]
Mas se é possível haver alguma confusão, opto por não haver confusão - é a mesma coisa que omitir as chaves quando o if, ou while, ou do/while; é possível mas costuma dar alguma confusão depois de alguma manutenção no código. [/quote]
Concordo totalmente! Só quis deixar claro que não daria problemas suprimir aquele super() ali.