Busy Java Developer's Workshop using Apche Isis Ted Neward Neward - PowerPoint PPT Presentation

Busy Java Developer's Workshop using Apche Isis Ted Neward Neward & Associates http://www.tedneward.com | ted@tedneward.com

Objectives Why are we here? – Explore concepts around "domain objects" specifically, the idea of using them to build an application – Understand the history of Smalltalk and MVC – Play around with NakedObjects • Apache Isis (Java) • RestfulObjects (HTTP-API)

Credentials Who is this guy? – Principal -- Neward & Associates – Director -- Developer Relations, Smartsheet.com – Microsoft MVP (F#, C#, Architect); Java Expert (JSRs 175, 277) – Author Professional F# 2.0 (w/Erickson, et al; Wrox, 2010) Effective Enterprise Java (Addison-Wesley, 2004) SSCLI Essentials (w/Stutz, et al; OReilly, 2003) Server-Based Java Programming (Manning, 2000) – Blog: http://blogs.tedneward.com – Writing: http://www.newardassociates.com/#/writing – Twitter: @tedneward – For more, see http://www.newardassociates.com/#/about

Format How we gonna do this?

Format Lecture/lab format – I will lecture for a bit – You will code/debug/explore for a bit I will try to wander the room and help where I can – Lather, rinse, repeat – Turn in your evals and you are free!

Format "The Rules" – Pairing and interaction absolutely encouraged – Googling/Binging/looking stuff up online absolutely encouraged – Leaving the room during a "lab" absolutely encouraged (if necessary) – Jumping ahead encouraged, but I can only help for "this" step

Format "Requests" – set the phone/volume/etc to vibrate basically, don't disturb the neighbors – ask questions! if you're thinking it, so are other people – ... but let's keep the focus to the here and now there's a lot to cover, so I need to keep us focused

Format Ready? – Any questions? – If not, here we go.... – Last chance... abandon hope, all ye who remain...

History Where it all began

Smalltalk: Overview The original O-O language

Overview Smalltalk is... – object-oriented – dynamically-typed – message-passing – reflective ... programming language ... and environment

Overview Current Smalltalk implementations – Amber (runs in Javascript browsers!) http://www.amber-lang.net/ – Squeak https://en.wikipedia.org/wiki/Squeak – GNU Smalltalk https://en.wikipedia.org/wiki/GNU_Smalltalk – Concomm Smalltalk (ObjectStudio, VisualWorks) http://www.cincomsmalltalk.com/main/ – Pharo http://pharo.org/

Smalltalk A History

History Smalltalk's history is long and distinguished – began development in 1969 – developed at Xerox PARC – invented by Alan Kay (with help from Dan Ingalls) – influenced by Lisp, Simula, Logo, Sketchpad – first release -- Smalltalk-71 – first public release -- Smalltalk-80

History Smalltalk influenced... – AppleScript – Common Lisp Object System – Dart – Dylan – Erlang – Etoys – Falcon

History Smalltalk influenced... – Go – Groovy – Io – Ioke – Java – Lasso – Lisaac

History Smalltalk influenced... – Logtalk – NewtonScript – Object REXX – Objective-C – PHP 5 – Perl 6

History Smalltalk influenced... – Python – Ruby – Scala – Scratch – Self

History Began on a bet – can a programming language based on the idea of message passing inspired by Simula be implemented in 'a page of code'? – incidentally, Kay answered that in "a few mornings"

History Objects introduced in Smalltalk-80 – Smalltalk object can do three things: • hold state (references to other objects) • receive a message from itself or another object • in the course of processing a message, send a message to itself or another object – no difference between values which are objects and primitive types – "in Smalltalk everything is an object" – classes are also instances of objects

History Smalltalk incorporated IDE and runtime into one tool – this is the "Smalltalk browser" – objects were visual objects – manipulate the objects to manipulate the environment – image files were of the entire runtime

Model/View/Controller Separating display from logic

Model/View/Controller MVC is a design pattern that appears frequently in GUI systems – Model represents the state – Controller represents the logic – View represents the display/UI

Model/View/Controller Origins lie in Smalltalk – Models were objects – Controllers were objects – Views were objects – Today, this is an idiom known as "Naked Objects"

Model/View/Controller MVC showed up in a number of GUI systems – Windows UI frameworks called it "Document/View" – Java Swing built around MVC quite deeply • tables, lists, all used models extensively • even the actual UI code was split along view/controller lines; AbstractButton defined basic button behavior, and deferred to another class to do the actual pixel-drawing work – iOS uses it (ViewControllers are controllers)

Model/View/Controller In the original MVC... – Models were often connected to more than one View – Controllers coordinated view updates as model changed – Models, Views and Controllers relatively loosely coupled – Web adaptation of MVC changed this to a 1:1 View/Controller Web views and controllers never reused

Model/View/Controller Parting thoughts – Models are not necessarily Domain Objects community is split over this one – Views should not contain "logic" • except for logic that is UI-focused • community is split over this one too

Model/View/Controller MVC has spawned a lot of similar ideas/patterns – Hierarchical model-view-controller – Model-view-adapter – Model-view-presenter – Model View ViewModel – Observer – Presentation-abstraction-control – Three- or n-tier architecture

Model/View/Controller Resources – For more details, see http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80 %93controller – Observer pattern comes from "Design Patterns" (GOF book) Gamma, Helm, Johnson, Vlissides – Presentation-abstraction-control comes from "POSA 1" Buschmann, Meuneir, Rohnert, Sommerlad, Stal

Naked Objects Wait.... what?

Naked Objects: Overview In the old days... – objects were intended to be directly user-manipulable things • data directly modified/changed • methods directly invoked • connections directly displayed/modified – ... but we have since lost that simple idea

Naked Objects: Overview What's wrong with the way we do applications today? – too much complexity in the UI code – too many opportunities to get the business rules wrong – too much time spent building the system – too much effort required to understand/maintain it

Naked Objects: Overview New idea: Let the UI center around the objects – "All business logic should be encapsulated onto the domain objects." – "The user interface should be a direct representation of the domain objects, with all user actions explicitly consist in the creating or the retrieving of domain objects and/or invoking methods on those objects." – "The user interface shall be 100% automatically created from the definition of the domain objects."

Naked Objects: Overview Benefits: – faster development cycle – greater agility – more user-centric/empowered user interface – easier requirements analysis

Naked Objects: Basics Understand the principles of Naked Objects

Basics Naked Objects frameworks core concepts – Domain Objects • properties • collections • actions – Value types – Non-objects • Factories/Repositories • services • external/system services – ViewModels

Basics Domain objects – domain objects represent the persistent entities described within the system – these are your "plain old objects" (POJOs, POCOs, etc) – typically they intend to represent state plus behavior • state is expressed as properties • behavior is expressed as actions

Basics Properties – represents an element of state in a domain object – typically one of three types • value property (property of value type) • reference property (association to another domain object) • collection property (collection of properties) – properties can have some UI logic or behavior attached to them • control the order in which properties are displayed • trigger behavior when a property is changed • input validation

Basics Actions – actions are methods intended for user invocation – typically these are "just methods" that are discovered

Basics Value types – these are basically non-referenced objects – we care only for their value – they lack a standalone "identity" – embedded "in-place" for storage