Slashdot Mirror

Sometime this seems to work out well, sometimes not. I thought that the Pattern Languages of Program Design editors did a nice job on making that work, and the same goes for the excellent Game Programming Gems series.

On the other hand, sometime you can really tell that one author wrote a book and was interested in the topic - i.e., Component Development for the Java Platform by Stuart Halloway comes to mind. This was an excellent book for intermediate to advanced Java programmers and Stuart's interest in how things really work in Java serialization, classloaders, and so forth shines through.

And hopefully the same goes for PMD Applied :-)

So how do you feel about "Holub on Patterns: Learning Design Patterns by Looking at code"?

And what about all the other patterns?

I use UML to design and document apps I write, when it's helpful. Usually for apps it takes longer than an eight hour day to write, and will see change in the future. It provides a birds-eye view of what the app is doing, and how it represents data.

How many open source projects do you see that come bundled with documentation cleary explaining how its internal structures look and relate, and how the program was intended to behave? If you answered "Few to None", you'd be today's winner! Monty, tell 'em what they've won!

UML is a visual modeling *language* used to communicate program behavior and data structure concepts with others (mostly humans), typically in an object-oriented context. As a bonus, there are quite a few visual modeling tools that work with UML. Some emit corresponding code in Java, Python, C++ and a handful of other languages. Some are OSS/FS, while others are proprietary and pricey.

UML is also handy when weaving Design Patterns into your application framework. If you're into designing your applications before you code them, you probably know about Design Patterns and the GoF book. Design Patterns are another kind of *language* for communicating about structure and behavior.

I'm not saying the only way to design an app is with DP and UML, but together they are very effective at communicating data structures, how objects/structures are to be constructed, and program behavior. Which, not coincidentally, are the three main categories of code patterns described in the GoF book.

The main point of UML is clear communication; for DP it's creating solid designs. To create an application that works well (does what's intended, doesn't need refactoring/rewriting when new data formats or behaviors are expected in the future), and is easy for other programmers to pick up (program logic easily understood, relationships between classes and other structures easily identified and grokked), it is good to choose a common language to communicate those things, besides the one the app is written in.

For the folks who pedantically attack UML as being part or product of an authoritarian regime - well, it's just a tool that helps you get your job done, and communicate effectively with others. Sometimes it will get used by hardliners I suppose. The flip side to that is, are you communicating clearly and consistently?

Maybe that doesn't matter to you, but maybe also you would be better off for expanding your personal toolset, and making yourself better understood.

I did XP in extreme C++ for about a year (by extreme C++, I mean boostified, Alexandrescu'd C++). We used CppUnit for our test framework.

I'm not especially satisfied with the currently available C++ unit testing frameworks. CppUnit and Boost's both have trade-offs. I suspect they'll both get better, though.

The Ant-Contrib project's cc task works pretty well, in my limited experience. I was playing around with it just this weekend. I've yet to set up a tinderbox build process, but I don't see why this wouldn't be easy with either Cruise Control or good ol' cron.

In my mind, the two biggest hurdles with doing XP in C++ are build speed and developer prejudice. You can tackle build speed with a combination of ccache, distcc, good programming principles, and cash. Tackling developer prejudice is harder. A lot of C++ programmers like to write low-level, unsafe, old school C++ code. Modern C++ mostly lets you discard unsafe coding practices without sacrificing efficiency. Whether you can convince an old C++ programmer of this is another matter; it depends on the person. I've had decent success taking Java programmers and teaching them modern C++ via pair programming.

Using Boost helps, indirectly. You write safer code, which gives you a faster development cycle. All in all, I think the basic tools are there. It might be a little harder to get fancy lava lamp integration going with C++, but there's no reason why you can't have a good build process. It's just that a lot of C++ projects haven't evolved (I think this is due, in part, to the fact that the C++ community is late to the internet; a lot of C++ programmers just don't know what's, out there.

cheers,

Jon

Sounds to me like you need to get grips with some basic design patterns, which requires a copy of the infamous Gang of Four book:

Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (ISBN 0-201-63361-2).

Essentially what they lay down is a simple catalogue of re-usable designs for simple and ubiquitous problems. Or to shamelessly rip from the preface:

"This book isn't an introduction to object-oriented technology or design. Many books already do a good job of that. This book assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well. You definitely shouldn't have to rush to the nearest dictionary the moment we mention ``types'' and ``polymorphism,'' or ``interface'' as opposed to ``implementation'' inheritance."

See http://hillside.net/patterns/DPBook/DPBook.html

Creating SuiteRunner was a huge amount of work. Despite my frustrations with JUnit, it would have been orders of magnitude easier to decipher JUnit's source code than to create a brand new testing toolkit.

I'm not sure if this includes the "additional content" but it has a tar of the code from the book:

Design Patterns Source

I'll vouch for the book. It was one of the textbooks from a Programming Languages and Paradigms class that I took. The first 2/3 of the class was advanced Java topics, but it became significantly more interesting when we dove into design patterns.

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, a.k.a. The Gang of Four, did an excellent job. If you don't buy it, at least pick up a copy at Borders and skim it. You will be a better programmer for it.

Here's another good breakdown of the book

I guess I am looking for a sort of 'Design Patterns applied to a big deskptop application' sort of discussion.

Then The GOF Design Patterns may be what you're looking for. The case study used for most of the pattern illustrations is that of designing a word processor -- which is no simple feat. A lot of these can be extended to any type of a UI architecture.

To expand on batkiwi's comment above, here's the Gang of Four entry in the Jargon File:

Gang of Four n.

(also abbreviated `GOF') [prob. a play on the `Gang Of Four' who briefly ran Communist China after the death of Mao] Describes either the authors or the book "Design Patterns: Elements of Reusable Object-Oriented Software" published in 1995 by Addison-Wesley (ISBN 0-201-63361-2). The authors forming the Gang Of Four are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. They are also sometimes referred to as `Gamma et. al.' The authors state at http://www.hillside.net/patterns/DPBook/GOF.html "Why are we ... called this? Who knows. Somehow the name just stuck." The term is also used to describe any of the design patterns that are used in the book, referring to the patterns within it as `Gang Of Four Patterns.'

Hi,

If Martin Fowler's Refactoring is not on your list, it should be added.

This book is changing the way people write code, and is up there with Knuth's books, Kernighan and Ritchie, and Design Patterns in terms of influence over software development.

...on a database of any kind, ever. Bravo, and for the link to extremeprogramming as well, also important.

I'd throw into the mix the very important software component design book, "Design Patterns: Elements of Reusable Object-Oriented Software" [ISBN 0-201-63361-2]

• 1.) Code uses linguistic devices.

  The syntax of a computer language is expressive in the same manner as the syntax of a natural language. In Section 1.2 of Programming Perl, Larry Wall describes the base structures of the Perl language using linguistic examples.

  • The nouns of Perl are variables. A variable is just a handy place to keep something, a place with a name, so you know where to find your special something when you come back looking for it later.[italics and bold added] Nouns can be singular or plural: We call a singular variable a scalar, and a plural variable an array
  • The verbs of Perl are the operators and sub-routines.
    Verbs are also sometimes called subroutines (when user-defined) or operators (when built-in). They are often imperative: As is typical of your typical imperative computer language, many of the verbs in Perl are commands: they tell the Perl interpreter to do something. Verbs can also be interrogative: Some verbs are for asking questions, and are useful in conditional statements.

  I want to get this post up soon, but I'm sure I could find a code example for every language structure expressed in English 101.

  (Code also has the ability to express metaphor in a powerful way. Music visualization plugins like G-Force translate sound into visuals, etc.)

• 2.) Code is most commonly used to express real-world concepts in a structured manner.

  Nearly all business programming consists of expressing real-world Things and their Capabilities in an ordered manner. For example, a short piece of Java code: public interface ShoppingCart { public void addProduct( Product p ); // add a product to the Shopping Cart public boolean checkOut(); // return true if successful checkout }

  This is an expression of a real-world Thing ( a grocery cart ) and what can be done with that Thing( add products to the cart, check out ).

The only difference is that computer languages have rules, natural languages have parameters. Every statement in a computer language is ordered, while statements in natural languages may or may not be ordered. The ordered nature of computer languages does not mean that all programs are a set of instructions. In object oriented programming attention is given to the relationships between the Objects (Design Patterns).

Code can express a wide range of properties of real world things, processes, and relationships. This expression of real world properties is not merely an enumeration (like a phone book), but a metaphor used to make certain tasks understandable to those who read the code. Let me repeat... the only difference between computer and natural languages is that computer languages are structured. Last time I checked, I don't think that being structured makes speech less expressive or ineligible for First Amendment protections.

P.S.: I realize that instructions in the form of programs can be performed by a computer; but this is analagous to saying that bomb instructions in the form of a book can be performed by an individual. The law protects the Anarchist Cookbook, and it should protect any form of code as well. A complementary legal tactic could be to dredge up case history where instructions to perform illegal actions were protected as speech.

It's amazing how local transformations can introduce quality to systems with no conceptual integrity.

But to really be effective, you have to be aware of where you started and where you are headed. The big picture is a lot of little pictures, hopefully connected by a coherent architecture.

One of the best ways to move toward coherent architectures is to start thinking in terms of design by contract. Think of preconditions, postconditions, and invariants as part of the public interface, just like routines' signatures. If your language doesn't support them directly, you can probably get free 3rd party tools that will help. Even if you can't, put them in as comments. Program code is documentation of the write once, read many times, variety.

Learn and get comfortable with as many variants of as many patterns as you can. When you use them, mention them in your comments.

This anonymous coward is Tom Morrisette

If you didn't understand a word of this review [and I've got to admit I came close] then perhaps this web site will help

Design Patterns

This is the homepage of the previous book in the series.