DEV Community: Cassio Menezes

Do You Like Pasta? Your Java Code Might!

Cassio Menezes — Fri, 21 Mar 2025 12:59:59 +0000

What if I told you that a fully functional piece of code would be the worst thing that could happen to your project? Consider a single Java class that spans 1276 lines and manages everything from database transactions to user prompts. It would be twisted up like spaghetti. It functions correctly, but when you need to add a feature, fix a bug, or bring on a new developer, things go bananas. This is the real code from a production system, a class named BtnGeraSerrada.java; it is not an invented horror story. I'm not here to judge; the developer who wrote it did the best they could with the time and resources they had. Instead, let's disassemble this beast to reveal the obscure dangers associated with spaghetti code, as this functional mess now could turn into a maintenance headache tomorrow.

Spaghetti code enters projects under the false pretense of "getting the job done" rather than making an announcement with flashing red warnings. A textbook example is the BtnGeraSerrada.java class I'm presenting, a massive, 1276-line monolith that controls an industrial process to generate sawing operations. It has all the functionality needed to manage transactions, create database entries, validate inputs, and even prompt users in a single location. Though it does not crash, its quality, maintainability, and scalability are all at risk. Let's investigate some of its visible code smells, which are based on fundamental software engineering concepts, and give a sneak peek at improved procedures that we'll discuss in later posts.

You can find the source code on my Gist https://gist.github.com/cassioborgesmenezes/e938db268a431b9928f9fd3308fdc802

Code Smell #1: The God Class

Robert C. Martin highlights the Single Responsibility Principle (SRP) in Clean Code, which states that a class should only have just one reason to change (Martin, 2008). However, BtnGeraSerrada is a "God Class," capable of handling anything from business logic (criaProducao) and persistence (NotaHelper.confirmarNotas) to user interface interactions (contexto.confirmarSimNao). With over a dozen methods, several of which include more than 100 lines, it is a master of none and a jack-of-all-trades. If you have to make changes to this giant when a database schema or a new user interface requirement arrives, this could have unexpected consequences. In contrast, Martin Fowler suggests in Refactoring that one should break huge classes into simpler, focused units (Fowler, 2018). Consider dividing this into three distinct components, each with a distinct function: SawingOrchestrator, DataPersister, and UserPromptService.

Code Smell #2: Long Methods and Poor Readability

