> You are cordially invited to the inugural event of the Hartford CT chapter
> of the Open Web Application Security Project. The Open Web Application
> Security Project (OWASP) is a worldwide free and open community focused on
> improving the security of application software. Our mission is to make
> application security "visible," so that people and organizations can make
> informed decisions about application security risks. Everyone is free to
> participate in OWASP and all of our materials are available under an open
> source license.
>
> Please see attachment for additional information...
>
>

Hi, I'm Alan Shalloway, author of Design Patterns Explained, A New Perspective of Object-Oriented Design.

I'll be doing a webinar on Design Patterns in an Agile Environment on September 4, 10am PDT.

We also have a new streamzine on Refactoring to the Open-Closed.  This is a way of doing emergent design in an agile environment (test-driven development guided by the knowledge of design patterns).  You can see this by going to our resources page http://www.netobjectives.com/resources (you'll need to register and/or login first).

Abstract of Design Patterns in an Agile Environment

What relevance do Design Patterns have in a modern, Agile development process?

Many development organization ask this question. After all, the book that started the patterns movement, Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides), was originally published in 1995. Can a concept introduced over 10 years ago still apply today?

Yes! Design Patterns are even more relevant now than ever before. Why?

Patterns emphasize maintainability as a fundamental priority in design. In an Agile process, we embrace the notion that all the forces which drive development (requirements, technology, priorities, etc…) can and will change, and that in order to keep the value of software high, our software must be changeable without excessive risk, cost, and waste. Patterns promote this by encapsulating variations at multiple levels.

Furthermore, patterns do not exist solely in the realm of up-front design. They are equally powerful, perhaps even more powerful, when emerging a design incrementally, and in the face of changing requirements. This is best understood by experiencing them in this context.

Patterns teach us to handle variation. They were originally discovered in situations where the variations to be handled were known at the beginning of the design process. However, the principles behind the patterns can be just as effectively applied when these same variations are discovered one at a time. This is what typically happens in an Agile process. This webinar introduces the principles of standard design patterns, but it does it within the context of an Agile project.

Click here  to get more information on this webinar as well as register for it at:

Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2007.

Integrating people, process and technology through training, coaching and consulting.

See http://www.netobjectives.com/courses/index.html for our list of nationally offered courses in Lean Software Development, Scrum, Requirements, OO, Design Patterns and TDD.

Blogs and podcasts http://blogs.netobjectives.com/

Hi,

I just got an email that the meeting scheduled for tonight has been
moved to next week, same time, same place.


--- In dpsg-nyc@yahoogroups.com, "AMIT" <amit.bolakani@...> wrote:
>
> I am a new member and was wondering if we are meeting today?
> Thanks,
> -A
>

No, there is no meeting today.

We were meeting on the 1st and 3rd Weds of the month
so we met last week. Starting next month I believe
that we will be meeting on the second Weds of the
month only.

The next meeting will be on July 11th.
7:00 PM.
IBM Public Space, 590 MADISON AVENUE (next to the
Trump Tower)
Between 56th and 57th Streets

Shannon will verify this before the meeting but I
think that our topic is serialization (bridge design
pattern/memento/others). I'm guessing that this will
take up a good part of the Summer.

Please feel free to join us!



________________________________________________________________________________\
____
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

I am a new member and was wondering if we are meeting today?
Thanks,
-A

Just checking - I think there is a meeting tonight, but I thought I
should confirm.

Unfortunately, this meeting will again be cancelled due to conflicts
in schedules.


--- In dpsg-nyc@yahoogroups.com, "Shannon Wagner" <shannon@...> wrote:
>
> We will be meeting at the IBM public space at 56th and Madison in NYC
> from 7pm to 9pm on Wednesday, May 2nd.
>
> We plan to review Creational patterns and discuss general issues
> related to object instantiation.
>
> - sw
>

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, May 2nd.

We plan to review Creational patterns and discuss general issues
related to object instantiation.

- sw

Due to several conflicts tonight, we need to cancel the meeting.

Sorry for the short notice.. sw


