Jason McDonald

Yegor - first off, thank you for posting this. It takes guts to go against the norm and push the boundaries of what is acceptable. Don't stop this.

All - Everyone would be well off to remember that people pushing the envelope are how we make things better. Disagree with the principle but don't bash the person for starting the conversation.

That said, I don't agree with you either. The abstraction of complex and specific (DB interaction) behavior into separate classes is inherently OOP. Separation of responsibilities prevents the overloading of objects with more responsibility and complexity than they should ever have. In addition to having thousands of simple queries embedded within hundreds of classes in a given enterprise application you now have to worry about 1) a slew of decorators any time you want anything other than a straight 1:1 object retrieval, which will be commonplace in any real world implementation and 2) unnecessary complexity any time you have the need to do joins or cascading updates/deletes/lookups due to the fact that all of the logic for how to retrieve those must now be implemented in individual classes. ORM does all this for you.

I'd agree totally that the Hibernate implementation of ORM is overly verbose and could be greatly streamlined. You should read up on Ruby on Rails and how ActiveRecord works in greater detail as there are a lot of patterns and behavior in there that give the plusses of things like Hibernate in a less verbose way. Granted, a loosely typed language has some flexibility that Java doesn't, however we have implemented something (proprietary) very similar to ActiveRecord in java and it works well (still more verbose but far less than Hibernate).

I just added the following feature enhancements: 1. Canvas now supports a read only mode. 2. Can now save canvas information and drawing down to a JSON string. 3. Can now load canvas information and drawing from a JSON string. 4. Resize now preserves what part of any existing drawing it can.

Note that I've fixed a couple minor bugs in the code. You can get the latest version here:

http://www.mcdonaldland.info/2010/05/18/ruby-based-image-crawler/

There are a lot more comments here:
http://refcardz.dzone.com/announcements/design-patterns

There are a lot more comments here:
http://refcardz.dzone.com/announcements/design-patterns

I believe we are crossing in semantics... I thought about this my whole commute home and I think I realized what you are saying.

You mention the opened arrow, which I took to mean the inheritance arrow:

After thinking about it more what I think you mean is to replace the solid arrows:

With line arrows:

Is this correct?

The use of the solid arrows as opposed to the line arrows was strictly a design choice. Both are used frequently, even though the line arrows are technically the correct one to use with class diagrams. When I originally wrote the quick reference the fonts and diagrams were much smaller because all 23 patterns had to fit on just two pages. Now that the patterns are spread over 7 pages, I think it will be a bit easier to read if we use the line arrows.

I will talk with Jill and the rest of the dzoners about changing this out.

Jason Mcdonald

I believe we are crossing in semantics... I thought about this my whole commute home and I think I realized what you are saying.

You mention the opened arrow, which I took to mean the inheritance arrow:

After thinking about it more what I think you mean is to replace the solid arrows:

With line arrows:

Is this correct?

The use of the solid arrows as opposed to the line arrows was strictly a design choice. Both are used frequently, even though the line arrows are technically the correct one to use with class diagrams. When I originally wrote the quick reference the fonts and diagrams were much smaller because all 23 patterns had to fit on just two pages. Now that the patterns are spread over 7 pages, I think it will be a bit easier to read if we use the line arrows.

I will talk with Jill and the rest of the dzoners about changing this out.

Jason Mcdonald

I believe we are crossing in semantics... I thought about this my whole commute home and I think I realized what you are saying.

You mention the opened arrow, which I took to mean the inheritance arrow:

After thinking about it more what I think you mean is to replace the solid arrows:

With line arrows:

Is this correct?

The use of the solid arrows as opposed to the line arrows was strictly a design choice. Both are used frequently, even though the line arrows are technically the correct one to use with class diagrams. When I originally wrote the quick reference the fonts and diagrams were much smaller because all 23 patterns had to fit on just two pages. Now that the patterns are spread over 7 pages, I think it will be a bit easier to read if we use the line arrows.

I will talk with Jill and the rest of the dzoners about changing this out.

Jason Mcdonald

I believe we are crossing in semantics... I thought about this my whole commute home and I think I realized what you are saying.

You mention the opened arrow, which I took to mean the inheritance arrow:

After thinking about it more what I think you mean is to replace the solid arrows:

With line arrows:

Is this correct?

The use of the solid arrows as opposed to the line arrows was strictly a design choice. Both are used frequently, even though the line arrows are technically the correct one to use with class diagrams. When I originally wrote the quick reference the fonts and diagrams were much smaller because all 23 patterns had to fit on just two pages. Now that the patterns are spread over 7 pages, I think it will be a bit easier to read if we use the line arrows.

I will talk with Jill and the rest of the dzoners about changing this out.

Jason Mcdonald

Brian,

I'm a bit confused... Open arrows are used to show inheritance. Closed arrows are simply a directional attribute at the end of the association.

So, using the Visitor pattern as an example, the Client object is associated with both the Visitor and the Element. The arrow in this case could technically be dropped but I left it in to show that the Client object is doing something with/to the other two objects. In this same pattern you will see an open arrow from the ConcreteVisitor to the Visitor, signifying that the ConcreteVisitor inherits from Visitor.

Likewise, the dashed arrow in the Factory Method diagram, from ConcreteCreator to ConcreteProduct, shows that there is an association between the two and that ConcreteCreator has a dependency upon ConcreteProduct. That is, the ConcreteCreator is useless unless it has one or more ConcreteProducts to create.

