Onde e quando usar um metodo?

Olá, Altom,

Primeiro, quando postar código, use as tags Code e indente para ficar mais legível.
Segundo, seu código não parece ser grande mas vc parece ter muitas dúvidas e estar fazendo alguma confusão. Então poste seu código completo assim:

ArquivoBla.java

// codigo da classe ArquivoBla aqui
//...

ArquivoBle.java

// codigo da classe ArquivoBle aqui
//...

Quanto ao baixo acoplamento e alta coesão, segue um link que tem uma boa explicação: http://jcspl.net/2007/12/17/acoplamento-e-coesao/
Mas resumindo:
Se você tem uma classe que está muito “amarrada” com outra(s), isto é um alto acoplamento.
Se você tem uma classe Televisao que possui um atributo Geladeira, isto pode ser baixa coesão pois não faz sentido ter uma geladeira dentro de uma televisão a não ser que vc tenha uma aplicação realmente muito louca.

[]s

Fala aê Altom,

Existem jeitos melhores para resolver este tipo de questão, por exemplo, usando um ArrayList ao invés de um Array comum (pesquise!). Mas eu vou considerar o escopo da discussão e falar sobre o que você pode fazer...

public class Empresa {

  private Funcionario empregados;

  void demite(Funcionario f) {
      for (int i = 0; i < this.empregados.length(); i++) {
          if (this.empregados[i].getNome() == f.getNome()) {
              f.setEstaNaEmpresa(false);
          }
          if (this.empregados[i].length() == null) {
              break;
          }
      }
  }
}

Dava para fazer com Enhanced For (pesquise também!) mas como eu disse que eu ia me limitar no êscopo da conversa, não toquei no assunto.

Espero ter ajudado!

1. Nunca compare Strings usando ==. String é um objeto, precisa ser testado com equals;

2. Seu método demite empresas ou funcionários? Esse nome está esquisito;

3. Evite código redundante, como o “this.” quando ele não é necessário.

4. É meio bizarro demitir por nome assim. Afinal, existem muitos casos de pessoas com mesmo nome. Para evitar demitir um homônimo de alguém por engano, use a matricula ou o id.

É assim que eu escreveria o método:

boolean demite(Funcionario demitido) { for(Funcionario funcionario : empregados){ if (funcionario == null || funcionario.getNome().equals(demitido.getNome())) funcionario.demite(); return true; } } return false; }

Obrigado pela resposta iogui!

na verdade não chega a ser um codigo… foi mais um pequeno exemplo, eu tinha identado o codigo… mas na hora que postei, ele bagunçou tudo você utilizou o eclipse para postar ele identado corretamente? , quanto ao exemplo que dei, usar um metodo de uma classe para chamar um outro metodo de outra classe, li o texto que você passou e (acho) que entendi, a coesão esta correta pois empresa tem empregados que na verdade são funcionarios, agora quanto a dependencia ou acoplamento, o metodo que chama o metodo de outra classe, fica dependente, então fiquei com outra duvida agora, considero altamente acoplado, porque eu tenho que chamar um metodo de uma classe através de outra ou fracamente acoplado pois, se eu alterar internamente o metodo chamado, não fara diferença pois (pelo que li ) “o que importa e o que faz não como faz”.

Não tenho pratica em programação, aprendi c e c++ na faculdade a uns 3 anos, agora comecei a estudar java, não para area profissional, mesmo porque como você disse tenho duvidas e faço confusão… :lol: por enquanto é so por curiosidade mesmo, fora que eu “simpatizei” com o java.

so mais duvida, no exemplo eu usei um array de funcionarios chamado empregados, então (acho) quem tem que contralar o que sera feito com o array de uma classe é a classe que a instanciou.

Novamente agradeço a ajuda! caso eu tenha entendido algo errado criticas serão bem vindas!

Por que você faria o setter? Isso dá o direito de anular a demissão de um funcionário. Normalmente, isso não é feito sem uma nova matricula funcional, e isso realmente é uma operação sem volta. Não deveria haver um comando para “des-demitir”.

Não, usamos a tag code:

Obrigado BernardoCSantos!