--- In dpsg-nyc@yahoogroups.com, "Shannon Wagner" <shannon@...> wrote:
>
> We will be meeting at the IBM public space at 56th and Madison in NYC
> from 7pm to 9pm on Wednesday, April 18th.
>
> We plan to review Creational patterns and discuss general issues
> related to object instantiation.
>
> - sw
>

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, April 18th.

We plan to review Creational patterns and discuss general issues
related to object instantiation.

- sw

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, April 4th.

The topic has not been decided yet, but we plan to discuss a topic
selected from Refactoring To Patterns, by Joshua Kerievsky.

- sw

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, March 21st.

The patterns planned to be discussed are: Prototype, Template

- sw

I'm sorry - I saw someone walking to some of the tables while we were
there, but if that was you then I think we were one of the tables you
didn't ask about the group.

I normally put up a copy of the Design Patterns book to help identify
us, but I forgot to last night, and we did get a bit of a late start
(although two of us were there at the time you were).

We are still meeting - the next meeting will be Wednesday, March 21st,
and we'll be discussing the Prototype and Template patterns.  We are
doing a schedule of 2 Wednesday's each month.  Right now, it is 1st
and 3rd Wednesday of the month, but we have discussed moving to 2nd
and 4th Wednesday due to a scheduling conflict (but the actual dates
will always be posted on this group ahead of time).

So far with this group we have discussed the following patterns:
Abstract Factory, Builder, Decorator, Factory Method, Singleton,
State, Chain of Responsibility, Iterator, Command, Observer, Strategy

I am sorry that we missed you last night - we are definitely looking
for additional members.  Hope to see you next time..

shannon


--- In dpsg-nyc@yahoogroups.com, wendy wu <wwanwendy@...> wrote:
>
> Hi Shannon,
>   I have been to the IBM building today. Stayed there from 6:50 to
7:20. Did not see anyone from this group. Is the study group still
active? Thanks.
>   wendy
>
> Shannon Wagner <shannon@...> wrote:
>           We will be meeting at the IBM public space at 56th and
Madison in NYC
> from 7pm to 9pm on Wednesday, March 7th.
>
> The patterns planned to be discussed are: Decorator, Factory
>
> - sw
>
>
>
>
>
>
> ---------------------------------
> Looking for earth-friendly autos?
>  Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
>

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, March 7th.

The patterns planned to be discussed are: Decorator, Factory

- sw

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, March 7th.

The patterns planned to be discussed are:  Decorator, Factory

- sw

I think you mean the 21st?

At any rate, I am feeling a bit under the weather, so I will not be
attending this evening.

--- In dpsg-nyc@yahoogroups.com, "Shannon Wagner" <shannon@...> wrote:
>
> We will be meeting at the IBM public space at 56th and Madison in NYC
> from 7pm to 9pm on Wednesday, February 19th.
>
> The patterns planned to be discussed are: Singleton, Builder
>
> Any helpful printouts you want to bring (code samples, insightful
> articles, etc.) are very welcome!
>
> A GoF book will be on display to make the group recognizable.
>
> - sw
>

I'm sorry I'm not a good person to answer your question, but I do hope
that you got some response offline at least..

The best insight I could offer re: what "first-class" means for
Smalltalk is that in Smalltalk I always read that *everything* is an
object.  So, an integer is an object in exactly the same sense that
any other class instance is an object.  I guess that this has subtle
implications when dealing with creational patterns, but I can't
understand yet what they are.

If you are in New York City, then maybe you could come to our next
meeting for some discussion?  The guy who is moderating doesn't have
Smalltalk experience, but he has a lot of experience working with
patterns.

- sw



