CODEWITHSUNDEEP
javaoop
jeff
jeff

Reputation: 3732

OO Design of JavaBeans

I'm questioning the way that I have been designing my JavaBeans. For example, say I have the following:

Employee - basic employee information: 
   private String employee_id;
   private String first_name;
   private String last_name;
   private String phone;
   private String deptNo; 
   etc..

WorkflowPlayer - details about an employee in a system workflow: 
   private String workflow_instance_id;
   private String employee_id;
   private String role_class_id;
   private String role_required;
   private Employee employee;
   private RoleClass roleClass;

RoleClass - details of a type of role (Approver, SecurityReviewer, Originator, Instructor, Manager, etc..)
   private String role_class_id;
   private String name;
   private String label;
   private String description;

These three models also correspond directly to Database tables (Employee is a read only view for me, if that matters)

Then in my view I would do something like
workflow_player.employee.first_name
workflow_player.roleClass.label

Is it acceptable to make Employee an instance variable? Or should I instead be extending WorkflowPlayer with Employee and then do
workflow_player.first_name

this makes sense for employee but not for roleClass.
workflow_player.description //NO!

I just want to use a consistent [correct] pattern

Upvotes: 1

Views: 120

Answers (3)

Nathan Hughes
Nathan Hughes

Reputation: 96434

Yes, it's ok to make Employee an instance variable if you are referring to it from another table. Subclassing in this case is wrong because from your description it sounds like workflow is not a specialized kind of employee. Ask yourself if the lifecycles of these entities are the same or different, and if the subclass is substitutable for the superclass in all situations.

Subclassing should be a last resort reserved for cases where some entity is a specialized version of another entity and you want to refer to the specialized versions by their superclass.

There are specific patterns where subclassing is used in Object-relational mapping: table per class hierarchy, table per subclass, table per concrete entity, etc. The Hibernate documentation describes them. You would use inheritance in mapping objects to tables when your tables fall into one of those patterns. Even if you're not using Hibernate that's still a good example to follow.

Upvotes: 2

Toilal
Toilal

Reputation: 3409

You can't map JavaBean directly to Tables, because OO is not the same as Relational (Database).

You could use an ORM, like Hibernate, to map you JavaBean to SGBD Tables properly.

From an OO point of view, beans should be like that

public class Employee {
    private String id;

    private String firstName;
    private String lastName;
    private String phone;
    private String deptNo;
}

public class WorkflowPlayer {
    private String id;

    private String roleRequired;
    private Employee employee;
    private Role roleClass;
}

public class RoleClass {
    private String id;

    private String name;
    private String label;
    private String description;
}

Upvotes: 2

Rob
Rob

Reputation: 11733

I think role classes are a great design approach, and many developers do not use them. This matches the canonical use of role classes: when an entity participates in different activities, and within those activities, the view of that type is different. A good example would be the following. Suppose we were modeling payroll. We have a user who is both one of the employees who is getting paid, and an administrator in the app. In Java, we would have to model that as role classes because we don't have multiple inheritance, but it's really a more accurate representation because the role class, if it does confer any additional behavior or properties, it is doing so in the context of its own behavior. So for instance, whatever powers you need to grant the administrator in the payroll is confined to that realm.

It's also not an either/or situation: in the Payroll, you might want to show that some employees are also managers. That probably would best be done with inheritance, but the role class is still valid, again, as a way of representing participation.

Upvotes: 2

Related Questions