If you still feel that there are corrections to be made, please let us know - it is our goal to make sure that this is as accurate as possible.

Also, check these out:
http://dn.codegear.com/article/31863#classdiagrams
http://www.digilife.be/quickreferences/QRC/UML%20Reference%20Card.pdf

Jason McDonald

Brian,

I'm a bit confused... Open arrows are used to show inheritance. Closed arrows are simply a directional attribute at the end of the association.

So, using the Visitor pattern as an example, the Client object is associated with both the Visitor and the Element. The arrow in this case could technically be dropped but I left it in to show that the Client object is doing something with/to the other two objects. In this same pattern you will see an open arrow from the ConcreteVisitor to the Visitor, signifying that the ConcreteVisitor inherits from Visitor.

Likewise, the dashed arrow in the Factory Method diagram, from ConcreteCreator to ConcreteProduct, shows that there is an association between the two and that ConcreteCreator has a dependency upon ConcreteProduct. That is, the ConcreteCreator is useless unless it has one or more ConcreteProducts to create.

If you still feel that there are corrections to be made, please let us know - it is our goal to make sure that this is as accurate as possible.

Also, check these out:
http://dn.codegear.com/article/31863#classdiagrams
http://www.digilife.be/quickreferences/QRC/UML%20Reference%20Card.pdf

Jason McDonald

Brian,

I'm a bit confused... Open arrows are used to show inheritance. Closed arrows are simply a directional attribute at the end of the association.

So, using the Visitor pattern as an example, the Client object is associated with both the Visitor and the Element. The arrow in this case could technically be dropped but I left it in to show that the Client object is doing something with/to the other two objects. In this same pattern you will see an open arrow from the ConcreteVisitor to the Visitor, signifying that the ConcreteVisitor inherits from Visitor.

Likewise, the dashed arrow in the Factory Method diagram, from ConcreteCreator to ConcreteProduct, shows that there is an association between the two and that ConcreteCreator has a dependency upon ConcreteProduct. That is, the ConcreteCreator is useless unless it has one or more ConcreteProducts to create.

If you still feel that there are corrections to be made, please let us know - it is our goal to make sure that this is as accurate as possible.

Also, check these out:
http://dn.codegear.com/article/31863#classdiagrams
http://www.digilife.be/quickreferences/QRC/UML%20Reference%20Card.pdf

Jason McDonald

Brian,

I'm a bit confused... Open arrows are used to show inheritance. Closed arrows are simply a directional attribute at the end of the association.

So, using the Visitor pattern as an example, the Client object is associated with both the Visitor and the Element. The arrow in this case could technically be dropped but I left it in to show that the Client object is doing something with/to the other two objects. In this same pattern you will see an open arrow from the ConcreteVisitor to the Visitor, signifying that the ConcreteVisitor inherits from Visitor.

Likewise, the dashed arrow in the Factory Method diagram, from ConcreteCreator to ConcreteProduct, shows that there is an association between the two and that ConcreteCreator has a dependency upon ConcreteProduct. That is, the ConcreteCreator is useless unless it has one or more ConcreteProducts to create.

If you still feel that there are corrections to be made, please let us know - it is our goal to make sure that this is as accurate as possible.

Also, check these out:
http://dn.codegear.com/article/31863#classdiagrams
http://www.digilife.be/quickreferences/QRC/UML%20Reference%20Card.pdf

Jason McDonald

As the post says, this is a contrived example meant only to illustrate a situation where opening multiple windows would cause concurrency issues. This was never meant to be an example of concurrency...

Sorry about that Brian - these were oversights and we are working to correct them now. Faux anything was never the goal...

The Chain of Responsibility and a couple aggregation symbols are strictly errors. As for the difference between the aggregation versus composition symbols, the distinction is pretty subtle but there are a couple places that it was incorrect. These are also being corrected right now.

Once the new copy comes out, please let us know if you see any problems with it.

Sorry about that Brian - these were oversights and we are working to correct them now. Faux anything was never the goal...

The Chain of Responsibility and a couple aggregation symbols are strictly errors. As for the difference between the aggregation versus composition symbols, the distinction is pretty subtle but there are a couple places that it was incorrect. These are also being corrected right now.

Once the new copy comes out, please let us know if you see any problems with it.

Sorry about that Brian - these were oversights and we are working to correct them now. Faux anything was never the goal...

The Chain of Responsibility and a couple aggregation symbols are strictly errors. As for the difference between the aggregation versus composition symbols, the distinction is pretty subtle but there are a couple places that it was incorrect. These are also being corrected right now.

Once the new copy comes out, please let us know if you see any problems with it.

Sorry about that Brian - these were oversights and we are working to correct them now. Faux anything was never the goal...

The Chain of Responsibility and a couple aggregation symbols are strictly errors. As for the difference between the aggregation versus composition symbols, the distinction is pretty subtle but there are a couple places that it was incorrect. These are also being corrected right now.

Once the new copy comes out, please let us know if you see any problems with it.

I just noticed that I started every sentence in the above post with the word "this". Nice.

edaj - I'm not sure why you are getting a 403... My site is up... What exactly did you click on?

The site is good, the content is good, the marketing is bulls*%t.

Like these?

http://www.mcdonaldland.info/2007/11/28/40/

I'd be willing to make these available...