Observe the go method, which is a complex web of nested transactions, loops, and conditionals that spans more than 100 lines. Joshua Bloch promotes simplicity and clarity in Effective Java (Bloch, 2017). Long methods like this are harder to read, debug, or test, particularly if variables like movimentosReference change across scopes. According to the Gang of Four in Design Patterns, a more refined approach would use the Command or Strategy pattern to divide tasks like note confirmation or header construction into distinct, reusable units (Gamma et al., 1994). Shorter methods with descriptive names, such confirmSawingNotes, would tell a story rather than hide it.

    public BtnGeraSerrada(final ContextoAcao contexto) throws Exception{
        go(contexto);
    }

    public BtnGeraSerrada() throws Exception{
    }

    private void go(final ContextoAcao contexto) throws Exception {

        int qtdLinhas = contexto.getLinhas().length;

        if (qtdLinhas > 1) {
            contexto.mostraErro("Selecione apenas uma OP");
            return;
        }

        final Registro[] linhas = contexto.getLinhas();
        final BigDecimal id = (BigDecimal) linhas[0].getCampo("ID");
        String status = (String) linhas[0].getCampo("STATUS");

        if (status == null) {
                status = "0";
        }
        if (status.equals("0")) {
            contexto.mostraErro("Ainda nao foram geradas as chapas!");
            return;
        }
        if (status.equals("3") || status.equals("2")) {
            contexto.mostraErro("Essa Serrada ja foi finalizada!");
            return;
        }

        boolean Confirma = contexto.confirmarSimNao("Gerar Serrada", "Confirma serragem do bloco?", 1);

        if (!Confirma){
            return;
        }

        final ConfirmaNotaTxManual confirma = new ConfirmaNotaTxManual();
         JapeSession.putProperty("br.com.sankhya.ctclasse.processando", Boolean.TRUE);
         final FinalWrapper<ArrayList<BigDecimal>> movimentosReference = new FinalWrapper<ArrayList<BigDecimal>>();

        /* Cria Cabeçalho da requisicao do bloco*/             
                SessionHandle hnd = null;
                hnd = JapeSession.open();   
                hnd.setCanTimeout(false);
                System.out.println("TESTE 85");
                hnd.execWithTX(new JapeSession.TXBlock() {
                    @Override
                    public void doWithTx() throws Exception {

                            ArrayList<BigDecimal> m = new ArrayList<BigDecimal>();
                            DynamicVO opVO = (DynamicVO) EntityFacadeFactory.getDWFFacade().findEntityByPrimaryKeyAsVO("SERCAB2", new Object[] { id });

                            m.add(criaReqbloco(contexto));
                            m.add(criaProducao(contexto));
                            if("S".equals(opVO.asString("TERCEIRO")))
                            m.add(criaProducao(contexto, Boolean.TRUE));
                            linhas[0].setCampo("OP", m.get(1));
                            linhas[0].save();

                            System.out.println("TESTE 100");
                            movimentosReference.setWrapperReference(m); 
                    }
                });

                System.out.println("TESTE 105");
                ArrayList<BigDecimal> movimentos = movimentosReference.getWrapperReference();
                JapeSession.close(hnd);
                System.out.println("TESTE 108");
                NotaHelper.confirmarNotas(movimentos);

                for(BigDecimal movimento : movimentos) {
                    if (!movimento.equals(BigDecimal.ZERO)) {
                            confirma.confirmarNota(movimento, true);
                            bloquearNota(movimento);
                        }
                }

                 final FinalWrapper<ArrayList<BigDecimal>> movimentoBaixa = new FinalWrapper<ArrayList<BigDecimal>>();

                    /* Cria Cabeçalho da requisicao do bloco*/             


                            hnd = JapeSession.open();

                            hnd.execWithTX(new JapeSession.TXBlock() {
                                @Override
                                public void doWithTx() throws Exception {

                                        ArrayList<BigDecimal> m = new ArrayList<BigDecimal>();

                                        //m.add(criaReqbloco(contexto));
                                        m.add(criaReqBaixaInsumos(contexto, id));
                                        insereCusto(contexto, id);
                                        //criaReqEntera(contexto);
                                        /*
                                            m.add(criaReqBaixaInsumos(contexto, id));
                                            m.add(criaProducao(contexto));
                                            linhas[0].setCampo("OP", m.get(3));
                                            linhas[0].save();
                                        */
                                        movimentoBaixa.setWrapperReference( m   );

                                }
                            });
                            JapeSession.close(hnd);

                            ArrayList<BigDecimal> movimentosBaixa = movimentosReference.getWrapperReference();
                            NotaHelper.confirmarNotas(movimentosBaixa);
                            for(BigDecimal movimento : movimentosBaixa) {
                                if (!movimento.equals(BigDecimal.ZERO)) {
                                        bloquearNota(movimento);
                                    }
                            }


        atualizaStatus(contexto);

        GeraNFT(contexto);

        JapeSession.putProperty("br.com.sankhya.ctclasse.processando", Boolean.FALSE);

        contexto.setMensagemRetorno("Fim da operacao!!");


    }

Code Smell #3: Tight Coupling and Transaction Chaos

The class has a problem of tight coupling; it is tied to particular implementations by direct calls to EntityFacadeFactory, JapeSession, and utility classes like NotaHelper. You're rewriting half the class if the database layer changes. To make matters worse, there are tons of JapeSession.open() and execWithTXsections dispersed about, increasing the risk of partial commits or leaks. As a way to decouple the process logic from the infrastructure, Fowler's Refactoring recommends removing dependencies and putting them into interfaces (such as a TransactionManager) (Fowler, 2018). This diminishes fragility and complies with SOLID's Dependency Inversion Principle.

Code Smell #4: Error Handling as an Afterthought

BtnGeraSerradahandles errors inconsistently; some methods throw raw Exceptions, others use contexto.mostraErro(), and many don't have the right recovery logic or logging. Martin's Clean Code stresses the need for meaningful and purposeful exceptions (Martin, 2008). Instead of merely leaving users with unclear popup warnings, a centralized error-handling approach - perhaps a specific SawingExceptionwith logging - would make failures traceable and recoverable.

A Real-World Warning

This code is being used in a live system, so it is not broken. However, there are real costs that come with its complexity: adding functionality feels like defusing a bomb, problems hide in its deepest parts, and onboarding new devs takes weeks. The lesson? Functionality alone isnt enough. As Bloch points out, “Good code is not just about working today — it’s about thriving tomorrow” (Bloch, 2017). We'll refactor this monster in upcoming articles, using principles and patterns to create a sustainable masterpiece. Let that be a lesson in what not to do for the time being.

Takeaways

Beware the God Class: A class that reacts inappropriately to SRP and encourages fragility should divide roles to promote resilience and clarity.

Keep It Short and Sweet: Use concise, easily understandable language; lengthy approaches obfuscate intent.

Decouple to Survive: Tight coupling to dependencies restricts your flexibility; instead, employ interfaces and inversion of control.

Handle Errors with Care: Blind spots are caused by inconsistent exception handling; consolidate and appropriately log them.

Quality Is Worthier Than Speed: Invest in structure up front as functional spaghetti code now will cost you badly tomorrow.

Spaghetti code is a debt that accumulates interest, yet it could help you accomplish a deadline. In your projects, have you had to deal with a confusing web like BtnGeraSerrada? Which poor habits have you observed transforming functional code into headaches for maintenance? Tell me about your experiences solving (or suffering) code quality challenges in the comments below!

Full disclosure: this article was written with the aid of Grok, an AI built by xAI, who helped me organize my ideas and polish the content. The concepts and insights, however, are based on my own daily experiences as a coder.

Why One-Class Java Heroes Are Killing Your Project's Quality

Cassio Menezes — Wed, 12 Mar 2025 23:05:42 +0000

Have you ever looked at a tangled web of Java code and wondered, “How did it get this complicated?” As Software Engineers, we’ve all dealt with overcrowded classes or brittle workflows. Quality code is not created by chance; it is designed with purpose. What if I told you that delegating tasks and orchestrating workflows might turn your Java projects into maintainable masterpieces? Let’s look at an actual example of Clean Code and Best Practices in action.

Suppose you’re developing a Java system for handling data — say, a Header containing Items — and save it in a database. The process is triggered by a user event via a Service Provider, and each step must be completed in order: process the data, then store it. It’s easy to put everything into a single class: parsing, validation, and database logic. But here’s where Clean Code and SOLID’s Single Responsibility Principle (SRP) come to the rescue.

As a Software Engineer, sticking to SRP means providing each class one job. Combining data processing and persistence in a single class violates this concept. Why? Processing logic may change as the input format evolves, and persistence logic changes with database updates — two unrelated reasons to modify the same class. Instead, separate them:

HeaderAndItemsProcessor: Parses and structures the data.
DataPersister: Handles database writes.

But how do you integrate these steps into a sequence? Enter the service layer, a DataProcessingService that orchestrates the workflow. This coordinator receives raw input, passes it to the processor, and finally passes the final result to the persister. The user event triggers the Service Provider, which simply calls this service. Here’s a simplified version of Java:

public class DataProcessingService {
    private final HeaderAndItemsProcessor processor;
    private final DataPersister persister;

    public DataProcessingService(HeaderAndItemsProcessor processor, DataPersister persister) {
        this.processor = processor;
        this.persister = persister;
    }

    public void processAndPersist(String rawData) {
        Header header = processor.processData(rawData);
        persister.persist(header);
    }
}

Details on Gist

This design is more than just following the rules; it is about quality. Separating concerns makes your code testable (mock the persister!), flexible (switch databases quickly!) and readable (each class tells its own story). This technique aligns with Best Practices for Software Engineers: it eliminates problems, speeds up debugging, and simplifies the onboarding of new team members.

This isn't just theoretical fluff; it's a practical pattern you can use right away to improve your projects.

Takeaways

Single Responsibility Principle: To keep your code modular and maintainable, assign each Java class one specific job
Service Layer: Use a coordinator class to coordinate sequential workflows while keeping clarity and control.
Quality Over Haste: Investing in Clean Code now saves time and frustration later.
Practical Java: This design is compatible with technologies such as Java 8 and your favorite IDE, making it ideal for everyday programming.

Do you believe separating responsibilities like this makes sense in your Java projects? Have you had trouble balancing Clean Code with tight deadlines? Please share your thoughts in the comments—I'd love to know how you approach quality in your Software Engineering journey!

Full disclosure: this article was written with the aid of Grok, an AI built by xAI, who helped me organize my ideas and polish the content. The concepts and insights, however, are based on my own daily experiences as a coder.

