DOCSLIB.ORG

Domain-Driven Design Using Naked Objects

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Prepared exclusively for ALESSANDRO CAROLLO What Readers Are Saying About Domain-Driven Design Using Naked Objects Over the years I have watched Dan strive to find the best ways to develop complex systems, and I’m glad he has taken this opportunity to share with you just some of his insights and experiences. As well as a champion of using the Naked Objects framework, Dan has now become one of its major contributors and committers, and I must say we are lucky to have his energy and enthusiasm directed at this project. Robert Matthews Creator, the Naked Objects framework This is a tutorial, a Naked Objects manifest, a software architecture book, and a user reference, all at the same time and combined amazingly well. You’ll find this book to be the best way of developing enterprise apps without repeating yourself. Sebastián Slutzky Software engineer, Department of Family and Social Affairs, Ireland Domain-driven design comes alive in this book, as it is demonstrated by example on every page. Furthermore, Naked Objects is shown to be the ideal support for the approach, focusing as it does on the core concepts of a system’s domain. Dan Haywood’s easy style means that the complex ideas in this book come across very clearly. Don’t just read this book...mark, learn, and inwardly digest! Andy Carmichael CEO, OpenXprocess Ltd This is a great hands-on guide to implementing domain-driven solutions using the innovative Naked Objects open source framework. Dylan Hayes Solutions architect, Deloitte Consulting Prepared exclusively for ALESSANDRO CAROLLO Dan does an excellent job of bringing domain-driven design out of the realm of theory and into practical reality. Dave Klein Author, Grails: A Quick-Start Guide This book is an excellent piece of work. It’s well written, thorough, engaging, and interesting. Eoin Woods Coauthor, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives This is a must-read book for CIOs, IT architects, and developers who want to understand how to build agile IT systems. Barry Keane Senior manager, BearingPoint This book is an indispensable companion in your Naked Objects journey whether you are starting with it or you have been using it for some time. Enrique Albert-Gleiser Enterprise software engineer If you are already developing with Naked Objects or are just starting out on a new project or merely curious, buy this book! Coming from one of the main drivers in the Naked Objects community, you will get an insight to this range of technologies that is absolutely invaluable. Aidan Coughlan Independent software developer Prepared exclusively for ALESSANDRO CAROLLO Prepared exclusively for ALESSANDRO CAROLLO Domain-Driven Design Using Naked Objects Dan Haywood The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Prepared exclusively for ALESSANDRO CAROLLO Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com Copyright © 2009 Dan Haywood. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-10: 1-934356-44-1 ISBN-13: 978-1-934356-44-9 Printed on acid-free paper. P1.0 printing, December 2009 Version: 2009-12-15 Prepared exclusively for ALESSANDRO CAROLLO Contents Preface 14 Who This Book Is For ....................... 15 How the Book Is Organized .................... 16 Case Study and Exercises ..................... 17 Conventions ............................. 18 Further Resources ......................... 18 I Tools 20 1 Getting Started 21 1.1 Understanding Domain-Driven Design .......... 21 1.2 The Essentials of DDD ................... 22 1.3 Introducing Naked Objects ................ 26 1.4 Naked Objects in About Five Minutes .......... 28 1.5 How Naked Objects Helps with DDD ........... 34 1.6 The Big Picture ....................... 37 2 Identifying the Domain Concepts 41 2.1 Introducing CarServ .................... 41 2.2 Getting Ready ........................ 43 2.3 Creating the Domain Classes ............... 45 2.4 Using Repositories to Locate Objects ........... 49 2.5 Identifying Objects to the User .............. 53 2.6 Capturing Simple Business Rules ............ 59 2.7 Providing Choices for Properties ............. 61 3 Relating Objects Together 64 3.1 Associating Objects ..................... 64 3.2 Adding Describing Concepts ................ 71 3.3 Capturing Business Rules for Collections ........ 77 Prepared exclusively for ALESSANDRO CAROLLO CONTENTS 8 4 Rapid Prototyping 80 4.1 Fixtures for Setting Up Domain Objects ......... 81 4.2 Fixtures for Setting Up the Clock ............. 84 4.3 Fixtures for Setting Up User Sessions .......... 87 4.4 Organizing Fixtures into Hierarchies ........... 91 5 Creating Behaviorally Complete Objects 95 5.1 Adding Behavior to Domain Objects ........... 96 5.2 Validating Action Arguments ............... 98 5.3 Making Actions Friendlier to Use ............. 101 5.4 Adding Finders to Repositories .............. 103 6 Implementing Business Rules 106 6.1 Validation Recap ...................... 107 6.2 Disabling Class Members ................. 110 6.3 Hiding Class Members ................... 113 6.4 Declarative Rules and the Object Life Cycle ....... 117 6.5 Validating the Entire Object ................ 120 7 Using Value Types 124 7.1 Identifying Value Types ................... 125 7.2 Pushing Business Rules onto a Value Type ....... 126 7.3 Adding a Third-Party Value Type ............. 129 7.4 Specifying Defaults and Other Characteristics ..... 137 8 Isolating Infrastructure Services 140 8.1 A Taxonomy of Services .................. 141 8.2 The Domain Object Container ............... 143 8.3 Dependency Injection .................... 145 8.4 Using Services in Fixtures ................. 146 8.5 Requirements for Writing Services ............ 147 8.6 Using Interfaces for Repositories ............. 149 8.7 Implementing a Calendar Service ............. 151 8.8 Hints and Tips for Writing Services ............ 154 II Techniques 157 9 Distributing Class Responsibilities 158 9.1 Applying Coad Colors .................... 159 9.2 Factoring Out Objects ................... 161 9.3 Balancing Responsibilities ................. 166 9.4 Representing Large Collections with Finder ....... 168 9.5 Contributing Actions from Services ............ 172 Report erratum Prepared exclusively for ALESSANDRO CAROLLO this copy is (P1.0 printing, December 2009) CONTENTS 9 10 Applying Domain Patterns 176 10.1 Type as Factory Pattern .................. 177 10.2 Knowledge Level Pattern .................. 184 10.3 Null Object Pattern ..................... 187 10.4 Role Object Pattern ..................... 189 10.5 User Peer Object Pattern .................. 194 10.6 Strategy Pattern ....................... 195 10.7 Process Object Pattern ................... 200 11 Keeping the Model Maintainable 206 11.1 Analyzing the Structure of CarServ ............ 207 11.2 Decoupling by Moving Responsibilities .......... 210 11.3 Decoupling by Introducing Interfaces .......... 212 11.4 Layering Modules ...................... 219 11.5 Decoupling by Splitting Classes .............. 221 11.6 Introducing an Application Package ........... 222 11.7 An Application Architecture Blueprint .......... 225 12 Scenario Testing 229 12.1 Writing Developer Tests .................. 230 12.2 Scenario Testing Using FitNesse ............. 235 12.3 Getting Ready to Write Scenario Tests .......... 236 12.4 Writing Scenario Tests ................... 241 12.5 Hints and Tips ........................ 249 III Practices 252 13 Developing Domain Applications 253 13.1 The Layered Architecture ................. 254 13.2 Deployment Options .................... 255 13.3 Which Option to Choose? ................. 258 13.4 Development Activities ................... 261 13.5 Configuration Management ................ 264 13.6 Working Effectively ..................... 267 14 Naked Objects as a Design Tool 271 14.1 Using Naked Objects Only in Development ....... 271 14.2 Decoupling from the Framework ............. 272 14.3 Programming Model Interaction Protocol ........ 276 14.4 Changing the Programming Model ............ 278 Report erratum Prepared exclusively for ALESSANDRO CAROLLO this copy is (P1.0 printing, December 2009) CONTENTS 10 15 Integrating with Web Frameworks 281 15.1 Deploying an Embedded Metamodel ........... 282 15.2 Integrating Layers with the Custom Presentation Option 293 16 Integrating with the Database 299 16.1 Configuring XML Persistence ............... 300 16.2 Mapping
Recommended publications
  • Learning Functional Programming in Scala Alvin Alexander

    Learning Functional Programming in Scala Alvin Alexander

    Learning Functional Programming in Scala Alvin Alexander A logical, step by step approach to learning functional programming Copyright Learning Functional Programming in Scala Copyright 2017 Alvin J. Alexander All rights reserved. No part of this book may be reproduced without prior written permission from the author. Disclaimer: This book is presented solely for educational purposes, and it’s also a work in progress. While best efforts have been used in prepar- ing this book, the author makes no representations or warranties of any kind and assume no liabilities of any kind with respect to the accuracy or completeness of the contents, and specifically disclaim any implied war- ranties of merchantability or fitness of use for a particular purpose. The author shall not be held liable or responsible to any person or entity with respect to any loss or incidental or consequential damages caused, or al- leged to have been caused, directly or indirectly, by the information or programs contained herein. Any use of this information is at your own risk. The advice and strategies contained herein may not be suitable for your situation. Version 0.1.1, published May 15, 2017 (The cover photo was taken on the Dalton Highway in Alaska, some- where between Fairbanks and Prudhoe Bay.) Contents 1 Changelog 1 2 Preface 3 3 Introduction (or, Why I Wrote This Book) 5 4 WhoThisBookisFor 11 5 Goals 15 6 Question Everything 23 7 Rules for Programming in this Book 33 8 One Rule for Reading this Book 39 9 What is “Functional Programming”? 41 10 What is This Lambda
  • Design Pattern Interview Questions

    Design Pattern Interview Questions

    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
  • Naked Objects: a Technique for Designing More Expressive Systems

    Naked Objects: a Technique for Designing More Expressive Systems

    Naked objects: a technique for designing more expressive systems Richard Pawson Robert Matthews Computer Sciences Corporation NakedObjects.org and Computer Science Department, Tdnity College, Dublin, IE rpawson@csc;com ABSTRACT OOUIs provide a number of advantages to the user including Naked objects is an approach to systems design in which core reduced modality [6], and greater expressiveness for the user business objects show directly through to the user interface, and [10], and have become the norm for 'creative' applications such in which all interaction consists of invoking methods on those as drawing, computer aided design (CAD), page make-up and objects in the noun-verb style. One advantage of this approach multimedia editing. OOUIs are far less common in transactional is that it reaults in systems that arc more expressive from the business systems. This may be because the need for viewpoint of the user: they treat the user like a problem solver, expressiveness is less clear. It may also be because the not as merely a process-follower. Another advantage is that the underlying structure of most transactional business applications, 1:1 mapping between the user's representation and the comprising scripted procedures and data operations, does not underlying model means that it is possible to auto-generate the map well onto an OOUI. former from the latter, which yields benefits to the development Surprisingly, though, even where a transactional business process. The authors have designed a Java-based, open source system is based upon a true business object model, the core toolkit called Naked Objects which facilitates this style of business objects are typically hidden from the user.
  • Design Patterns Design Patterns

    Design Patterns Design Patterns

    Design Patterns CSC207 – Software Design Design Patterns • Design pattern: – A general description of the solution to a well- established problem using an arrangement of classes and objects. • Patterns describe the shape of code rather than the details. – There are lots of them in CSC 301 and 302. Loop patterns from first year • Loop pattern: – A general description of an algorithm for processing items in a collection. • All of you (hopefully) have some loop patterns in your heads. • You don’t really need to think about these any more; you just use them, and you should be able to discuss them with your fellow students. • Some first-year patterns: – Process List – Counted Loop – Accumulator – Sentinel Process list pattern • Purpose: to process every item in a collection where you don’t care about order or context; you don’t need to remember previous items. • Outline: • Example: • Other example: darken every pixel in a picture Counted loop pattern • Purpose: to process a range of indices in a collection. • Outline: • Example: • Other example: print indices of even-length string Accumulator pattern • Purpose: to accumulate information about items in a collection. • Outline: • Example: • Other examples: sum, min, accumulate a list of items meeting a particular criterion. Sentinel pattern • Purpose: to remove a condition in a loop guard. • Outline: • Example: Sentinel pattern, continued • Here is the code that Sentinal replaces; note that i != list.size() is evaluated every time through the loop, even though it is false only once. Design Pattern
  • Presentación De Powerpoint

    Presentación De Powerpoint

    Software Architecture of Oviedoof University Modularity Science Computer of of Course 2018/2019 Jose E. Labra Gayo School Software Software School of Computer Science University of Oviedo Modularity Architecture Software Architecture of Oviedoof University Big Ball of Mud Modular decomposition Definitions Recommendations Modularity styles Layers Aspect Oriented decomposition Domain based decomposition Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Big Ball of Mud University Described by Foote & Yoder, 1997 Elements Lots of entities intertwined Constraints None Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Quality attributes (?) University Time-to-market Quick start It is possible to start without defining an architecture Incremental piecemeal methodology Solve problems on demand Cost Cheap solution for short-term projects Science Computer of of School Software Architecture Big Ball of Mud of Oviedoof Problems University High Maintenance costs Low flexibility at some given point At the beginning, it can be very flexible After some time, a change can be dramatic Inertia When the system becomes a Big Ball of Mud it is very difficult to convert it to another thing A few prestigious developers know where to touch Science Clean developers run away from these systems Computer of of School Software Architecture Big Ball of Mud of Oviedoof Some reasons University Throwaway code: You need an immediate fix for a small problem, a quick prototype or proof of concept When it is good
  • Five Considerations for Software Developers

    Five Considerations for Software Developers

    FiveFive ConsiderationsConsiderations forfor SoftwareSoftware DevelopersDevelopers Kevlin Henney [email protected] Presented at Jfokus, Stockholm, 30th January 2008. Kevlin Henney [email protected] [email protected] Curbralan Ltd http://www.curbralan.com Voice: +44 117 942 2990 Fax: +44 870 052 2289 Agenda • Introduction • Consideration 1: Economy • Consideration 2: Visibility • Consideration 3: Spacing • Consideration 4: Symmetry • Consideration 5: Emergence • Outroduction 2 What general qualities in a software architecture help to promote its success? We can of course focus on fitness for purpose, cost of change, organisational acceptance, and so on, but are there broad considerations that can be kept in mind when looking at the structural and developmental side of an architecture? Those involved in software have a lot to keep in mind as they negotiate the worlds inside and outside of their code and the relationship between them. For those interested in improving the state of their art there are many (many) sources of specific recommendations they can use to sharpen their practice. This talk takes a step back from the busy, overpopulated and often overwhelming world of such recommendations to focus on five general considerations that can inform more detailed recommendations and specific decisions. Introduction StructuralSoftwareStructural engineering engineering engineering is is theis the the science science science an and dand art art art of of designingof designing designing and and and making, making, making, with with with economyeconomy and and elegance, elegance, buildings,applications, buildings, bridges, bridges, bridges, frameworks, frameworks, frameworks, and and and other other other similar similar similar structuresstructures so so that that they they can can safely safely resist resist the the forces forces to to which which they they may may be be subjected.
  • Declare Property Class Accept Null C

    Declare Property Class Accept Null C

    Declare Property Class Accept Null C Woesome and nontechnical Joshuah planned inveterately and pull-outs his frontiers sourly and daftly. Unquiet Bernard fly-by very instructively while Rick remains ectotrophic and chastened. Sometimes stereoscopic Addie unnaturalizes her acorns proportionally, but unlidded Cat invert heinously or orientalizes rancorously. Even experts are accepted types and positional parameters and references, and assigns to. Use HasValue property to check has value is assigned to nullable type sometimes not Static Nullable class is a. Thank you declare more freely, declare property class accept null c is useful to provide only one dispiriting aspect of. Here we're defining a suggest that extracts all non-nullable property keys from plant type. By disabling cookies to accept all? The car variable inside counter Person class shouldn't be declared type grass and. Use JSDoc type. Any class property name, null safe code token stream of properties and corresponds to accept a class! Why death concept of properties came into C The decline because not two reasons If the members of a class are private then select another class in C. JavaScript Properties of variables with null or undefined. Type cup type as should pickle the null value variable the pastry of the variable to which null. CS31 Intro to C Structs and Pointers. Using the New Null Conditional Operator in C 6 InformIT. Your extra bet is to get themselves the good group of initializing all variables when you disabled them. This class that null values can declare variables declared inside an exception handling is nullable context switches a varargs in.
  • A Project to Model-Driven Development with Naked Objects and Domain-Driven Design

    A Project to Model-Driven Development with Naked Objects and Domain-Driven Design

    Elihu: A Project to Model-Driven Development with Naked Objects and Domain-Driven Design Samuel Alves Soares1 and Mariela Ines´ Cortes´ 2 1Federal Institute of Education, Science and Technology of Ceara,´ Taua,´ Ceara,´ Brazil 2State University of Ceara,´ Fortaleza, Ceara,´ Brazil Keywords: Model Driven Development, Naked Objects, Domain Driven Design, Domain Patterns, Design Patterns. Abstract: The model-driven development is a approach to creating software through well-defined models containing the information needed to generate the application. However, the software modeling in this approach requires the definition of application infrastructure artifacts in the model, such as user interface technologies and data persistence scheme, in order to transform modeling in final application. This makes the modeling complex, difficult to understand and maintain since new artifacts need to be added, failing to keep the focus on application business domain. To resolve this problem, we propose the Elihu project, a solution based on Naked Objects Pattern, Domain-Driven Design and software design patterns where the developer models just business objects and their characteristics related to the application domain. The full application is generated based on these software patterns and a Naked Objects Pattern framework is responsible for the application infrastructure code and the display of objects to users. The proposed solution benefits the creation of less complex models, that support evolution and modification of requirements along the development and the generation of full applications without manual intervention in the generated code. 1 INTRODUCTION 2006). On the other hand, the ambiguous nature of models and information redundancy along different The focus on the problem domain is pointed views of the same object make it difficult to maintain out as the ideal approach to the development of and make it difficult to adopt the MDD in the industry computer systems (Pawson, 2004).
  • Design Patterns

    Design Patterns

    CSE 403: Software Engineering, Winter 2016 courses.cs.washington.edu/courses/cse403/16wi/ Design Patterns Emina Torlak [email protected] Outline • Overview of design patterns • Creational patterns • Structural patterns • Behavioral patterns 2 introoverview of design patterns What is a design pattern? 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • A technique for making code more flexible or efficient • reduce coupling among program components • reduce memory overhead 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • A technique for making code more flexible or efficient • reduce coupling among program components • reduce memory overhead • Shorthand for describing program design • a description of connections among program components • the shape of a heap snapshot or object model 4 Why should you care? • You could come up with these solutions on your own … • But you shouldn't have to! • A design pattern is a known solution to a known problem. 5 Types of design patterns • Creational patterns • how objects are instantiated • Structural patterns • how objects / classes can
  • Pawson Thesis.Pdf

    Pawson Thesis.Pdf

    Naked objects A thesis submitted to the University of Dublin, Trinity College for the degree of Doctor of Philosophy Richard Pawson, Department of Computer Science, Trinity College, Dublin June 2004 1 Foreword by Trygve Reenskaug (Author’s note: Prof. Reenskaug was the external examiner for this thesis. One of the pioneers of object-oriented programming, he is best known as the inventor of the Model- View-Controller pattern. After the thesis was accepted, he generously agreed to write a foreword to the electronically-published version.) The world’s shipbuilding industry went through a heavy modernization program through the nineteen fifties and sixties. My colleague Kjell Kveim invented a control unit for the numerical control of machine tools such as flame cutters. The first unit was installed at the Stord shipyard in 1960 and opened the field for integrated computer aided design and manufacturing. The matching design system, Autokon, was first deployed at the Stord Yard in 1963. Autokon was subsequently adopted by most major shipyards around the world and was still in use by the late nineties. The purpose of Autokon was to empower the ship’s designers. It had a central database holding important information about the shape of the hull, the position of frames and decks, and the shapes of the parts. There was a language that permitted the designers to specify parts in shipbuilding terminology. There was a designer programming facility so that they could specify families of similar parts. Autokon was developed in close collaboration between shipbuilders and scientists. We considered ourselves as tool builders; the success criterion was that the tools should be handy, practicable, serviceable and useful.
  • Table of Contents

    Table of Contents

    Table of Contents ± -—T^jTp^om Object-Oriented to Functional Programming 5 Chajava- an introduction 5 java programming paradigms 6 CO imperative programming CD Real-life imperative example Object-oriented paradigm 7 Objects and classes 7 Encapsulation 7 Abstraction 8 Inheritance 8 Polymorphism 9 Declarative programming 10 Functional programming 11 Working with collections versus working with streams 11 An introduction to Unified Modeling Language 12 Class relations 14 Generalization 15 Realization 15 Dependency 16 Association 16 Aggregation 16 Composition 17 Design patterns and principles 17 Single responsibility principle 18 Open/closed principle 20 Liskov Substitution Principle 20 Interface Segregation Principle 22 Dependency inversion principle 23 Summary 24 Chapter 2: Creational Patterns 27 Singleton pattern 27 Synchronized singletons 29 Synchronized singleton with double-checked locking mechanism 30 Lock-free thread-safe singleton 30 tu * y and lazy loacling 31 i he factory pattern 31 Simple factory pattern 32 Table of Contents Static factory 33 Simple factory with class registration using reflection 34 Simple factory with class registration using Product.newlnstance 35 Factory method pattern 36 Anonymous concrete factory 38 Abstract factory 38 Simple factory versus factory method versus abstract factory 40 Builder pattern 40 Car builder example 41 Simplified builder pattern 43 Anonymous builders with method chaining 44 Prototype pattern 45 Shallow clone versus deep clone Object pool pattern Summary аэоэсБ Chapter 3: Behavioral Patterns
  • Pharo by Example

    Pharo by Example

    Portland State University PDXScholar Computer Science Faculty Publications and Computer Science Presentations 2009 Pharo by Example Andrew P. Black Portland State University, [email protected] Stéphane Ducasse Oscar Nierstrasz University of Berne Damien Pollet University of Lille Damien Cassou See next page for additional authors Let us know how access to this document benefits ouy . Follow this and additional works at: http://pdxscholar.library.pdx.edu/compsci_fac Citation Details Black, Andrew, et al. Pharo by example. 2009. This Book is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. For more information, please contact [email protected]. Authors Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker This book is available at PDXScholar: http://pdxscholar.library.pdx.edu/compsci_fac/108 Pharo by Example Andrew P. Black Stéphane Ducasse Oscar Nierstrasz Damien Pollet with Damien Cassou and Marcus Denker Version of 2009-10-28 ii This book is available as a free download from http://PharoByExample.org. Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz and Damien Pollet. The contents of this book are protected under Creative Commons Attribution-ShareAlike 3.0 Unported license. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).