Hey there! I’ve been exactly where you are—kicking off a wxWidgets calculator project, enjoying the smooth early coding phase, then watching it turn into a tangled mess as I added more features. Let’s break down how to structure your code for cleanliness, flexibility, and scalability, tailored specifically for C++ and wxWidgets.

These are the foundational rules that will keep your codebase manageable as it grows:

• Single Responsibility Principle (SRP): Every class should do one thing and do it well. For example, don’t cram calculation logic into your wxFrame subclass—keep GUI code strictly about rendering user interactions, and move math operations to a separate CalculatorEngine class.
• Open/Closed Principle (OCP): Design components to be extendable without modifying existing code. Want to add square roots or trig functions later? Build an interface like IOperation that new operations can implement, instead of hacking conditional checks into your core calculator logic.
• Dependency Inversion Principle (DIP): High-level modules (like your GUI) should depend on abstractions, not concrete implementations. Your wxWidgets buttons shouldn’t directly call CalculatorEngine methods—instead, they should rely on an ICalculator interface, making it easy to swap in a mock engine for testing later.

These patterns will help you decouple GUI and business logic, which is the biggest win for maintainability:

MVC (Model-View-Controller) #

This is a classic for GUI apps and plays nicely with wxWidgets:

• Model: Holds your business logic (calculation rules, state like current input values). It doesn’t know anything about the GUI.
• View: Your wxWidgets components (wxFrame, wxPanel, buttons, text controls). It displays data and forwards user actions to the controller.
• Controller: Acts as the middleman. It listens for View events (like button clicks), fetches input from the View, tells the Model to perform operations, and updates the View with results.

Example snippet structure:

// Model: Pure business logic
class CalculatorModel {
public:
    double Compute(double a, double b, char op) {
        switch(op) {
            case '+': return a + b;
            case '-': return a - b;
            // ... other ops
        }
        return 0;
    }
};

// View: wxWidgets UI
class CalculatorFrame : public wxFrame {
public:
    CalculatorFrame() : wxFrame(nullptr, wxID_ANY, "Calculator") {
        // Setup text controls, buttons, sizers
        m_input1 = new wxTextCtrl(this, wxID_ANY);
        m_input2 = new wxTextCtrl(this, wxID_ANY);
        m_result = new wxStaticText(this, wxID_ANY, "0");
        m_calcBtn = new wxButton(this, wxID_ANY, "Calculate");
    }

    // Getters/setters for data
    double GetInput1() { return wxAtof(m_input1->GetValue()); }
    double GetInput2() { return wxAtof(m_input2->GetValue()); }
    char GetOperator() { /* Fetch from dropdown/button state */ }
    void SetResult(double val) { m_result->SetLabel(wxString::Format("%f", val)); }

    // Expose event binding for controller
    void BindCalculateEvent(wxEvtHandler* handler) {
        m_calcBtn->Bind(wxEVT_BUTTON, handler, wxID_ANY);
    }

private:
    wxTextCtrl* m_input1;
    wxTextCtrl* m_input2;
    wxStaticText* m_result;
    wxButton* m_calcBtn;
};

// Controller: Glue between Model and View
class CalculatorController : public wxEvtHandler {
public:
    CalculatorController(CalculatorModel* model, CalculatorFrame* view) 
        : m_model(model), m_view(view) {
        m_view->BindCalculateEvent(this);
    }

    void OnCalculate(wxCommandEvent& evt) {
        double a = m_view->GetInput1();
        double b = m_view->GetInput2();
        char op = m_view->GetOperator();
        double result = m_model->Compute(a, b, op);
        m_view->SetResult(result);
    }

private:
    CalculatorModel* m_model;
    CalculatorFrame* m_view;
    DECLARE_EVENT_TABLE()
};

// Implement event table for controller
BEGIN_EVENT_TABLE(CalculatorController, wxEvtHandler)
    EVT_BUTTON(wxID_ANY, CalculatorController::OnCalculate)
END_EVENT_TABLE()

MVP (Model-View-Presenter) #

A slight twist on MVC that’s often more intuitive for wxWidgets:

• The Presenter takes a more active role—instead of the View forwarding events, the Presenter tells the View what to display and handles all user interaction logic.
• The View is passive: it only exposes methods to update its state (like SetResult()) and doesn’t know about the Model.

This works well because wxWidgets controls are inherently stateful, so the Presenter can directly manipulate the View’s state without tight coupling.

Observer Pattern #

Use this to keep your Model and View in sync without hard dependencies. For example, when the Model updates its calculation state, it can trigger a custom wxEvent that the View listens to. wxWidgets’ built-in wxEvtHandler system makes this easy—you can define custom event types to broadcast changes from the Model to any interested View components.

• Split UI into reusable components: Don’t dump all your buttons and controls into one giant wxFrame. Create smaller, focused classes like NumberPadPanel, OperatorPanel, or DisplayPanel—each responsible for a single part of the UI. This makes it easier to tweak or replace parts later.
• Avoid global variables: It’s tempting to use globals for calculator state or UI pointers, but they turn into maintenance nightmares. Instead, use dependency injection—pass required objects (like the Model) to your UI components via constructors.
• Leverage wxWidgets sizers: Forget hardcoding control positions and sizes. Use wxBoxSizer, wxGridSizer, etc., to create responsive layouts that adapt to window resizing. This keeps your UI code clean and avoids messy coordinate math.
• Use smart pointers: Manage dynamic objects (like your Model or Controller) with std::unique_ptr or std::shared_ptr to avoid memory leaks and make ownership clear.

• Write unit tests for your Model first: Since the Model has no GUI dependencies, you can test all calculation logic independently without firing up wxWidgets. This catches bugs early and makes refactoring safer.
• Keep event handlers thin: Don’t put complex logic inside OnButtonClicked methods. Instead, delegate to your Controller or a dedicated service class—event handlers should only be responsible for routing events.

Content的提问来源于stack exchange，提问作者Michael Chon