[Insight-developers] Modes versus Objects

[Johnson, Hans J]

To add a very concrete example to Gaetans statements.

Kent and I have discussed a solution to dealing with the physical space
image additions.

1)  We will refine Kent's current patch under a different name (with the
necessary bug fixes that have been identified), perhaps even some more
engineering effort is needed to overcome some of Gaetans points of concern.
2)  We will implement Brad Lowekamp's "VerifyAllInputs()" in the rolled
back version of base classes

=========
This was our original thought, it would be very little effort now, but it
introduces about 95% code duplication, and two parallel trees on that ONLY
works on voxel lattice, and fails if the voxel lattice is not consistent
(from item #2), and a second case that works in physical space and index
space when possible that seems to overlap the first.  This solution feels
wrong to me and feels like a maintenance nightmare.

==========
I am clearly missing something with respect to the "one filter does
exactly one thing" argument.  In my mind, that is exactly what we are
trying to accomplish.  I don't see where the two different things are.
The one thing is "Add two images together", and provide "modes" for how
that one thing is accomplished.

I assume this can be an agenda for tomorrows teleconference.

--
Hans J. Johnson, Ph.D.
hans-johnson at uiowa.edu
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive

Iowa City, Iowa 52242
Phone:  319-353-8587







-----Original Message-----
From: Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>
Date: Thu, 2 Jun 2011 18:40:53 +0200
To: Bill Lorensen <bill.lorensen at gmail.com>
Cc: ITK <insight-developers at itk.org>
Subject: Re: [Insight-developers] Modes versus Objects


Le 2 juin 11 à 17:32, Bill Lorensen a écrit :

> Folks,
>
> This discussion is motivated by recent activity...
>
> Back in the early days of OO programming, I recall having discussions
> about the use of modes versus objects. When I taught OO courses I
> always discouraged modes if they changed the "identity" of the object.
>
> Should a mode be used to change the behaviour of an object or should a
> new object be created?
>
> A case where a mode is better than an object:
> Controlling the visibility of an actor in VTK:
>  1) Mode: vtkActor VisibilityOn/Off
> or
>  2) Object: two classes vtkActor and vtkVisibleActor
>
>  1) is the appropriate solution since, at run time, an application
> may want to change the visibility of an actor.
>
> A case where an object may be better than a mode:
>  1) Mode: itkShiftScaleImageFilter
> SetOperationOrderToShiftScale()/SetOperationOrderToScaleShift()
> or
>  2) Object: two classes itkShiftScaleImageFilter and
> itkScaleShiftImageFilter
>
> A VTK approach versus an ITK approach
>  1) mode: vtkImageMathematics 21 different modes
> (ADD,SUBTRACT,MULTIPLY,...)
>  2) object: itkAddImageFilter, itkSubtractImageFilter,
> itkMultipleImageFilter...
>
> It is not always obvious as to the best choice. But, I think the
> question should be asked anytimne we introduce a new "mode".
>

Hi Bill,

This is certainly a good thing to keep in mind while adding a new
feature, and your example on ShiftScaleImageFilter and
ScaleShiftImageFilter certainly make sense.

But I'm not sure the decision will be that easy when it comes to base
classes.
Adding features in base classes may help to avoid duplicating the
subclasses, and code duplication is certainly something we want to
avoid.

The BinaryFunctorImageFilter recently modified is a good example - do
we want to have two versions of Add image filter, one for indexed data
access and another for physical space data access?

The InPlaceImageFilter is another good example. It allows a subclass
to run in place or not. We probably don't want to duplicate the
subclasses to implement that feature.

It would be nice if everything can be simple!

Gaëtan


--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.html

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.itk.org/mailman/listinfo/insight-developers



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________