I know that an attribute defines the state of an object. So, is it correct to keep attributes that don't define the state of an object of a class?
For example, I have an Employee
class, which has these attributes:
emp_id
,
fname
,
lname
,
mname
,
salary
,
mobile
,
email
,
gender
,
maritalstatus
,
position
,
birthdate
,
hiredate
,
dept_id
,
address_id
,
bank_id
.
The dept_id
, address_id
and bank_id
are foreign keys. Now my actual question is can we include attributes like bank_id
, address_id
and dept_id
into Employee
class because they are not actually showing exact behavior of Employee
Class? Instead can I make another class named EmployeeForeignKeys
and keep these attributes bank_id
, address_id
, dept_id
in that class?
Best Answer
First a couple of observations:
Person
class theBankAccount
is not part of its inner state but for an Employee class it does.dept_id
andaddress_id
don't follow any widely accepted Java naming convention, they should be nameddeptId
,addressID
, etc.An
Employee
class shouldn't have abankID
member but abankAccount
member which is of typeBankAccount
.I wouldn't do this:
but this
In the case of a person perhaps the banking information is not part of the class itself, so, you invert the logic so the person doesn't have a reference to the banking information and let the BankAccount have a reference to the person:
In the case of en amployee, everyone should have a bank account to work properly so it makes sense the bank account to be part of its state.
In the case of a mere person that may not be so, so the bank account should reference the person and not the other way around.
EDIT:
@COMEFROM in one comment added some valid exceptions to my point on whether or not classes should have referencing IDs as members: