tags:

views:

51

answers:

5

Hi!

I have a simple question about object oriented design but I have some difficulties figuring out what is the best solution. Say that I have an object with some methods and a fairly large amount of properties, perhaps an Employee object. Properties, like FirstName, Address and so on, which indicates a data structure. Then there could be methods on the Employee object, like IsDueForPromotion(), that is more of OO nature.

Mixing this does not feel right to me, I would like to separate the two but I do not know how to do it in a good way. I have been thinking about putting all property data in a struct and have an internal struct object inside the employee object, private EmployeeStruct employeData ...

I am not sure this is a really good idea however, maybe I should just have all methods and proerties in the same class and go with that. Am I making things to complicated if I separate data from methods?

I would very much appreciate if someone have any ideas about this.

J

+3  A: 

Wasn't the idea of OO-design to encapsulate data and the corresponding methods together?

The question here is how the Employee object could possibly know about begin due for promotion. I guess that method belongs somewhere else to a class which has the informations to decicde that. really stupid example Manager m = new Manager(); manager.IsDueForPromotion(employeeobject);

But other methods to access the fields of Employee belong to this class.

The question I raised about IsDueForPromotion depends on you application and if your Employee is a POJO or DTO only or if it can have more "intelligent" methods associated too.

jitter
A: 

Object operations (methods) are supposed to use the properties. So I feel its better to leave them together.

If it does not require properties, its a kind of utility method and should be defined else ware, may in some helper class.

Nrj
A: 

Well, OO is a way of grouping data and functionality that belong together in the same location. I don't really see why you would make an exception 'when there is a lot of data'. The only reason I can think of is legibility.

Personally I think you would be making things needlessly complex by coming up with a separate struct to hold your data. I'm also conflicted as to wether this would be good practice. On the one hand, how a class implements it's functionality, or stores it's data is supposed to be hidden from the outside world. On the other hand, if data belongs to a class, it feels unnatural to store it in something like a struct.

It may be interesting to look at the data you have and see if it can be modeled into smaller domain objects. For example, have an Address object that holds a street, housenumber, state, zip, country, etc value. That way, your Employee object will just hold an Address object. The Address object could then be reused for your Company objects etc.

+1  A: 

if your data evolves slower than behaviour you may want to give a try to Visitor pattern:

class Employee {

    String name;
    String surName;
    int age;
    // blah blah
    // ...getters
    // ...setters
    // other boilerplate

    void accept(EmployeeVisitor visitor) {
        visitor.visitName(name);
        visitor.visitAge(age);
        // ...
    }
}

interface EmployeeVisitor {

    void visitName(String name);

    void visitAge(int age);
}

with this design you can add new operations without changing the Employee class. Check also use the specification pattern.

dfa
A: 

The basic principle of Object Oriented programming is grouping data such as FirstName and Address with the functionality that goes with it, such as IsDueForPromotion(). It doesn't matter how much data the object is holding, it will still hold that data. The only time you want to remove data from an object is if it has nothing to do with that object, like storing the company name in the Employee object when it should be stored in a company object.

indyK1ng