--- In dpsg-nyc@yahoogroups.com, "sky eagle" <eagle.xiao@...> wrote:
>
> I am rereading the GOF's book. In the 3rd chapter, implementation of
> Abstract factory, they said abstract factory could be implemented with
> Prototypen and when going on "A variation on the Prototype-based
approach is
> possible in languages that treat classes as *first-class* objects
(Smalltalk
> and Objective C, for example). " I just want to know what does they
mean by
> "first-class". Maybe, I just don't get the correct translation of
this term
> (I speak Chinese.).
> And would some kind guy give an example that implements the Abstract
Factory
> pattern with Prototype in Java or C# (or even C++)? I know little about
> smarttalk. I googled it with "abstract factory implemented with
prototype"
> and got nothing helpful.
> Thank you in advance. If some guy speaking Chinese in this list, you
could
> reply me to my private mail address eagle.xiao@...
>
> --
> XiaoPeng
> My blog: http://designpatterns.cnblogs.com
>

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, February 19th.

The patterns planned to be discussed are: Singleton, Builder

Any helpful printouts you want to bring (code samples, insightful
articles, etc.) are very welcome!

A GoF book will be on display to make the group recognizable.

- sw

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, February 7th.

The patterns planned to be discussed are: State, Chain of Responsibility

Any helpful printouts you want to bring (code samples, insightful
articles, etc.) are very welcome!

A GoF book will be on display to make the group recognizable.

- sw

P.S. Regular meetings are planned for the 1st and 3rd Wednesday of
each month.

No problem.. Matt and I will be there tonight (the meeting has also
been posted on C# Corner, so we don't want to miss anyone else who
might come).

We'll probably plan to discuss tonight's patterns at our next meeting,
though.

- sw



--- In dpsg-nyc@yahoogroups.com, "A. Resa Jones" <adrianresajones@...>
wrote:
>
>
> Valen also will not be able to make it due to work!
>
>
>
>
>
________________________________________________________________________________\
____
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives.
> http://tools.search.yahoo.com/toolbar/features/mail/
>

Valen also will not be able to make it due to work!




________________________________________________________________________________\
____
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

I probably will not be able to make it. I just moved
and am in the middle of chaos.




________________________________________________________________________________\
____
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

We will be meeting at the IBM public space at 56th and Madison in NYC
from 7pm to 9pm on Wednesday, January 17th.

The patterns planned to be discussed are: State, Chain of Responsibility

Any helpful printouts you want to bring (code samples, insightful
articles, etc.) are very welcome!

A GoF book will be on display to make the group recognizable.

- sw

P.S. Regular meetings are planned for the 1st and 3rd Wednesday of
each month.

At 12:18 AM 1/6/2007, sky eagle wrote:
>I think some details needs clarification.
>I add some code here to show the implementation and what troubles me:


   First, I translated the code into a reasonable language,
   so I could see what was going on.  Then I added and removed
   a couple lines -- which have the effect of solving your
   'time-travel' problem, by way of what might be referred to as
   the 'follower' pattern.  (I use this a lot).

   The only other change was to push what you called the "client"
   into the <visitor>, proper; and to return a container, at the
   end of each visit, rather than leave it lying around in a global.

   No need to refactor the traversal -- your use of visitor is fine.

Cheers,

-jim



>Shape>>property
>    ^property
>
>
>NormalShapePropertyA>>accept: visitor
>    visitor visitNormalShapePropoertyA: self
>
>NormalShapePropertyB>>accept: visitor
>    visitor visitNormalShapePropoertyB: self
>
>NormalShapePropertyC>>accept: visitor
>    visitor visitNormalShapePropoertyC: self
>
>...
>
>SpecialShapeProperty>>
>  >>accept: visitor
>    visitor visitSpecialShapePropoerty: self
>
>  >>nextCard
>    ...


++  Visitor>>
++      instanceVariables := 'lastSpecialNode'.


>Visitor>>visitNormalShapePropertyA: visitee
>        ...
>        id := CardIDGenerator getCardID: visitee.
>        container := CardNodes for: id.
>        node := NormalShapeNodeA new.
>        ...
>        node setTag: visitee name.
>        ...
>        container add: node.
>        ...
>        ^container
>
>
>" While for the SpecialShapeProperty, there is some problem "
>        ...
>        ...
>>>visitSpecialShapeProperty: visitee
>        ...
>        id := CardIDGenerator getCardID: visitee.


++      lastSpecialNode isNil or: [lastSpecialNode setNextCardID: id].


>        container := CardNodes for: id.
>        node := lastSpecialNode := SpecialShapeNode new.
>        ...
>        node setTag: visitee name.



>        node setNextCardID: (???). "" !! visitee doesn't know it's next cardID
"
>                                   " !! nobody knows now. "

         " We must delay setting the nextCardId for a node
          until after that id is generated, which will happen
          in the future -- the next time we visit a specialShape.

          So, we use the 'follower' pattern,
          and remember the lastSpecialNode.
          Next time we visit a specialNode,
          we'll generate the current cardId,
          then immediately time-travel into the past,
          storing the 'future' nextCardId
          into the lastSpecialNode.
        "

>        ...
>
>        container add: node.
>        ...
>        ^container
>
>
>ObjectStructure>>
>  >>startShape
>  >>NextShape
>  ...
>
>Client>>fu
>    ...
>    shape := objectStructure startShape.
>    [ shape ~= ExitShape
>    ] whileTrue:
>      [ result := shape property accept: visitor.
>        " assemble the result to a XmlRootNode "
>        ...
>        shape := objectStructure nextShape.
>        ...
>      ].


      " Note: the very lastSpecialNode has no <nextCardId> "


>    ...
>
>
>
>2007/1/5, sky eagle <<mailto:eagle.xiao@...>eagle.xiao@...>:
>Background: A graph is a set of shapes and connectors. The software is to
generate a xml file from the graph. A piece of xml code is generated from each
shape and then they are composed to a whole xml file. This is a typical
information collecting method, so I used visitor here.
>
>
>Implementation: I used visitor pattern for this case. I used ObjectStructure to
traverse all the shapes (we don't need to care about the connector, another
class assembles the ObjectStructure). There is an XmlElement member in the
visitor as the collection parameter to save the data got from each shape.
>
>Problem: Each time the visitor visits a shape, it will generate a ID for this
shape. There is a special shape. It has a property named NextShapeID which is
the ID for its next shape. While this "ID" is only generated when the next shape
is visited. The traversal is not controlled by the visitor (but the
ObjectStructure), and we need to change the traversal order for this special
shape. I don't know how to do this, or is it possible.
>
>Any suggestion would be appreciated!
>For the class diagram of Visitor pattern:
>
><http://www.cnblogs.com/images/cnblogs_com/DesignPatterns/WindowsLiveWriter/Vis\
itor_148E8/clip_image002.gif>http://www.cnblogs.com/images/cnblogs_com/DesignPat\
terns/WindowsLiveWriter/Visitor_148E8/clip_image002.gif
>
>

I think some details needs clarification.
I add some code here to show the implementation and what troubles me:

Shape>>property
    ^property


NormalShapePropertyA>>accept: visitor
    visitor visitNormalShapePropoertyA: self
 
NormalShapePropertyB>>accept: visitor
    visitor visitNormalShapePropoertyB: self
 
NormalShapePropertyC>>accept: visitor
    visitor visitNormalShapePropoertyC: self
 
...
 
SpecialShapeProperty>>
  >>accept: visitor
    visitor visitSpecialShapePropoerty: self
 
  >>nextCard
    ...

Visitor>>visitNormalShapePropertyA: visitee
        ...
        id := CardIDGenerator getCardID: visitee.
        container := CardNodes for: id.
        node := NormalShapeNodeA new.
        ...
        node setTag: visitee name.
        ...
        container add: node.
        ...
        ^container


" While for the SpecialShapeProperty, there is some problem "
        ...
        ...
>>visitSpecialShapeProperty: visitee
        ...
        id := CardIDGenerator getCardID: visitee.

        container := CardNodes for: id.
        node := lastSpecialNode := SpecialShapeNode new.     
        ...
        node setTag: visitee name.

        node setNextCardID: (???). "" !! visitee doesn't know it's next cardID "
                                   " !! nobody knows now. "

        ...

        container add: node.
        ...
        ^container


ObjectStructure>>
  >>startShape
  >>NextShape
  ...

Client>>fu
    ...
    shape := objectStructure startShape.
    [ shape ~= ExitShape
    ] whileTrue:
      [ result := shape property accept: visitor.
        " assemble the result to a XmlRootNode "
        ...
        shape := objectStructure nextShape.
        ...
      ].

    ...


 
2007/1/5, sky eagle <eagle.xiao@...>:

Background: A graph is a set of shapes and connectors. The software is to generate a xml file from the graph. A piece of xml code is generated from each shape and then they are composed to a whole xml file. This is a typical information collecting method, so I used visitor here.

 

Implementation: I used visitor pattern for this case. I used ObjectStructure to traverse all the shapes (we don't need to care about the connector, another class assembles the ObjectStructure). There is an XmlElement member in the visitor as the collection parameter to save the data got from each shape.

 

Problem: Each time the visitor visits a shape, it will generate a ID for this shape. There is a special shape. It has a property named NextShapeID which is the ID for its next shape. While this "ID" is only generated when the next shape is visited. The traversal is not controlled by the visitor (but the ObjectStructure), and we need to change the traversal order for this special shape. I don't know how to do this, or is it possible.

 

Any suggestion would be appreciated!

For the class diagram of Visitor pattern:

http://www.cnblogs.com/images/cnblogs_com/DesignPatterns/WindowsLiveWriter/Visitor_148E8/clip_image002.gif

 

I think some details needs clarification.
I add some code here to show the implementation and what troubles me:

Shape>>property
    ^property


NormalShapePropertyA>>accept: visitor
    visitor visitNormalShapePropoertyA: self
 
NormalShapePropertyB>>accept: visitor
    visitor visitNormalShapePropoertyB: self
 
NormalShapePropertyC>>accept: visitor
    visitor visitNormalShapePropoertyC: self
 
...
 
SpecialShapeProperty>>
  >>accept: visitor
    visitor visitSpecialShapePropoerty: self
 
  >>nextCard
    ...

Visitor>>visitNormalShapePropertyA: visitee
        ...
        id := CardIDGenerator getCardID: visitee.
        container := CardNodes for: id.
        node := NormalShapeNodeA new.
        ...
        node setTag: visitee name.
        ...
        container add: node.
        ...
        ^container


" While for the SpecialShapeProperty, there is some problem "
        ...
        ...
>>visitSpecialShapeProperty: visitee
        ...
        id := CardIDGenerator getCardID: visitee.

        container := CardNodes for: id.
        node := lastSpecialNode := SpecialShapeNode new.     
        ...
        node setTag: visitee name.

        node setNextCardID: (???). "" !! visitee doesn't know it's next cardID "
                                   " !! nobody knows now. "

        ...

        container add: node.
        ...
        ^container


ObjectStructure>>
  >>startShape
  >>NextShape
  ...

Client>>fu
    ...
    shape := objectStructure startShape.
    [ shape ~= ExitShape
    ] whileTrue:
      [ result := shape property accept: visitor.
        " assemble the result to a XmlRootNode "
        ...
        shape := objectStructure nextShape.
        ...
      ].

    ...


 
2007/1/5, sky eagle <eagle.xiao@...>:

Background: A graph is a set of shapes and connectors. The software is to generate a xml file from the graph. A piece of xml code is generated from each shape and then they are composed to a whole xml file. This is a typical information collecting method, so I used visitor here.

 

Implementation: I used visitor pattern for this case. I used ObjectStructure to traverse all the shapes (we don't need to care about the connector, another class assembles the ObjectStructure). There is an XmlElement member in the visitor as the collection parameter to save the data got from each shape.

 

Problem: Each time the visitor visits a shape, it will generate a ID for this shape. There is a special shape. It has a property named NextShapeID which is the ID for its next shape. While this "ID" is only generated when the next shape is visited. The traversal is not controlled by the visitor (but the ObjectStructure), and we need to change the traversal order for this special shape. I don't know how to do this, or is it possible.

 

Any suggestion would be appreciated!

For the class diagram of Visitor pattern:

http://www.cnblogs.com/images/cnblogs_com/DesignPatterns/WindowsLiveWriter/Visitor_148E8/clip_image002.gif