Prev: ComVisible(false) doesn't work as expected
Next: COM communicate with managed code(.NET)
From: Michaela Brauner on 2 May 2010 03:52
Hello Peter,
> Some broad observations:
thanks a lot for the obervations.
Can you show me concretely at the code.
>
> � ScannerState: unless your enum is required to have specific values
> for the purpose of interoperation with some other component (managed or
> unmanaged) that you don't control, there really is not any point in
> providing explicit values for each enumeration value.
>
> � BaseScannerVerify: there are no abstract members of this abstract
> class. Thus, there is not any point in making the class abstract. If
> there are members of the class that you want to require sub-classes to
> override, then those members should not be implemented in the base
> class. Make them abstract instead.
>
> � ScannerVerifyTypeA: currently, the base class provides default
> implementations for every member. There is no point in the sub-class
> overriding the base class implementations for members for which it does
> not change the implementation. This includes the "Initialize()" and
> "Stop()" methods, and the "State" property.
>
> � BackgroundWorkerScannerTypeA: there is almost never any point in
> overriding BackgroundWorker, and definitely in your example there's
> really no obvious benefit to doing so. Even if you wanted a convenience
> method such as the "RunAsync()" method, there's nothing about that
> method that suggests it should actually be _in_ an instance of
> BackgroundWorker.
>
> � BackgroundWorkerScannerTypeA: your DoWork event handler sets the
> Cancel property at the end based on the CancellationPending. But, the
> worker object hasn't had its WorkerSupportsCancellation property set to
> true. Even if it had, the Cancel property should be set _only_ if the
> DoWork event handler was in fact actually cancelled. If it runs to
> completion, then in spite of some client code trying to cancel the
> worker (resulting in the CancellationPending property getting set), by
> definition the worker was not in fact cancelled, and should not report
> that it was.
Then it becomes clearer for me. Have a nice Sunday.
Greeting Michaela
From: Michaela Brauner on 3 May 2010 08:19
Hello Peter,

the reason for 'abstract' class was.
I don't know what is in the future?
Maybe some Scanners have same features.
What do you think about that?

Michaela
From: Peter Duniho on 3 May 2010 11:34
Michaela Brauner wrote:
> Hello Peter,
>
> the reason for 'abstract' class was.
> I don't know what is in the future?
> Maybe some Scanners have same features.
> What do you think about that?

I think it doesn't make sense.

If in the future the base class changes in a way that actually requires
the "abstract", that would mean you'd either add abstract members or
change existing members to abstract. In which case, existing code would
have to be recompiled to use the same the DLL anyway. It would be
simple enough to change the class to "abstract" at that point as well.

There is no reason I can see to have a class be "abstract" now when
there's nothing abstract about it.

Pete
From: Michaela Brauner on 3 May 2010 14:59
Peter Duniho wrote:
> Michaela Brauner wrote:
>> Hello Peter,
>>
>> the reason for 'abstract' class was.
>> I don't know what is in the future?
>> Maybe some Scanners have same features.
>> What do you think about that?
>
> I think it doesn't make sense.
>
> If in the future the base class changes in a way that actually requires
> the "abstract", that would mean you'd either add abstract members or
> change existing members to abstract. In which case, existing code would
> have to be recompiled to use the same the DLL anyway. It would be
> simple enough to change the class to "abstract" at that point as well.
>
> There is no reason I can see to have a class be "abstract" now when
> there's nothing abstract about it.
ok thanks.

Do you have, do you know a good sample, link for my task?
So I can see, maybe the better way.

But not with the new framework. I haven't VS2010, only VS2008
http://mef.codeplex.com/
http://msdn.microsoft.com/de-de/library/dd460648.aspx#the_problem_of_extensibility
I need, to understand first the basics pattern.

Thanks a lot.

Greeting Michaela
From: Peter Duniho on 4 May 2010 03:45
Michaela Brauner wrote:
> [...]
>> There is no reason I can see to have a class be "abstract" now when
>> there's nothing abstract about it.
>
> ok thanks.
>
> Do you have, do you know a good sample, link for my task?
> So I can see, maybe the better way.
>
> But not with the new framework. I haven't VS2010, only VS2008
> http://mef.codeplex.com/
> http://msdn.microsoft.com/de-de/library/dd460648.aspx#the_problem_of_extensibility
>
> I need, to understand first the basics pattern.

Which pattern are you referring to? The factory pattern (which you
originally seem to have asked about)? Or the abstract class design
(which you seem to be trying to implement)?

Not that I have any good links that I personally can vouch for, to refer
you to off-hand. But you should at least be specific about what you're
looking for.

I will point out that Wikipedia has articles on both the factory pattern
and abstract class design:
http://en.wikipedia.org/wiki/Factory_pattern
http://en.wikipedia.org/wiki/Abstract_class

Though, on the latter point, to the extent that an abstract class is
basically the same as an interface, except that it can have some default
implementation for members, it doesn't seem to me as though that's
really all that complicated a subject. My previous comments regarding
your code should give you some insight as to important differences
between an abstract class as you've implemented it, and the more typical
ways to implement one (*).

(*)(in particular, if you have implemented all of the virtual members
already, there's no point in the class being abstract; only if some
members are themselves abstract, and thus much like an interface that
some type might need to implement, would the whole class need to be
abstract).

Note that neither of these issues are in any way specific to a given
version of Visual Studio.

I also don't understand the intent behind the links you posted. The
first doesn't seem specifically applicable to the question at hand, and
the second I can't even understand (I appreciate that your English is
better than my German and certainly don't fault you for referring to
German sources, but unfortunately there is little hope of me figuring
them out).

Pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ComVisible(false) doesn't work as expected
Next: COM communicate with managed code(.NET)