Re: design quicky
From: TheFerryman (ferry_at_onthenet.com)
Date: 04/04/04
- Next message: Ronald E Jeffries: "Re: Refactoring (Was: Code Coverage and QC)"
- Previous message: Robert C. Martin: "Re: xp and simple design"
- In reply to: Robert C. Martin: "Re: design quicky"
- Next in thread: Daniel T.: "Re: design quicky"
- Reply: Daniel T.: "Re: design quicky"
- Reply: Robert C. Martin: "Re: design quicky"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 04 Apr 2004 22:31:01 +0100
On Sun, 04 Apr 2004 11:11:46 -0500, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>On Fri, 02 Apr 2004 09:56:11 +0100, TheFerryman <ferry@onthenet.com>
>wrote:
>
>>I have a design problem that occurs fairly often. In essence it is
>>this:
>>
>>class Base
>>{
>>protected:
>>
>> stack<Base*> m_BaseStack;
>>
>> virtual void f()=0;
>>
>> virtual ~Base(){DeleteStack(m_BaseStack);}
>>};
>>
>>class DerivedType1 : public Base
>>{
>> void f()
>> {
>> if (SomeLogic())
>> {
>> m_BaseStack.push(new DerivedType2);
>> }
>> }
>>};
>>
>>
>>class DerivedType2 : public Base
>>{
>> void f()
>> {
>> if (SomeLogic())
>> {
>> m_BaseStack.push(new DerivedType999);
>> }
>> }
>>};
>>
>>
>>The code above is what I normally do but some of my peers abhor the
>>use of new in a function call. tbh, it's never felt right to me
>>either.
>
>Can you articulate why you don't want the new keyword in the function?
>I can think of a number of reasons, but I'd like to hear your reasons.
I feel as though the creation of an object should be the
responsibility of the class that owns (and deletes) the object, and
not the responsibility of the client.
Actually, writing this out has made me realize that the object that
owns the newed object *is* actually deleting it too! So this looks
okay to me now.
For the sake of furthering this discussion though, let's assume the
new keyword is used in a method call by an object who has no further
responsibility for the newly created object. What are *your* reasons
for disliking this (you said you can think of a number of them...)
>
>In any case, you could defer the new invocations into global
>functions, or you could create an abstract factory. In C++ either of
>those options will prevent your classes from #including the header
>files of the classes they are trying to create.
I think an abstract factory is what I was suggesting. I'm not sure
though, I'm inexperienced and I don't have the GOF book to hand to
verify.
>>
>>I'm considering creating a factory method in Base, that stores a map
>>of Derived types referenced into by string so I can do something like:
>>
>>class DerivedType2 : public Base
>>{
>> void f()
>> {
>> if (SomeLogic())
>> {
>> PushOnStack("DerivedType999");
>> }
>> }
>>};
>
>This is probably overkill. The base class would have to #include
>*every* derivative.
It wouldn't have to #include any derivatives. That's the partly the
point, clients can define the functionality of the map at runtime.
(all the derivatives will be #included in the object that sets up the
map)
>
>>Is this a better design or do you think it unnecessarily complex? What
>>do you think of the first design?
>
>I think the first design could be OK, depending on how many news are
>called from any given f method.
- Next message: Ronald E Jeffries: "Re: Refactoring (Was: Code Coverage and QC)"
- Previous message: Robert C. Martin: "Re: xp and simple design"
- In reply to: Robert C. Martin: "Re: design quicky"
- Next in thread: Daniel T.: "Re: design quicky"
- Reply: Daniel T.: "Re: design quicky"
- Reply: Robert C. Martin: "Re: design quicky"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
