摘要 Class getter 和 setter 用法 [V2]

Question

Good Morning,

This is an add-on to a question I recently asked about the proper usage of abstract classes.

I currently have a abstract class and 2 sub classes see illustration for example:

public abstract class Vehicle {

  String type;
  String color;
  
  ...getter and setters
 

 }

Inherits getter and setter from parent, plus one unique property

  public class Truck extends Vehicle{


   String pickupBed;

 
  public setPickupBed(String pickupBed){
   this.pickupBed = pickupBed;
  }
  public getPickupBed(String pickupBed){
   return pickupBed;
  }


 .....Parent class getter and setters
  }

Inherits getter and setter from parent

  public class Car extends Vehicle{

   .....Parent class getter and setters
  }

The situation I am having is when I create a Method in my DAO class, for example

 public Vehicle selectAllRecords(){
    ...DO database stuff
 return VehicleRowMapperWithData();
 }

And if I call Vehicle veh = selectAllRecords() I can not do this veh.getPickupBed() I understand thats not how it works, but how can I accomplish this? I tried casting but it didnt work.

Thanks in advance

Answer 1

There's no easy answer.

Use your DB tooling

Some DBs support 'subclassing'; you can make a table that extends another. Postgres can do this, for example. Many DB abstraction layers do not support it, psql doesn't support it all that well (it works and is maintained, but not really recommended). As long as the DB more or less perfectly reflects how your java code works, then there's at least a chance that the tooling you use will just figure out what to do as if by magic.

Write code

Forget java for a moment. Just look at your DB tables. How do you know a certain vehicle is, in fact, a truck? Is there a separate table called 'truck'? Is there a column 'vehicleType', and all the custom fields for each kind of vehicle is a column in your DB table, with each row that isn't that kind of vehicle holding NULL or some dummy value for that column? In that case, you'd write a big if/elseif block that checks the vehicle type column and then calls the right new Car(...) , or new Truck(...) constructor.

More generally you now have a mismatch between your java object model and your DB model.

This is usually a good thing, though, JPA and friends work best when these 2 match precisely, but given that java is OO and likes hierarchy, and DBs really don't. that's not neccessarily a good idea, However: once your java's class structures do not match up with how the DB stores things (example, In your DB, it's one table with a 'type' column, in java, it's a hierarchy of classes and there is no 'type' field, instead, there are instances of Car, instances of Truck. etc) - that means automated tools can't just magically turn one into the other. You write code that does this.

Match java to the DB

Instead of trying to make sure the DB's table definitions match your java code exactly, which is hard (psql) or impossible (most other db systems that do not have subtabling features), well, as they say, if you can't get the stone up the mountain, maybe bring the mountain to the stone: Forget about your type hierachy in java. Just have one class Vehicle, and an enum VehicleType. This is a bit nasty, as it breaks all sorts of idiomatic java rules; now an instance of Vehicle representing a roadbike has a getPickupBed() method which is weird.

This brings us back to the simple truth of things:

• Idiomatic (as in, most tutorials recommend it, tooling of all stripes work best if you do it that way, it's a supported path in most DBs and any issues in that workflow are found early and fixed fast because most folks working with this software work just like you do, that's what 'idiomatic' means) DB design is important.
• Idiomatic code is important.
• The same concept represented as idiomatic DB design often doesn't match idiomatic code design.
• We like automated conversion.

These things aren't fully compatible with each other.