从SQLite查询返回DB_Memo对象地址而非数据的解决方法

Hey there! Let's work through your problem step by step—this is a super common issue when working with custom database model classes in Java, so we'll get it sorted quickly.

First, let's clear up why you're getting that unreadable string instead of your actual data:
All Java classes inherit from the Object class by default, and the default toString() method in Object returns a string made of the class name, @, and the object's hash code (that hex number at the end). When you print or log your DB_Memo objects directly, Java uses this default method, hence the weird memory address output.

Rewriting toString() lets you replace that default behavior with something meaningful—like the actual data stored in your object.

You mentioned your current toString() only outputs fixed variables, but you need different outputs for different use cases. Since you can't change the signature of the standard toString() method (it has to be public String toString() with no parameters), here are two simple, practical solutions:

Option 1: Create Scenario-Specific Methods #

Add custom methods to your DB_Memo class that return the exact string format you need for each scenario. This is straightforward and easy to maintain.

Example for your DB_Memo class:

public class DB_Memo {
    // Your actual table columns (adjust to match your database schema)
    private int id;
    private String playerName;
    private int lifeTotal;
    private String commanderName;

    // Constructor, getters, setters, and other existing code...

    // Default toString() (fallback for generic use cases)
    @Override
    public String toString() {
        return "DB_Memo{id=" + id + ", playerName='" + playerName + "'}";
    }

    // For scenario 1: Displaying in a player list
    public String toStringForPlayerList() {
        return playerName + " | Current Life: " + lifeTotal;
    }

    // For scenario 2: Displaying detailed commander info
    public String toStringForCommanderDetail() {
        return "Player: " + playerName + "\nCommander: " + commanderName + "\nLife Total: " + lifeTotal;
    }
}

Then, when you retrieve data from your DB_DataSource, call the appropriate method based on your use case:

// Example: Fetching data via DB_DataSource
List<DB_Memo> playerData = dbDataSource.getAllPlayers();

// Scenario 1: Print list-friendly format
for (DB_Memo player : playerData) {
    System.out.println(player.toStringForPlayerList());
}

// Scenario 2: Print detailed format for a selected player
DB_Memo selectedPlayer = playerData.get(0);
System.out.println(selectedPlayer.toStringForCommanderDetail());

Option 2: Parameterized String Method #

If you prefer a single method that handles multiple scenarios, you can create a parameterized method with a switch case to return the right format:

public class DB_Memo {
    // Existing fields, constructor, getters/setters...

    public String toStringByScenario(String scenario) {
        switch(scenario) {
            case "PLAYER_LIST":
                return playerName + " | Current Life: " + lifeTotal;
            case "COMMANDER_DETAIL":
                return "Player: " + playerName + "\nCommander: " + commanderName + "\nLife Total: " + lifeTotal;
            case "SIMPLE":
                return playerName;
            default:
                return super.toString(); // Fallback to default if scenario is unknown
        }
    }
}

Use it like this:

System.out.println(selectedPlayer.toStringByScenario("COMMANDER_DETAIL"));

• DB_Memo: This is your model class—this is where you'll add the custom string methods (since it holds the data you want to display).
• DB_DataSource: When you fetch data using this class, you'll get a list of DB_Memo objects. Instead of printing the objects directly, call your custom methods on each object.
• DB_Helper: This class handles database creation and upgrades—you won't need to modify it for this issue, since it doesn't deal with displaying data.

内容的提问来源于stack exchange，提问作者prextor