eu tinha visto algo sobre arrayList, mas acabei reiventando a roda :oops: :lol:

pois eu fiz o setters e getters desta classe, mas sua explicação foi bem interessante! quem demite é a empresa não o proprio funcionario :oops: :oops: :oops: com relação a uma coisa, é certo criar um metodo para pesquisar o funcionario no array empregados ou tem outra forma? pois não tem como o proprio funcionario se demitir(a não ser que ele trabalhe no rh hehe) digo ele não vai poder controlar o array empregados, ja que ele foi instanciado dentro de outra classe? ou não?

Não, usamos a tag code:

Obrigado ViniGodoy!

Por que você faria o setter? Isso dá o direito de anular a demissão de um funcionário. Normalmente, isso não é feito sem uma nova matricula funcional, e isso realmente é uma operação sem volta. Não deveria haver um comando para “des-demitir”.

Humn (acho) que entendi… o id que você tinha comentando é a mesma coisa que a matricula funcional?

ViniGodoy:

1. Nunca compare Strings usando ==. String é um objeto, precisa ser testado com equals;

2. Seu método demite empresas ou funcionários? Esse nome está esquisito;

3. Evite código redundante, como o “this.” quando ele não é necessário.

4. É meio bizarro demitir por nome assim. Afinal, existem muitos casos de pessoas com mesmo nome. Para evitar demitir um homônimo de alguém por engano, use a matricula ou o id.

É assim que eu escreveria o método:

boolean demite(Funcionario demitido) { for(Funcionario funcionario : empregados){ if (funcionario == null || funcionario.getNome().equals(demitido.getNome())) funcionario.demite(); return true; } } return false; }

Obrigado ViniGodoy!

1. equals humn… novidade para mim… vou pesquisar…

2. Funcionarios no caso… mas quem demite é a empresa correto, e o funcionario esta no array empregados do objeto empresa instanciado, como não sei a posição que o funcionario esta no array fiz este codigo estranho, mas (acho) que estou confundindo o metodo demitir com o “metodo esta na empresa” ou melhor setEstaNaEmpresa que fica no proprio funcionario, na verdade o demitir da empresa alteraria o valor do atributo boolean estaNaEmpresa no objeto funcionario ou seja demitir, chama o objfuncioraio.setEstaNaEmpresa(false), acho que meu problema é abstração, espero ter entendido corretamente.

3. Pensava que o this era “obrigado” pois eu quando recebia um objeto, eu tinha que me referir a ele proprio. (na verdade ja pesquisei este assunto mas nunca entendi direito) :oops: se tiver algum exemplo “simples” eu agradeço.

4. no outro exemplo eu usei um id, mas era so um codigo de exemplos simples pois minha duvida era quanto um metodo de uma classe chamando um metodo dentro de outra classe.

Altom,

Quanto ao acoplamento, vou te dar um exemplo. Veja:

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
		//Iniciando aleatoriamente alguns funcionários
		funcionarios = new ArrayList<Funcionario>();
		
		funcionarios.add(new Funcionario("João"));
		funcionarios.add(new Funcionario("José"));
		funcionarios.add(new Funcionario("Maria"));
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}
}

Neste código, podemos dizer que a classe Empresa tem um forte acoplamento da classe Funcionario. Imagine que eu tenha uma outra classe qualquer que também use a classe Funcionario, por exemplo uma classe “Industria” e eu fizer uma alteração no código da classe Funcionario. Esta alteração vai acabar refletindo indiretamente, tanto na classe Empresa, quanto na classe Industria pois as duas usam a classe Funcionario.
E isto significa que, se uma aplição tiver várias classes diferentes que usem a classe Funcionario, eu vou ter que tomar muito cuidado ao alterá-la pois posso causar algum comportamento inesperado em outra parte do sistema.
Agora imaginemos que, para evitar este problema, eu resolva criar uma classe FuncionarioEmpresa específica para a empresa de forma a não alterar o comportamento de todas as outras classes que dependem da classe Funcionario.
O problema que vou ter é que terei que alterar um monte de coisas na classe Empresa pois existe um forte acoplamento entre a classe Empresa e a classe Funcionario.
A grande questão é, como eu poderia ter desenvolvido este código de forma a ter um fraco acoplamento logo de início?
Pra começar, poderíamos tirar a dependência da crasse concreta Funcionario passando para uma interface, desta forma:

public interface Funcionario {
}


public class FuncionarioEmpresa implements Funcionario {
	private String nome;
	
	public FuncionarioEmpresa(String nome){
		this.nome = nome;
	}
}

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
		//Iniciando aleatoriamente alguns funcionários
		funcionarios = new ArrayList<Funcionario>();
		
		funcionarios.add(new FuncionarioEmpresa("João"));
		funcionarios.add(new FuncionarioEmpresa("José"));
		funcionarios.add(new FuncionarioEmpresa("Maria"));
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}
}

Isto já vai diminuir bastante o acoplamento pois agora já não dependo de uma classe concreta e sim de uma interface. Desta forma a classe concreta pode ser alterada facilmentsem afetar seu uso no método “trabalhaPeao” que só conhece a interface Funcionario e não sua classe concreta.

Para completar, poderíamos tentar nos livrar da palavra chave “new”, geralmente onde ela aparece, costuma ter um acoplamento mais forte. Pra fazer isto, poderíamos passar esta responsabilidade para fora da classe, desta forma:

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}

	public void setFuncionarios(List<Funcionario> funcionarios) {
		this.funcionarios = funcionarios;
	}
	
}

Agora, eu teria que dar um jeito de chamar o setter de Funcionarios em algum outro lugar, entretanto, acabei de vez com o forte acoplamento entre a classe empresa e a classe concreta de Funcionario (FuncionarioEmpresa no caso). Perceba que não tem mais nem mensão da classe FuncionarioEmpresa dentro da classe empresa. Desta forma, o acoplamento ainda existe mas ele passou a ser fraco pois está em um ponto isolado, que é na classe que vai ser Responsável por settar os funcionários, e isto pode ser feito com controle, em um lugar próprio para isto. Isto é chamado de Injeção de Dependências. Eu não tenho mais a criação das minhas dependências dentro da classe, pelo contrário, eu deleguei esta responsábilidade. Eu injeto as dependências.

Resumindo, o uso de interfaces e do padrão de projetos DI (Dpendency Ingection), é uma das melhores formas de você conseguir um fraco acoplamento.

Pra completar, aqui segue um link pra quem quiser entender um pouco mais desta mágica:
http://javafree.uol.com.br/artigo/871453/

Putz… acho que escrevi um tutorial… rs

[]s

iogui:

Altom,

Quanto ao acoplamento, vou te dar um exemplo. Veja:

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
		//Iniciando aleatoriamente alguns funcionários
		funcionarios = new ArrayList<Funcionario>();
		
		funcionarios.add(new Funcionario("João"));
		funcionarios.add(new Funcionario("José"));
		funcionarios.add(new Funcionario("Maria"));
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}
}

Neste código, podemos dizer que a classe Empresa tem um forte acoplamento da classe Funcionario. Imagine que eu tenha uma outra classe qualquer que também use a classe Funcionario, por exemplo uma classe “Industria” e eu fizer uma alteração no código da classe Funcionario. Esta alteração vai acabar refletindo indiretamente, tanto na classe Empresa, quanto na classe Industria pois as duas usam a classe Funcionario.
E isto significa que, se uma aplição tiver várias classes diferentes que usem a classe Funcionario, eu vou ter que tomar muito cuidado ao alterá-la pois posso causar algum comportamento inesperado em outra parte do sistema.
Agora imaginemos que, para evitar este problema, eu resolva criar uma classe FuncionarioEmpresa específica para a empresa de forma a não alterar o comportamento de todas as outras classes que dependem da classe Funcionario.
O problema que vou ter é que terei que alterar um monte de coisas na classe Empresa pois existe um forte acoplamento entre a classe Empresa e a classe Funcionario.
A grande questão é, como eu poderia ter desenvolvido este código de forma a ter um fraco acoplamento logo de início?
Pra começar, poderíamos tirar a dependência da crasse concreta Funcionario passando para uma interface, desta forma:

public interface Funcionario {
}


public class FuncionarioEmpresa implements Funcionario {
	private String nome;
	
