modificadoresDeAcesso TipoDeDadoDoRetorno nomeDoMetodo(TipoDeDadoDoParametro é um objeto ( variável que recebeu uma classe) nomeDoParametro) {
// Corpo do método
}
Este método abaixo é uma cópia quase exata do “main” com a diferença de não atribuir valores ao objeto cliente1 que é uma instanciação da Classe ContaCorrente, arquivo separado dentro do mesmo package:
condição dentro do método main que invoca:
if (opcao == 2) {
cliente1.consultarSaldo(); telaInicialSemAtribuicoes(cliente1); <<<<========
}
método:
static void telaInicialSemAtribuicoes( Class cliente1 ){
Scanner scan = new Scanner(System.in);
int opcao = menuBanco();
if (opcao == 1) {
double total = 0;
System.out.println("Digite a quantia que quer sacar.");
double quantiaPedidoSaque = scan.nextDouble();
boolean pedidoSaque = cliente1.estadoParaSaque(quantiaPedidoSaque);
if (pedidoSaque) {
total = cliente1.sacarDinheiro(quantiaPedidoSaque);
System.out.println("O novo saldo é: R$" + cliente1.saldo);
} else {
System.out.println("Você não tem saldo e/ou limite suficiente"
+ " para efetuar este saque.");
}
retornaAoMenu(); // AQUI, FAREI UM OUTRO MÉTODO IGUAL AO MAIN, MAS SEM ATRIBUIR VALORES
// PARA OS ATRIBUTOS DA CONTA CORRENTE
}
if (opcao == 2) {
cliente1.consultarSaldo();
telaInicialSemAtribuicoes(cliente1);// AQUI, FAREI UM OUTRO MÉTODO IGUAL AO MAIN, MAS SEM ATRIBUIR VALORES
// PARA OS ATRIBUTOS DA CONTA CORRENTE
}
if (opcao == 3) {
cliente1.consultarSaldo();
retornaAoMenu();// AQUI, FAREI UM OUTRO MÉTODO IGUAL AO MAIN, MAS SEM ATRIBUIR VALORES
// PARA OS ATRIBUTOS DA CONTA CORRENTE
}
if (opcao == 4) {
cliente1.consultarChequeEspecial();
}
if (opcao == 5) {
System.exit(0);
}
}
Bom, parece que consegui resolver, tornando a variável cliente1, global, sem ter apresentado erro de sintaxe, vamos ver se não vai dar erro de lógica.
No escopo global:
static ContaCorrente cliente1 = new ContaCorrente();
Se “cliente1” é uma instância de “ContaCorrente”, acredito que no parâmetro do método “telaInicialSemAtribuicoes” você deveria trocar “Class cliente1” por “ContaCorrente cliente1”. Não seria isso? Ou então, usar o tipo “Object” no lugar de “Class”.
OBS: Objetos da classe “Class” fazem referência a uma classe num contexto em que você precisa “mapear” a estrutura de uma classe, de forma a uma classe tomar “ciência” de como ela própria é composta, como, por exemplo, se você quiser imprimir na tela quais são os métodos de uma determinada classe para fazer a documentação de como ela foi feita. Nesse caso sim, usaria uma instância de “Class” e outra de “Method”. Essas classes pertencem a API java.lang.reflect. Caso já seja a inteção utilizá-la, não percebi a intenção.
Eu tentei isso, mas nada adiantou. Deve ser porque se vc chegar a precisar usar algo assim, é desnecessário, tendo em vista que um objeto em escopo global resolve.
Esses caras das IDE pensam em tudo o que é conhecido, só não pensam em algo que ninguém imaginou usar ainda.
Outra coisa, Java não tem escopo global.
Você tem escopo local (dentro de métodos e blocos), de instância (declarado na corpo da classe) ou de classe (declarado na corpo da classe como static).
A IDE só segue o lexema, sintaxe e semântica da linguagem. Se o programador faz algo que foge disso, está errado.
Qual o erro? Provavelmente estava no caminho certo.
Nesse caso, basta que o objeto esteja na mesma classe e fora do bloco de algum método que será visível para os demais métodos. Modificadores de visibilidade remetem ao que pode ser acessado à partir de outra classe. Sugiro este artigo sobre modificadores: https://www.devmedia.com.br/metodos-atributos-e-classes-no-java/25404
O modificador static não trata de visibilidade, mas sim de indicar que o elemento pertence a classe e não ao objeto que será instanciado à partir dessa classe. No seu caso, o static diz que se você se referir a este objeto à partir de uma classe diferente, não poderá criar uma instância deste elemento. Creio que seja desnecessário para seu caso.