[Pharo-project] OOP best practices

Hernan Wilkinson hernan.wilkinson at 10pines.com
Thu Oct 14 17:55:35 EDT 2010


cool!
remember also the other tip, that the object should be valid from scratch...
so, for this example I would do something like this:

PerformedExperiment class>>for: anExperiment
   startedAt: aStartTime
   stopedAt: aStopTime
   madeBy: aParticipant
   with: aCollectionOfTasks

   PatAssertionsRunner valueWith: (self
assertionForPerformedExperimentStartedAt: aStartTime before: aStopTime).

   ^self new initializeExperimient: anExperiment
      start: aStartTime
      stop: aStopTime
      participant: aParticipant
      tasks: aCollectionOfTasks

That way if the stoptime is before starttime (wich I beleive is an error in
this case) the object is not created and you wont have an invalid performed
experiment.
You will see that asserting that something starts before the "stop" is very
common, so I suggest to use an interval to represent that but not the
smalltalk Interval that does not verify that condition but the Aconcagua
Interval that verifies that intervals are valid. So you could change the
message to something like this:

PerformedExperiment class>>for: anExperiment
   during: aTimePeriod
   madeBy: aParticipant
   with: aCollectionOfTasks

   ^self new initializeExperimient: anExperiment
      during: aTimePeriod
      participant: aParticipant
      tasks: aCollectionOfTasks

Doing so you get less parameters and only valid "time periods" (intervals)
that leads to valid performed experiments.
Another assertion that you may have is if aCollectionOfTasks can be empty...
anyway, thinking about this constrains helps you to create a better model
and understand the business rules.

I hope it helps!
Hernan.

2010/10/14 Fernando olivero <fernando.olivero at usi.ch>

> THANKS Hernan!
>
> With the example i've got to  understand the correct usage of the pattern
> now. Which of course i will follow from now on, given the benefits from
> having complete objects! ( no messy ifNil checks for starters!, etc...)
>
>
>
>
> 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 <fernando.olivero at usi.ch
> > 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
>> Pharo-project at lists.gforge.inria.fr
>> 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: hernan.wilkinson at 10Pines.com
> site: http://www.10Pines.com <http://www.10pines.com/>*
>
>  <ATT00001..txt>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> 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: hernan.wilkinson at 10Pines.com
site: http://www.10Pines.com <http://www.10pines.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101014/7352dce2/attachment-0001.html>


More information about the Pharo-dev mailing list