So a "smart template" created by the debugger would just do the following, when
defining the following Class method:
performedExperiment := PerformedExperiment
for: anExperiment
startedAt: aStartTime
stopedAt: aStopTime
madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not
a good name"
with: aCollectionOfTasks.
DNU => HIT CREATE BUTTON => Automatically create the following methods
1)
PerformedExperiment class >>
for: anExperiment
startedAt: aStartTime
stopedAt: aStopTime
madeBy: aParticipant
with: aCollectionOfTasks.
| instance |
instance := self new.
instance
initializeFor: anExperiment
startedAt: aStartTime
stopedAt: aStopTime
madeBy: aParticipant
with: aCollectionOfTasks.
^ instance
2)
PerformedExperiment>> initializeFor: anExperiment
startedAt: aStartTime
stopedAt: aStopTime
madeBy: aParticipant
with: aCollectionOfTasks.
self shouldBeImplemented
On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote:
> Hi Fernando,
> I think that you are saying that having too many parameter could be a
> problem for understanding the message, is that right?
> I mean, having too many inst var as you say, it is a smell of bad design,
> and having too many parameters also, so I guess we agree on that.
> About reading the code, from the sender point of view, if you don't have an
> instance creation message that creates a "complete" object, then you would do
> something like this:
>
> performedExperiment := PerformedExperiment new
> experimient: anExperiment;
> start: aStartTime ;
> stop: aStopTime ;
> participant: aParticipant;
> tasks: aCollectionOfTasks;
> yourself.
>
> With an inst. creation message that returns a complete object, you would use
> it like this:
>
> performedExperiment := PerformedExperiment
> experimient: anExperiment
> start: aStartTime
> stop: aStopTime
> participant: aParticipant
> tasks: aCollectionOfTasks.
>
> So, it is basically the same but with less messages and less error prone (in
> the former you can forget to send a message, ie. stop: and nobody will
> complain immediately, but in the last one you wont make that mistake, or if
> you doit you will get a dnu immediately).
>
> About the implementation of the inst. creation message, it is true that it
> could bother a little the reading, but when there are so many parameters I
> format the code this way:
>
> PerformedExperiment class>>experimient: anExperiment
> start: aStartTime
> stop: aStopTime
> participant: aParticipant
> tasks: aCollectionOfTasks
>
> ^self new initializeExperimient: anExperiment
> start: aStartTime
> stop: aStopTime
> participant: aParticipant
> tasks: aCollectionOfTasks
>
> that makes it more readable.
> Also look that there is an initializeXxx message to distinguish it from the
> inst. creation message. This helps when analyzing code automatically (ie.
> initialize messages should only be sent from the class side) or generating
> code automatically on the debugger with the create button (as the enhancement
> 3099 that I sent the other day, the debugger could be smart enough to realize
> it is an initialization message so it could provide a better template than
> just a "self shouldBeImplemented").
> I the meantime, I would suggest another name for the message you are using as
> example, something easier to read like:
>
> performedExperiment := PerformedExperiment
> for: anExperiment
> startedAt: aStartTime
> stopedAt: aStopTime
> madeBy: aParticipant "Not sure what participant is, so maybe madeBy is
> not a good name"
> with: aCollectionOfTasks.
>
> I think it reads better. With the former you have duplicated "names" like
> "experimient: anExperiment", "start: anStartTime", etc., with the last one
> you don't have that problem.
>
> Hope it helps, let me know what you think!
>
> Hernan.
>
>
> On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <[email protected]>
> wrote:
> Hi Hernan, just wanted to get your opinion on the following method, that
> attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK).
>
> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime
> participant: aParticipant tasks: aCollectionOfTasks
> | experiment |
> experiment := self new.
> experiment experiment: anExperiment start: aTime stop: aStopTime
> participant: aParticipant tasks: aCollectionOfTasks.
> ^ experiment
>
>
> In your experience, how does the pattern cope with large keyword selectors.
>
> Maybe this case is not that evident, although we should try to avoid having
> more than 4 instance variables anyway, i would like to get your opinion on
> this problem (?).
>
> Thanks,
> Fernando
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: [email protected]
> site: http://www.10Pines.com
>
> <ATT00001..txt>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
