OO Design: Who can do what?

[antonyliu2002]

OO Design continued.

When we try to design a class, we try to think about what the objects
of the class can do, like quite many OO programming books say.

Let's suppose that we are gonna design a ProjectManager class and a
Project class.

Well, what can a ProjectManager do? I think s/he can
createNewProject, deleteProject, assignFundToProject, requestFund,
deleteFund, editProject, viewProjectList, etc.

What can a Project do? I don't know except some getter setter
methods. The reason I don't know about it is because a project is not
animate, thus I am not sure what action it can perform.

So, naturally, I put those named methods above (createNewProject,
deleteProject, assignFundToProject, etc.) into the ProjectManager
class, because I think those are the things that a ProjectManager can
do.

But my colleague told me that those methods should really go into the
Project class. I assume that my colleague is right, because I do not
have much experience in OO design. But, then,

1. Why does it make more sense to put those methods in the Project
class than in the ProjectManager class, giving the instructions of OO
programming textbooks?

2. If we move those methods into the Project class, then what can a
ProjectManager do?

I want to be a good OO designer, so, please do share your wisdom about
this. Thanks.

 

[Manivannan Palanichamy]

OO Design continued.

When we try to design a class, we try to think about what the objects
of the class can do, like quite many OO programming books say.

Let's suppose that we are gonna design a ProjectManager class and a
Project class.

Well, what can a ProjectManager do? I think s/he can
createNewProject, deleteProject, assignFundToProject, requestFund,
deleteFund, editProject, viewProjectList, etc.

What can a Project do? I don't know except some getter setter
methods. The reason I don't know about it is because a project is not
animate, thus I am not sure what action it can perform.

So, naturally, I put those named methods above (createNewProject,
deleteProject, assignFundToProject, etc.) into the ProjectManager
class, because I think those are the things that a ProjectManager can
do.

But my colleague told me that those methods should really go into the
Project class. I assume that my colleague is right, because I do not
have much experience in OO design. But, then,

1. Why does it make more sense to put those methods in the Project
class than in the ProjectManager class, giving the instructions of OO
programming textbooks?

2. If we move those methods into the Project class, then what can a
ProjectManager do?

I want to be a good OO designer, so, please do share your wisdom about
this. Thanks.

Your first design is correct. the design confusion is because of
unclear requirements. you should start from UseCase diagram, and then
will come to know what each Actor got to do.

Anyway. In this case, the Project will be a a resource class. Like a
value object. So, obviously it will have only getters & setters.

I would agree with the following design:

class Project
{
get/setName();
get/setReleaseDate();
get/setTeams();
get/setProjectManager();
}

class ProjectManager
{
Project createNewProject();
deleteProject(Project project);
assignFundToProject(Project project, Fund fund);
}

 

[antonyliu2002]

Your first design is correct. the design confusion is because of
unclear requirements. you should start from UseCase diagram, and then
will come to know what each Actor got to do.

Anyway. In this case, the Project will be a a resource class. Like a
value object. So, obviously it will have only getters & setters.

I would agree with the following design:

class Project
{
get/setName();
get/setReleaseDate();
get/setTeams();
get/setProjectManager();

}

class ProjectManager
{
Project createNewProject();
deleteProject(Project project);
assignFundToProject(Project project, Fund fund);

}

Interesting, so you are with me, and disagree with my colleague. Any
comments from other OO gurus?

 

[Alexey]

Interesting, so you are with me, and disagree with my colleague. Any
comments from other OO gurus?

I tend to agree with your and GP's design. Generally speaking, it IS
a good idea to assign "verbs" as methods to the actors. Other methods
that Project may have would come no so much from actions, but perhaps
requirements that detail what kind of information might be needed from
within the Project entity. For example:

class Project
{
// ... getters and setters for simple data fields

Date getCompletionETA()
Money estimateCost()

// some task management
Set<Task> getTasks()
Set<Task> getTasksAssignedTo(Employee emp)
}

 

[antonyliu2002]

I tend to agree with your and GP's design. Generally speaking, it IS
a good idea to assign "verbs" as methods to the actors. Other methods
that Project may have would come no so much from actions, but perhaps
requirements that detail what kind of information might be needed from
within the Project entity. For example:

class Project
{
// ... getters and setters for simple data fields

Date getCompletionETA()
Money estimateCost()

// some task management
Set<Task> getTasks()
Set<Task> getTasksAssignedTo(Employee emp)

}

Cool, sounds like that I have been correct, but my colleague was
wrong. Feeling so proud. So, the principle is really simple: assign
"verbs" as methods to the actors.

 

[Mike Schilling]

Your first design is correct. the design confusion is because of
unclear requirements. you should start from UseCase diagram, and then
will come to know what each Actor got to do.

Anyway. In this case, the Project will be a a resource class. Like a
value object. So, obviously it will have only getters & setters.

Quibble:

Suppose one of the things a project manager can do is combine two project,
merging all of the resources associated with project A into project B.
Agreed that there should be

ProjectManager.combineProjects(Project mergeInto, Project mergeFrom)

I don't think that this should be implemented by a list of get() and set()
calls. The knowledge of what resources exist and how to merge them (as well
as what state the cannibalized project goes into) belongs in the Project
class. That is, if I add a new sort of resource to Project, it should be
clear in the Project class what corresponding changes need to be made.

Thus this should be implemented as

combineProjects(Project absorbInto, Project cannibalizeFrom)
{
absorbInto.absorb(cannibalizeFrom);
}

with the details of this processing in Project.absorb(). (Obviously, if
the two projects were combined into a brand-new project, the work would be
done in a Project constructor.)

 

[Greg R. Broderick]

Well, what can a ProjectManager do? I think s/he can
createNewProject, deleteProject, assignFundToProject, requestFund,
deleteFund, editProject, viewProjectList, etc.

IMO, you've neglected one very important, frequently-invoked method for the
ProjectManager class. I've provided a reference implementation below.


public class ProjectManager
{
...

public void pesterWorkers()
{
System.out.println("What do you mean it isn't done yet?");
}
}


Cheers
GRB

--
---------------------------------------------------------------------
Greg R. Broderick (e-mail address removed)

A. Top posters.
Q. What is the most annoying thing on Usenet?
---------------------------------------------------------------------

 

[antonyliu2002]

IMO, you've neglected one very important, frequently-invoked method for the
ProjectManager class. I've provided a reference implementation below.

public class ProjectManager
{
...

public void pesterWorkers()
{
System.out.println("What do you mean it isn't done yet?");
}

}

Cheers
GRB

--
---------------------------------------------------------------------
Greg R. Broderick (e-mail address removed)

A. Top posters.
Q. What is the most annoying thing on Usenet?
---------------------------------------------------------------------

Ha, that's a good joke. My Project Manager has been nice so far.

 

[TobiMc3]

OO Design continued.

When we try to design a class, we try to think about what the objects
of the class can do, like quite many OO programming books say.

Let's suppose that we are gonna design a ProjectManager class and a
Project class.

Well, what can a ProjectManager do? I think s/he can
createNewProject, deleteProject, assignFundToProject, requestFund,
deleteFund, editProject, viewProjectList, etc.

What can a Project do? I don't know except some getter setter
methods. The reason I don't know about it is because a project is not
animate, thus I am not sure what action it can perform.

So, naturally, I put those named methods above (createNewProject,
deleteProject, assignFundToProject, etc.) into the ProjectManager
class, because I think those are the things that a ProjectManager can
do.

An aside:

I think you forgot yellAtDeveloper()

Tobi

 

[TobiMc3]

IMO, you've neglected one very important, frequently-invoked method for the
ProjectManager class. I've provided a reference implementation below.

public class ProjectManager
{
...

public void pesterWorkers()
{
System.out.println("What do you mean it isn't done yet?");
}

}

Cheers
GRB

--
---------------------------------------------------------------------
Greg R. Broderick (e-mail address removed)

A. Top posters.
Q. What is the most annoying thing on Usenet?
---------------------------------------------------------------------

LOL-Great minds!!

Tobi