	public FuncionarioEmpresa(String nome){
		this.nome = nome;
	}
}

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
		//Iniciando aleatoriamente alguns funcionários
		funcionarios = new ArrayList<Funcionario>();
		
		funcionarios.add(new FuncionarioEmpresa("João"));
		funcionarios.add(new FuncionarioEmpresa("José"));
		funcionarios.add(new FuncionarioEmpresa("Maria"));
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}
}

Isto já vai diminuir bastante o acoplamento pois agora já não dependo de uma classe concreta e sim de uma interface. Desta forma a classe concreta pode ser alterada facilmentsem afetar seu uso no método “trabalhaPeao” que só conhece a interface Funcionario e não sua classe concreta.

Para completar, poderíamos tentar nos livrar da palavra chave “new”, geralmente onde ela aparece, costuma ter um acoplamento mais forte. Pra fazer isto, poderíamos passar esta responsabilidade para fora da classe, desta forma:

public class Empresa {
	private List<Funcionario> funcionarios;
	
	public Empresa(){
	}
	
	public void trabalhaPeao(){
		// código que justifique a existencia dos objetos funcionários
	}

	public void setFuncionarios(List<Funcionario> funcionarios) {
		this.funcionarios = funcionarios;
	}
	
}

Agora, eu teria que dar um jeito de chamar o setter de Funcionarios em algum outro lugar, entretanto, acabei de vez com o forte acoplamento entre a classe empresa e a classe concreta de Funcionario (FuncionarioEmpresa no caso). Perceba que não tem mais nem mensão da classe FuncionarioEmpresa dentro da classe empresa. Desta forma, o acoplamento ainda existe mas ele passou a ser fraco pois está em um ponto isolado, que é na classe que vai ser Responsável por settar os funcionários, e isto pode ser feito com controle, em um lugar próprio para isto. Isto é chamado de Injeção de Dependências. Eu não tenho mais a criação das minhas dependências dentro da classe, pelo contrário, eu deleguei esta responsábilidade. Eu injeto as dependências.

Resumindo, o uso de interfaces e do padrão de projetos DI (Dpendency Ingection), é uma das melhores formas de você conseguir um fraco acoplamento.

Pra completar, aqui segue um link pra quem quiser entender um pouco mais desta mágica:
http://javafree.uol.com.br/artigo/871453/

Putz… acho que escrevi um tutorial… rs

[]s

Poxa iogui brigadão mesmo!! você quase não digitou ne hehe…magica é alguem ter paciencia para escrever tanto!! mais uma coisa não ache, tenha certeza!!! você escreveu um excelente tutorial que com certeza vai me ajudar… e ajudar outros que tenham duvidas parecidas!!

Sim Sim!
Tinham algumas falhas conceituais e de sintaxe lá! Falha minha! >.<

Não falei de equals() pois, como eu havia dito, eu não queria fugir do escopo do tópico. E o "this", de fato, não é obrigatório nesse caso, mas é considerado boa prática sempre usá-lo.

E de fato, eu também achei esquisito comparar funcionários pelo nome. Então eu acho que seria uma boa hora para explicar o equals().

Primeiramente, o que é uma igualdade né? O que faz com que duas coisas sejam iguais? Provavelmente você tem muitas respostas para isso, pois isso pode variar de situação em situação.

Por exemplo: Dadas duas variáveis do tipo inteiro x e y, o que faz com que a operação (x == y) retorne True? Em outras palavras, qual o conceito de igualdade entre dois inteiros? Simples! Basta que o valor desses inteiros sejam equivalentes!

Seguindo o mesmo raciocínio, dadas duas variáveis de referência, f1 e f2, que apontam, cada uma, para um objeto do tipo Funcionario.
Agora, como nós estamos tratando de objetos, não podemos iguala-los com o operador "==". Por isso existe um método herdado da classe Object (pesquisar sobre a classe Object), que toda classe possui, chamado equals().
Então, retomando o raciocínio, podemos agora igualar o f1 e f2 desta maneira: f1.equals(f2) (lê-se "f1 é igual a f2?"). Mas o que será que vai retornar, julgando que os objetos de f1 e f2 possuem os valores dos seus atributos idênticos?
FALSE! Sim! False! Mais uma vez... False!
"Ué! Mas por que?"... Lembra quando eu fiz isso com as variáveis do tipo inteiro e perguntei "qual o conceito de igualdade entre dois inteiros"? Então, agora me responda: qual o conceito de igualdade entre dois Funcionarios?

