Object heuristic
-
Is there a design heuristic in object oriented programming that states that an object shouldn't send messages to objects it creates? Is one of these "better"?
class AnotherClass
{
public:
AnotherClass(SomeClass *obj)
{
this->obj = obj;
this->obj->DoStuff();
}// Rest of implementation....};
SomeClass *obj1 = new SomeClass;
AnotherClass *obj2 = new AnotherClass(obj1);vs.
class AnotherClass
{
public:
AnotherClass()
{
obj = new SomeClass;
obj->DoStuff();
}// Rest of implementation....};
AnotherClass *obj = new AnotherClass();
I have a vague memory of reading somewhere that the first version is a better design, but I can't remember why. I haven't found anything Googling.
-
Is there a design heuristic in object oriented programming that states that an object shouldn't send messages to objects it creates? Is one of these "better"?
class AnotherClass
{
public:
AnotherClass(SomeClass *obj)
{
this->obj = obj;
this->obj->DoStuff();
}// Rest of implementation....};
SomeClass *obj1 = new SomeClass;
AnotherClass *obj2 = new AnotherClass(obj1);vs.
class AnotherClass
{
public:
AnotherClass()
{
obj = new SomeClass;
obj->DoStuff();
}// Rest of implementation....};
AnotherClass *obj = new AnotherClass();
I have a vague memory of reading somewhere that the first version is a better design, but I can't remember why. I haven't found anything Googling.
Hi Leslie, I prefer the first. The second creates its own SomeClass instance, without any parameters or specialization. So creating two AnotherClass() instances would cause exactly the same things to happen twice. The first snippet makes much more sense to me. From your snippet it isn't really clear why you need two classes in the first place. I also expect real names for the classes would make things more obvious. :)
Luc Pattyn [Forum Guidelines] [My Articles] [My CP bug tracking] Nil Volentibus Arduum
Season's Greetings to all CPians.
-
Hi Leslie, I prefer the first. The second creates its own SomeClass instance, without any parameters or specialization. So creating two AnotherClass() instances would cause exactly the same things to happen twice. The first snippet makes much more sense to me. From your snippet it isn't really clear why you need two classes in the first place. I also expect real names for the classes would make things more obvious. :)
Luc Pattyn [Forum Guidelines] [My Articles] [My CP bug tracking] Nil Volentibus Arduum
Season's Greetings to all CPians.
Luc Pattyn wrote:
From your snippet it isn't really clear why you need two classes in the first place. I also expect real names for the classes would make things more obvious.
It was a quick and dirty example. I'll try to do better. :) I've been doing iPhone programming, and using the Model/View/Controller pattern (or at least one variation of it) is encouraged by the architecture. Say we have a model.
class Model
{
public:
// Stuff...
};The controller uses the model, but should it also be responsible for creating it? Assume for the sake of argument that an instance of the model isn't used any where else besides the controller class. I guess it then becomes academic, but I seem to remember reading some where that objects shouldn't use the objects they create. I can't remember why or where I read that. I was wondering if this:
class Controller
{
public:
Controller(Model *model)
{
this->model = model
}
};Is better than this:
class Controller
{
public:
Controller()
{
this->model = new Model();
}
};Maybe the reasoning as to why the first approach is better is that if we use polymorphism, we can switch out which model is used by the Controller; we can't do that in the second example without changing the Controller class. Also, maybe as a general rule factory code should be seperate from the rest of the code?
-
Luc Pattyn wrote:
From your snippet it isn't really clear why you need two classes in the first place. I also expect real names for the classes would make things more obvious.
It was a quick and dirty example. I'll try to do better. :) I've been doing iPhone programming, and using the Model/View/Controller pattern (or at least one variation of it) is encouraged by the architecture. Say we have a model.
class Model
{
public:
// Stuff...
};The controller uses the model, but should it also be responsible for creating it? Assume for the sake of argument that an instance of the model isn't used any where else besides the controller class. I guess it then becomes academic, but I seem to remember reading some where that objects shouldn't use the objects they create. I can't remember why or where I read that. I was wondering if this:
class Controller
{
public:
Controller(Model *model)
{
this->model = model
}
};Is better than this:
class Controller
{
public:
Controller()
{
this->model = new Model();
}
};Maybe the reasoning as to why the first approach is better is that if we use polymorphism, we can switch out which model is used by the Controller; we can't do that in the second example without changing the Controller class. Also, maybe as a general rule factory code should be seperate from the rest of the code?
I have no authority on the MVP/MVC subject nor on iPhone, however here are some thoughts: 1.
Leslie Sanford wrote:
objects shouldn't use the objects they create
does not make much sense to me. When I create objects I want to use them, or pass them on for others to use them. 2.
Leslie Sanford wrote:
factory code should be seperate from the rest of the code
I second that. The purpose is you can (and often have to) change the factory, however you don't want to touch the code in the object's users. 3. You need some overall code anyhow (say the static Main method in a C# app); so it can create Model, View, and Controller; in the right order; and pass the required ones as parameters to the other constructors. Maybe you even want interfaces, rather than actual classes passed in. So definitely your #1 approach for me. Suggestion: have a look at some other iPhone apps, there's bound to be some here in CP articles. :)
Luc Pattyn [Forum Guidelines] [My Articles] [My CP bug tracking] Nil Volentibus Arduum
Season's Greetings to all CPians.
-
Is there a design heuristic in object oriented programming that states that an object shouldn't send messages to objects it creates? Is one of these "better"?
class AnotherClass
{
public:
AnotherClass(SomeClass *obj)
{
this->obj = obj;
this->obj->DoStuff();
}// Rest of implementation....};
SomeClass *obj1 = new SomeClass;
AnotherClass *obj2 = new AnotherClass(obj1);vs.
class AnotherClass
{
public:
AnotherClass()
{
obj = new SomeClass;
obj->DoStuff();
}// Rest of implementation....};
AnotherClass *obj = new AnotherClass();
I have a vague memory of reading somewhere that the first version is a better design, but I can't remember why. I haven't found anything Googling.
The decision you have to make is all about dependency. The first alternative implements a loose dependency between the controller and model. In the second alternative, the dependency is hard coded into the controller. Therefore I definitely vote for the first one. However, I am surprised that you are given this choices at all. Without knowing much about IPhone UI programming, all the other UI frameworks I know have some kind of preferred architecture model. While you can program "around it", by doing so you exclude yourself from using certain techniques or tools which could make your application unusable by third parties or make things like customization, styling, themeing etc... exteremly difficult. For example, Microsoft's presentation frameworks like WPF or Silverlight do not enforce a specific model but if you choose not to follow the guidance, you exclude yourself from things like easy data binding, dynamic UI composition, easy cooperation with designer tools and much more... So follow Luc's advice and have a look at some exemplary IPhone applications or even better on Apple's guidelines about the architecture model for UI. Cheers, Paul