Smalltalk Patterns: Best Practices / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $52.85
Usually ships in 1-2 business days
(Save 20%)
Other sellers (Paperback)
  • All (8) from $52.85   
  • New (6) from $52.85   
  • Used (2) from $52.85   

Overview


This classic book is the definitive real-world style guide for better Smalltalk programming. This author presents a set of patterns that organize all the informal experience successful Smalltalk programmers have learned the hard way. When programmers understand these patterns, they can write much more effective code. The concept of Smalltalk patterns is introduced, and the book explains why they work. Next, the book introduces proven patterns for working with methods, messages, state, collections, classes and formatting. Finally, the book walks through a development example utilizing patterns. For programmers, project managers, teachers and students -- both new and experienced. This book presents a set of patterns that organize all the informal experience of successful Smalltalk programmers. This book will help you understand these patterns, and empower you to write more effective code.
Read More Show Less

Product Details

  • ISBN-13: 9780134769042
  • Publisher: Prentice Hall
  • Publication date: 10/3/1996
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 240
  • Product dimensions: 7.00 (w) x 9.00 (h) x 0.70 (d)

Meet the Author

Kent Beck is the founder and director of Three Rivers Institute (TRI). His career has combined the practice of software development with reflection, innovation, and communication. His contributions to software development include patterns for software, the rediscovery of test-first programming, the xUnit family of developer testing tools, and Extreme Programming. He currently divides his time between writing, programming, and coaching. Beck is the author/co-author of Implementation Patterns, Extreme Programming Explained: Embrace Change 2nd Edition, Contributing to Eclipse, Test-Driven Development: By Example, Planning Extreme Programming, Smalltalk Best Practice Patterns, and the JUnit Pocket Guide. He received his B.S. and M.S. in Computer Science from the University of Oregon.
Read More Show Less

Read an Excerpt

This preface will explain what this book is about.

It will convince you to buy this book, or you will know why you shouldn't (more of the former than the latter, I hope).

What's it all about?

This book is about the simple things experienced, successful Smalltalkers do that beginners don't. In a sense, it is a style guide. I have tried to penetrate beneath the surface, though, to get at the human realities that make the rules work instead of focusing solely on the rules themselves.

The topics covered are the daily tactics of programming:

How do you choose names for objects, variables, and methods?
How do you break logic into methods?
How do you communicate most clearly through your code?

These are small scale issues. There are also many bigger technical reasons why projects fail (and many more nontechnical reasons).

The attraction of this set of issues is that they are so tractable. You don't have to be a programming wizard to pick good names, you just have to have good advice.

The advice is broken into 92 patterns. Each pattern presents:
a recurring daily programming problem;
the tradeoffs that affect solutions to the problem; and a concrete recipe to create a solution for the problem.

For example, here is a summary of a pattern called Role Suggesting Temporary Variable Name:
Problem: What do you name a temporary variable?
Tradeoffs:
You want to include lots of information in the name.
You want the name to be short so it is easy to type and doesn't make formatting difficult.
You don't want redundant information in the name.
You want to communicate why the variable exists. You want to communicate the type of the variable (i.e. what messages it is sent). Solution: Name the variable after the role it plays. The type can be inferred from context, and so doesn't need to be part of the name. You will see in the body of the book that each pattern occupies a page or two. Each pattern includes examples (and counter-examples) from the standard Smalltalk images.

Each pattern also talks about related patterns. The patterns don't stand in isolation, 92 independent bits of advice. Patterns work together, leading you from larger problems to smaller. Together they form a system or language. The system, as a whole, allows you to focus on the problem at hand, confident that tomorrow you can deal with tomorrow's problems.

Why should you read it?

Learning—If you are just learning Smalltalk, these patterns will give you a big jump start on making effective use of the system. Because the patterns aren't just rules, you can smoothly go from merely following the patterns, to understanding why they are the way they are, to formulating your own patterns. You will need a good basic introduction to Smalltalk in addition to this book, but reading them together will greatly accelerate your learning.

Programming

If you program in Smalltalk, these patterns will give you a catalog of techniques that work well. You will have discovered or invented many of them yourself, but the patterns may give you a fresh perspective on why they work present nuances you hadn't considered.

Teaching

If you teach Smalltalkers, either as a mentor or in classroom training, these patterns will give you large bag of instructional material. If you are trying to explain why code should be different, it is much more satisfying for you and the learner to be able to discuss the pattern and how it applies to the particular situation.

Managing

If you manage Smalltalk projects, you may be struggling with how to apply good software engineering principles to Smalltalk. These patterns don't address that topic directly, but they can become the basis of a common vocabulary for your developers.

What isn't it about?

This is not a book of methodology. It will not guide your entire development process. You can use it with your existing process, whether you invented it or it came out of a book.

This book is about making code that works for you. This is not a book of philosophy. If you want to understand what makes programs good in the abstract, if you went to learn to write patterns yourself, or understand their philosophical or psychological basis, you won't find any help here. This book is for people who have programs to write and want to do so as quickly, safely, and effectively as possible. This is not a book of design. If design is the process of defining the relationships among small families of objects, the resulting problems repeat just as surely as do implementation problems. Design patterns are very effective at capturing that commonality. They just aren't the topic of this book.

This book is about making Smalltalk work for you.

Making objects work for you is an entirely different topic.

Acknowledgments

I would like to thank the many people who contributed to this volume. First I would like to thank the Xerox PARC Learning Research Group (Alan Kay, Adele Goldberg, Dan Ingalls, Diana Merry-Shapiro, Ted Kaehler, Larry Tesler, and Bob Flegel) for having the insights in the first place, so I had something to write down.

I would like to thank my mentor and intellectual partner, Ward Cunningham, for showing me the way and sharing his insights. Many of the patterns here he identified and/or named. Thanks to my reviewers (Dirk Riehle, David N. Smith, Mitchell Model, Bill Reynolds, Dave Smith, Trygve Reenskaug, Ralph Johnson, John Brant, Don Roberts, Brian Foote, Brian Marick, Joe Yoder, Ian Chai, Mark Kendrat, Eric Scouten, Charles Herring, Haidong Ye, Kevin Powell, Rob Brown, Kyle Brown, Bobby Woolf, Harald Mueller, Steve Hayes, Bob Biros, David Warren, Gert Florijn, Mark L. Fussell, Martin Fowler, Chuck Siska, Chris Bird, Ron Jefferies, Volker Wurst, Peter Epstein, Thomas Murphy, Michel Brassard, Ron Jefferies, John Sellers, Steve Messick, Darrow Kirkpatrick, Phoenix Tong, Doug Lea, Randy Stafford, Sharry Fealk and all the reviewers who didn't put their names on their comments) for reading early rough drafts carefully. Finally, this book would never have been finished without my ever patient but gently prodding editor, Paul Becker.

Read More Show Less

Table of Contents

1. Introduction.

Coding. Talking Programs. Good Software. Style. What's Missing? Book Organization. Adoption. Learning a Pattern.

2. Patterns.

Why Patterns Work. Role of Patterns. Reading. Development. Review. Documentation. Clean Up. Format.

3. Behavior.

Methods. Composed Method. Constructor Method. Constructor Parameter Method. Shortcut Constructor Method. Conversion. Converter Method. Converter Constructor Method. Query Method. Comparing Method. Reversing Method. Method Object. Execute Around Method. Debug Printing Method. Method Comment. Messages. Message. Choosing Message. Decomposing Message. Intention Revealing Message. Intention Revealing Selector. Dispatched Interpretation. Double Dispatch. Mediating Protocol. Super. Extending Super. Modifying Super. Delegation. Simple Delegation. Self Delegation. Pluggable Behavior. Pluggable Selector. Pluggable Block. Collecting Parameter.

4. State.

Instance Variables. Common State. Variable State. Explicit Initialization. Lazy Initialization. Default Value Method. Constant Method. Direct Variable Access. Indirect Variable Access. Getting Method. Setting Method. Collection Accessor Method. Enumeration Method. Boolean Property Setting Method. Role Suggesting Instance Variable Name. Temporary Variables. Temporary Variable. Collecting Temporary Variable. Caching Temporary Variable. Explaining Temporary Variable. Reusing Temporary Variable. Role Suggesting Temporary Variable Name.

5. Collections.

Classes. Collection. OrderedCollection. RunArray. Set. Equality Method. Hashing Method. Dictionary. SortedCollection. Array. ByteArray. Interval. Collection Protocol. IsEmpty. Includes:. Concatentation. Enumeration. Do. Collect. Select/Reject. Detect. Inject:into:. Collection Idioms. Duplicate Removing Set. Temporarily Sorted Collection. Stack. Queue. Searching Literal. Lookup Cache. Parsing Stream. Concatenating Stream.

6. Classes.

Simple Superclass Name. Qualified Subclass Name.

7. Formatting.

Inline Message Pattern. Type Suggesting Parameter Name. Indented Control Flow. Rectangular Block. Guard Clause. Conditional Expression. Simple Enumeration Parameter. Cascade. Yourself. Interesting Return Value.

8. Development Example.

Problem. Start. Arithmetic. Integration.

Summary.

Appendix A: Quick Reference.

Index.

Read More Show Less

Preface

This preface will explain what this book is about.

It will convince you to buy this book, or you will know why you shouldn't (more of the former than the latter, I hope).

What's it all about?

This book is about the simple things experienced, successful Smalltalkers do that beginners don't. In a sense, it is a style guide. I have tried to penetrate beneath the surface, though, to get at the human realities that make the rules work instead of focusing solely on the rules themselves.

The topics covered are the daily tactics of programming:

How do you choose names for objects, variables, and methods?
How do you break logic into methods?
How do you communicate most clearly through your code?

These are small scale issues. There are also many bigger technical reasons why projects fail (and many more nontechnical reasons).

The attraction of this set of issues is that they are so tractable. You don't have to be a programming wizard to pick good names, you just have to have good advice.

The advice is broken into 92 patterns. Each pattern presents:
a recurring daily programming problem;
the tradeoffs that affect solutions to the problem; and
a concrete recipe to create a solution for the problem.

For example, here is a summary of a pattern called Role Suggesting Temporary Variable Name:
Problem: What do you name a temporary variable?
Tradeoffs:
You want to include lots of information in the name.
You want the name to be short so it is easy to type and doesn't make formatting difficult.
You don't want redundant information in the name.
You want to communicate why the variable exists. You want to communicate the type of the variable (i.e. what messages it is sent). Solution: Name the variable after the role it plays. The type can be inferred from context, and so doesn't need to be part of the name. You will see in the body of the book that each pattern occupies a page or two. Each pattern includes examples (and counter-examples) from the standard Smalltalk images.

Each pattern also talks about related patterns. The patterns don't stand in isolation, 92 independent bits of advice. Patterns work together, leading you from larger problems to smaller. Together they form a system or language. The system, as a whole, allows you to focus on the problem at hand, confident that tomorrow you can deal with tomorrow's problems.

Why should you read it?

Learning—If you are just learning Smalltalk, these patterns will give you a big jump start on making effective use of the system. Because the patterns aren't just rules, you can smoothly go from merely following the patterns, to understanding why they are the way they are, to formulating your own patterns. You will need a good basic introduction to Smalltalk in addition to this book, but reading them together will greatly accelerate your learning.

Programming

If you program in Smalltalk, these patterns will give you a catalog of techniques that work well. You will have discovered or invented many of them yourself, but the patterns may give you a fresh perspective on why they work present nuances you hadn't considered.

Teaching

If you teach Smalltalkers, either as a mentor or in classroom training, these patterns will give you large bag of instructional material. If you are trying to explain why code should be different, it is much more satisfying for you and the learner to be able to discuss the pattern and how it applies to the particular situation.

Managing

If you manage Smalltalk projects, you may be struggling with how to apply good software engineering principles to Smalltalk. These patterns don't address that topic directly, but they can become the basis of a common vocabulary for your developers.

What isn't it about?

This is not a book of methodology. It will not guide your entire development process. You can use it with your existing process, whether you invented it or it came out of a book.

This book is about making code that works for you. This is not a book of philosophy. If you want to understand what makes programs good in the abstract, if you went to learn to write patterns yourself, or understand their philosophical or psychological basis, you won't find any help here. This book is for people who have programs to write and want to do so as quickly, safely, and effectively as possible. This is not a book of design. If design is the process of defining the relationships among small families of objects, the resulting problems repeat just as surely as do implementation problems. Design patterns are very effective at capturing that commonality. They just aren't the topic of this book.

This book is about making Smalltalk work for you.

Making objects work for you is an entirely different topic.

Acknowledgments

I would like to thank the many people who contributed to this volume. First I would like to thank the Xerox PARC Learning Research Group (Alan Kay, Adele Goldberg, Dan Ingalls, Diana Merry-Shapiro, Ted Kaehler, Larry Tesler, and Bob Flegel) for having the insights in the first place, so I had something to write down.

I would like to thank my mentor and intellectual partner, Ward Cunningham, for showing me the way and sharing his insights. Many of the patterns here he identified and/or named. Thanks to my reviewers (Dirk Riehle, David N. Smith, Mitchell Model, Bill Reynolds, Dave Smith, Trygve Reenskaug, Ralph Johnson, John Brant, Don Roberts, Brian Foote, Brian Marick, Joe Yoder, Ian Chai, Mark Kendrat, Eric Scouten, Charles Herring, Haidong Ye, Kevin Powell, Rob Brown, Kyle Brown, Bobby Woolf, Harald Mueller, Steve Hayes, Bob Biros, David Warren, Gert Florijn, Mark L. Fussell, Martin Fowler, Chuck Siska, Chris Bird, Ron Jefferies, Volker Wurst, Peter Epstein, Thomas Murphy, Michel Brassard, Ron Jefferies, John Sellers, Steve Messick, Darrow Kirkpatrick, Phoenix Tong, Doug Lea, Randy Stafford, Sharry Fealk and all the reviewers who didn't put their names on their comments) for reading early rough drafts carefully. Finally, this book would never have been finished without my ever patient but gently prodding editor, Paul Becker.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted November 8, 2008

    No text was provided for this review.

Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)