Static Factories: When Static Methods Shine (And Why They're Not Always Evil)

Cassio Menezes — Wed, 05 Mar 2025 12:15:00 +0000

In my recent article (Static X OOP), I suggested that regular classes and interfaces are more effective than utility classes' static methods, particularly when it comes to validation. There are distinctions, though, much like with other software development tasks. I want to look at a situation today where static methods—more especially, static factory methods—can be a useful and sophisticated tool. Inspired by Joshua Bloch's 'Effective Java,' let's see how I utilize them to improve the testability and flexibility of my code.

The Right Tool

'Effective Java' teaches us to strategically employ static factory methods instead of constructors when applicable. The ability to retrieve subtypes, give descriptive names, and manage instance generation are just a few benefits of these methods. They've been especially helpful to me in managing dependencies like the JapeContext in my work extending ERP platforms.

    public static BlockRepository getInstance() {
        return new BlockRepositoryImpl(new BlockRepositorySqlExecutorImpl(() -> {
            try {
                return JapeUtils.executeWithJape(context -> context); // Get JapeContext
            } catch (SQLException e) {
                throw new RuntimeException("Error getting JapeContext", e); // Handle exception
            }
        }));
    }

In this case, BlockRepositoryImpl instances are created using a controlled entry point provided by the getInstance() method, which functions as a static factory. Using this method enables me to incorporate the intricate reasoning involved in acquiring the JapeContext into the factory method. Using a BlockRepositorySqlExecutorImpl and a lambda function, I can postpone retrieving the context until it's truly required. This type of deferred initialization can boost efficiency.

But the real magic happens when it comes to testing. By using a static factory, I can easily provide a mock JapeContext during unit tests. For instance, I can create a test-specific getInstance() method that returns a BlockRepositoryImpl instance with a mocked BlockRepositorySqlExecutorImpl. This allows me to isolate the BlockRepositoryImpl and test its behavior without relying on the actual ERP platform.

The flexibility of the code is also improved by the use of this pattern. All I have to do is alter the getInstance() method if I ever need to change how the JapeContext is retrieved. BlockRepositoryImpl callers are not impacted. This is a powerful demonstration of the Open/Closed Principle.

Takeaway

Static factory methods provide an alternative to static utility classes, which frequently result in rigid and untestable code. They offer a flexible and controlled method for managing dependencies, improving testability, and creating instances. We may create code that is reliable and manageable by using the right tool for the right job.

Have you used static factory methods in your projects? What insights and experiences do you have? Leave a comment below with your opinions! Let's continue the discussion and learn from each other.

Static x OOP

Cassio Menezes — Fri, 28 Feb 2025 18:21:17 +0000

As Java developers, we are continually aiming to create cleaner, more maintainable code. Recently, while working on a project, I faced a typical problem: how to effectively incorporate validation logic. Should I use a utility class with static methods or a separate class that implements the validation interface? The solution, as I learned, goes beyond convenience, and penetrates the heart of object-oriented ideas.

The Question That Sparked It All:

“Why use a regular class (implementing a Validator interface) instead of a utility class with static methods for validation in Java?” This question arose as I was trying to find the best approach for data validation in my application.

The Case for Regular Classes (Implementing Interfaces)

Here’s why I leaned towards regular classes, and why you might want to too:
Object-Oriented Principles (OOP) in Action:

Encapsulation: Even stateless validators benefit from encapsulation, bundling related behavior neatly.
Polymorphism: Interfaces like Validator enable flexible validation strategies and composite validators, something static methods can’t easily replicate.
Dependency Injection (DI): Regular classes play well with DI, enhancing testability and flexibility — a stark contrast to the rigidity of static methods.

Testability That Matters

Unit testing becomes a breeze. Mocking and stubbing dependencies in regular classes is straightforward, isolating validation logic for thorough testing.

Maintainability and Extensibility for the Long Haul

Validation logic evolves. Regular classes gracefully accommodate complexity, unlike the potential maintenance headaches of sprawling static utility classes.
Adding dependencies to external resources, like databases, is easier using regular classes and dependency injection. Readability and Organization for Clarity:
Dedicated validator classes enhance code organization, making it easier to understand and maintain. Adherence to SOLID Principles for Robust Design:
Regular classes naturally align with the Single Responsibility Principle (SRP) and Open/Closed Principle, fostering a robust and adaptable codebase.

When Static Methods Might Seem Tempting (But Shouldn’t Be)

While static methods might appear convenient for simple, unchanging validation, they often lead to technical debt eventually.

Choosing regular classes (implementing interfaces) over static utility methods leads to a more robust, adaptable, and maintainable solution. It adheres to OOP concepts, improves testability, and supports SOLID principles, all of which are necessary for developing high-quality Java programs.

What are your thoughts on validation strategies? Have you faced similar dilemmas? Share your experiences and insights in the comments below!