Para entender, experimente dar System.out.println(f1), por exemplo. O retorno vai ser algo do tipo: Funcionario@57c4f74a.

"Mas que p**** é essa?"
Respectivamente, o tipo da classe do objeto, e seu HashCode(pesquise). Isso funciona como um tipo de ID do objeto, que fica armazenado na sua variável de referência. Entenda isso como um pequeno mapa que explica a direção para determinado objeto. E esse mapa fica com a variável de referência que está apontando para este objeto.

"O que que isso tem a ver com o equals()?"
Simples! O equals() original, ou seja, se não for sobreescrito, ele comparar esse ID do objeto nas duas variáveis. Por isso que se você fizer com que f2 aponte para o mesmo objeto de f1 (f2 = f1), o f2 receberá o ID do objeto que o f1 aponta e apartir desse momento o equals() será true. Entendeu? Deu true porque o as duas variáveis apontam para o mesmo objeto, pois ambos tem o mesmo ID.

"Beleza! Saquei isso... mas o que eu tenho que fazer pra quando eu chamar o equals() ele testar apenas aquilo que eu quero?"
Simples! Sobreescreva o equals()! No exemplo do Altom, ele compara os Funcionarios pelo nome. Logo, para ele, o conceito de igualdade entre Funcionarios é que se dois funcionarios possuem nomes idênticos, os mesmos são iguais. Neste caso, então, reescreveríamos o equals() desta maneira:

public class Funcionario{ 

  // seus métodos e atributos

  public boolean equals(Object obj) {                            // Recebe qualquer classe do tipo Object (Pesquise sobre a classe Object)
    Funcionario funcionario = (Funcionario) obj;            // Faz casting do tipo Object para o tipo Funcionario
    if (this.getNome().equals(funcionario.getNome()) { // Testa se os nomes coincidem
      return true;                                                              // Retorna True se verdadeiro
    }
  return false;                                                                // Retorna False se falhar no teste
  }
}

Pronto! Agora, sempre que você quiser igualar 2 objetos do tipo Funcionario com o equals(), o código acima irá rodar e lhe passar o resultado de acordo com os dados que você informou.

Entende agora? Tudo depende do seu conceito de igualdade. Mesmo assim, eu continuo achando que comparar dois Funcionários pelo nome pode não dar certo. Experimente criar um campo chamado ID, e gerar um ID único para cada Funcionário.

Anyway... Passei o conhecimento adiante, mas acho que vale a pena você pesquisar bastante Altom. Recomendo a leitura do livro Head First Java, ou então procure baixar uma apostila gratuita na internet!

Bom... espero ter ajudado!

[]'s

ViniGodoy:

…

É assim que eu escreveria o método:

boolean demite(Funcionario demitido) { for(Funcionario funcionario : empregados){ if (funcionario == null || funcionario.getNome().equals(demitido.getNome())) funcionario.demite(); return true; } } return false; }

if(funcionario != null && funcionario.getNome().equals(demitido.getNome()))

Posso estar enganado, mas acho que do jeito que voce colocou pode dar nullpointerexception…

BernardoCSantos:

Sim Sim! Tinham algumas falhas conceituais e de sintaxe lá! Falha minha! >.<

Não falei de equals() pois, como eu havia dito, eu não queria fugir do escopo do tópico. E o "this", de fato, não é obrigatório nesse caso, mas é considerado boa prática sempre usá-lo.

E de fato, eu também achei esquisito comparar funcionários pelo nome. Então eu acho que seria uma boa hora para explicar o equals().

Primeiramente, o que é uma igualdade né? O que faz com que duas coisas sejam iguais? Provavelmente você tem muitas respostas para isso, pois isso pode variar de situação em situação.

Por exemplo: Dadas duas variáveis do tipo inteiro x e y, o que faz com que a operação (x == y) retorne True? Em outras palavras, qual o conceito de igualdade entre dois inteiros? Simples! Basta que o valor desses inteiros sejam equivalentes!

Seguindo o mesmo raciocínio, dadas duas variáveis de referência, f1 e f2, que apontam, cada uma, para um objeto do tipo Funcionario.
Agora, como nós estamos tratando de objetos, não podemos iguala-los com o operador "==". Por isso existe um método herdado da classe Object (pesquisar sobre a classe Object), que toda classe possui, chamado equals().
Então, retomando o raciocínio, podemos agora igualar o f1 e f2 desta maneira: f1.equals(f2) (lê-se "f1 é igual a f2?"). Mas o que será que vai retornar, julgando que os objetos de f1 e f2 possuem os valores dos seus atributos idênticos?
FALSE! Sim! False! Mais uma vez... False!
"Ué! Mas por que?"... Lembra quando eu fiz isso com as variáveis do tipo inteiro e perguntei "qual o conceito de igualdade entre dois inteiros"? Então, agora me responda: qual o conceito de igualdade entre dois Funcionarios?

Para entender, experimente dar System.out.println(f1), por exemplo. O retorno vai ser algo do tipo: Funcionario@57c4f74a.

"Mas que p**** é essa?"
Respectivamente, o tipo da classe do objeto, e seu HashCode(pesquise). Isso funciona como um tipo de ID do objeto, que fica armazenado na sua variável de referência. Entenda isso como um pequeno mapa que explica a direção para determinado objeto. E esse mapa fica com a variável de referência que está apontando para este objeto.

"O que que isso tem a ver com o equals()?"
Simples! O equals() original, ou seja, se não for sobreescrito, ele comparar esse ID do objeto nas duas variáveis. Por isso que se você fizer com que f2 aponte para o mesmo objeto de f1 (f2 = f1), o f2 receberá o ID do objeto que o f1 aponta e apartir desse momento o equals() será true. Entendeu? Deu true porque o as duas variáveis apontam para o mesmo objeto, pois ambos tem o mesmo ID.

"Beleza! Saquei isso... mas o que eu tenho que fazer pra quando eu chamar o equals() ele testar apenas aquilo que eu quero?"
Simples! Sobreescreva o equals()! No exemplo do Altom, ele compara os Funcionarios pelo nome. Logo, para ele, o conceito de igualdade entre Funcionarios é que se dois funcionarios possuem nomes idênticos, os mesmos são iguais. Neste caso, então, reescreveríamos o equals() desta maneira:

public class Funcionario{ 

  // seus métodos e atributos

  public boolean equals(Object obj) {                            // Recebe qualquer classe do tipo Object (Pesquise sobre a classe Object)
    Funcionario funcionario = (Funcionario) obj;            // Faz casting do tipo Object para o tipo Funcionario
    if (this.getNome().equals(funcionario.getNome()) { // Testa se os nomes coincidem
      return true;                                                              // Retorna True se verdadeiro
    }
  return false;                                                                // Retorna False se falhar no teste
  }
}

Pronto! Agora, sempre que você quiser igualar 2 objetos do tipo Funcionario com o equals(), o código acima irá rodar e lhe passar o resultado de acordo com os dados que você informou.

Entende agora? Tudo depende do seu conceito de igualdade. Mesmo assim, eu continuo achando que comparar dois Funcionários pelo nome pode não dar certo. Experimente criar um campo chamado ID, e gerar um ID único para cada Funcionário.

Anyway... Passei o conhecimento adiante, mas acho que vale a pena você pesquisar bastante Altom. Recomendo a leitura do livro Head First Java, ou então procure baixar uma apostila gratuita na internet!

Bom... espero ter ajudado!

[]'s

Se ajudou? sem dúvida BernardoCSantos!!! :D :D obrigado pela ajuda!!! :wink: meu inglês é bem ruim.. :( se não me engano acho que ja vi este livro em português em uma livraria.. com certeza pesquisarei sobre os assuntos que você indicou, espero conhecer tanto quanto vocês com o tempo! sei que depende de dedicação e estudo. vou me esforçar.. :wink: