I see in your program, you use the following "patterns":
I suggest abandoning these "standards" as quickly as possible and abolishing things like String[]
, Object[]
, List<String[]>
and List<Object[]>
. This comes from the fact that what you’re asking for is a XY problem.
That is, the declaration of the method should be something like this:
public List<Peca> searchPecas(
int codigoProduto,
int codigoFornecedor,
BigInteger bkSubDivisionUidD)
{
// ...
}
Note that the result is List<Peça>
and not List<Object[]>
. After all, Java is an object-oriented language, and therefore the data for a piece must be in a class Peça
and not within a Object[]
. Similarly, a method that provides a list of parts, must return List<Peça>
and not a List<Object[]>
.
Work with a Object[]
it is difficult because anything can be anywhere in any way and good luck to the poor programmer who has to deal with it, something quite different from the case of using a clearly defined class. Therefore, it is better to use a class Peça
instead of a Object[]
.
As for the parameters, the golden rule is to separate things clearly. The simplest way to do this would be to let the parameters be just simple types such as int
, String
, BigInteger
, etc. Or else, create a class to encapsulate the meaning of the parameters, such as something like this:
public final class BuscaPecasParametros {
private final int codigoProduto;
private final int codigoFornecedor;
public BuscaPecasParametros(int codigoProduto, int codigoFornecedor) {
this.codigoProduto = codigoProduto;
this.codigoFornecedor = codigoFornecedor;
}
public int getCodigoProduto() {
return codigoProduto;
}
public int getCodigoFornecedor() {
return codigoFornecedor;
}
}
And then, in the method you would put this:
public List<Peca> searchPecas(BuscaPecasParametros params) {
// ...
}
Depending on the case (you can’t know for sure only with the incomplete code of the question), it could be so too:
public List<Peca> searchPecas(
List<BuscaPecasParametros> params,
BigInteger bkSubDivisionUidD)
{
// ...
}
SQL would be built like this:
private static final String SQL_PECAS = ""
+ "\n BEGIN "
+ "\n SET NOCOUNT ON "
+ "\n DECLARE @CodigoProduto VARCHAR(10), "
+ "\n @CodigoFornecedor VARCHAR(10) "
+ "\n SET @subDivision = ? "
+ "\n SET @perfitSerial = ? ";
Yeah, use the old operator +
with String
s here. No creating StringBuilder
, StringBuffer
, append
or any of these paraphernalia because the compiler is smart enough to concatenate constant strings at compile time. If you look at the resulting bytecode, you’ll see the string already mounted by the compiler inside and the weight in performance will be so close to zero that it can’t even be measured easily, with the entire loaded string only once when the class is loaded into memory by the JVM. On the other hand, using the append
s such as you are using, the strings will eventually be built and rebuilt from several pieces each time the method is executed, which means there will be an impact on performance and garbage collector.
To see how to do the inside of the method, take a look here. You cannot put together exactly what this answer would look like because many parts of the method are missing from your question. Then I will copy the example I made in my answer to another question to be your inspiration:
private static final String SQL_ALUNOS_POR_TURMA =
"SELECT id, nome, telefone FROM alunos WHERE id_turma = ?";
public static void localizarAlunos(String turma) throws ConexaoFalhouException {
try (
Connection c = Conexao.obter();
PreparedStatement ps = c.prepareStatement(SQL_ALUNOS_POR_TURMA);
) {
ps.setString(1, turma);
try (ResultSet rs = ps.executeQuery()) {
List<Aluno> alunos = new ArrayList<>();
while (rs.next()) {
Aluno a = new Aluno();
a.setInt(rs.getInt(1));
a.setNome(rs.getString(2));
a.setTelefone(rs.getString(3));
alunos.add(a);
}
return alunos;
}
} catch (SQLException e) {
throw new ConexaoFalhouException(e);
}
}
And one more detail:
StringUtils.trim(String.valueOf(peças.getCodigoProduto()))
What? If the result of peças.getCodigoProduto()
needs to be encapsulated in a String.valueOf(...)
, then that’s probably not a string. If that’s not a string, then the StringUtils.trim(...)
is unnecessary. And even if the StringUtils.trim(...)
is necessary, the right would be the peças.getCodigoProduto()
return something that will never create spaces at the beginning or end.
+1 by the standards of Pogjetos that I didn’t even know q had names so far :p
– user28595
These Ambi design Patterns are hilarious. I’ve laughed about it :D
– Isac
Victor thanks for the clarifications. I am starting and will consider your guidance in the search for good practices.
– Pereira