Designing and Programming with Personalities Luis Blando lblandogte

Outline n n n Modeling behavior Personalities Dynamic Personalities Synergy with Frameworks Personalities/J language Q&A 2

Modeling Behavior - Outline n n n The functional nature of software systems Functional decomposition and Structured Programming Data Decomposition and Object Oriented Programming Finding objects and behavior When behavior misbehaves Popular functions and their mapping 3

The functional nature of software systems “a well-organized software system may be viewed as an operational model of some aspect of the world. Operational because it is used to generate practical results and sometimes to feed these results back into the world; model because any useful system must be based on a certain interpretation of some world phenomenon. ” Bertrand Meyer, Object Oriented Software Construction, 1988 4

Functional Decomposition and Smaller scope Structured Programming Bigger scope rtt_init() rtt_newpack() it! r? a W alle c rtt_start() h c ? i n h e h W rtt_stop() w d n A rtt_timeout() /* can be set nonzero by caller */ int rtt_d_flag = 0; . . . rtt_init(rtt_struct *ptr) {. . . } rtt_newpack(rtt_struct *ptr) {. . . } rtt_start(rtt_struct *ptr) {. . . } rtt_stop(rtt_struct *ptr) {. . . } rtt_timeout(rtt_struct *ptr) {. . . }. . . What if in here I mess with rtt_info? dgsendrecv(…) struct rtt_info; . . . dgsendrecv(. . . ) {. . . rtt_init( &rtt_info ); rtt_newpack( &rtt_info ); . . . }. . . Excerpts extracted from: UNIX Network Programming, Richard Stevens, 1990, pp. 406 -414 5

Data Decomposition and Object Oriented Programming This used to be rtt_struct These are the accessors to regulate object state changes ! RTT float rtt_rtt; float rtt_srtt; float rtt_rttdev; short rtt_nrexmt; short rtt_currto; short rtt_nxtrto; int rtt_d_flag; + + + + rtt_init() rtt_newpack() rtt_start() rtt_stop() rtt_timeout() set. X() get. X() Reliable. DGRAM int rttfirst; int tout_flag; RTT myrtt; + sendrecv(){ myrtt. set. X(); myrtt. init(); . . . } We’ve encapsulated data and functions together. The users keep an instance of “both” 6

Finding Objects and Behavior - 1 “This is why object-oriented designers usually do not spend their time in academic discussions of methods to find the objects: in the physical or abstract reality being modeled, the objects are just there for the picking”. Bertrand Meyer, Object-Oriented Software Construction, 1988. “The object’s operations come naturally when we consider and object’s interface. The operations can also be identified directly from the application, when we consider what can be done with the items we model”. Ivar Jacobson et. al. , Object. Oriented Software Engineering, 1992. “What actions must get accomplished, and which object will accomplish them, are questions that we must answer right at the start”. Rebecca Wirfs-Brock et. al. , Designing Object-Oriented Software, 1990. 7

Finding Objects and Behavior - 2 “normal” behavior (one-domain, accessors) When in doubt… Follow the data! (anonymous : ) CRC, use-cases The 3 amigos “intrinsic” behavior. Harrison & Ossher, Subject. Oriented Programming, 1993 Wait a minute! I know, let’s just What’s “normal” for me concentrate on the basic might not be so behavior only for now. . . for Grady or James! 8

? When Behavior Misbehaves - 1 Mammal Lion Animal Oviparous Use their reproductive What about using really behavior, of. Nonsense! course! What’stheir eating habits? important is their intelligence! Zoo. Sys “The name of a class should reflect its intrinsic nature and not a role that it plays in an association”. James Rumbaugh Veterinary Trainer Feeder et. al. Object-Oriented Modeling and 9 Design, 1991.

When Behavior Misbehaves - 2 The intrinsic stuff is easy to do! : -) The vets got their way But what about the trainers and the feeders ? ? ? 10

When Behavior Misbehaves - 3 A possible Trainer requirement Hey! I’m sure I can find some “The show shall start with the pink pelicans and the African geese commonality in all these functions! flying across the stage. They are to land at one end of the arena an After all, how many ways can you then walk towards a small door on the side. At the same time, a actually “walk”! killer whale should swim in circles and jump just as the pelicans fly by. After the jump, the sea lion should swim past the whale, jump out of the pool, and walk towards the center stage where the announcer is waiting for him. ” 11

Popular Functions The popular functions in Zoo. Sys Fly() popular function Encapsulate this sequence. Always the same for any class. . . …and their sub-functions 12

Mapping Popular Functions Swim() Fly() Walk() 13

Alternatives for Mapping n Pushing functions up the hierarchy – Design errors n Duplicate function implementation – Maintenance nightmare n Multiple inheritance – Ambiguous/not understood – Not supported by some languages – “Roles” are unconstrained (I. e. are fullfledged classes) 14

Personalities - Outline n n Designing with roles Personalities – Concept, Architecture, Components, Syntax, Usage n The law of personalities 15

“The show shall start with the pink pelicans and the African geese flying across the stage. They are to land at one end of the arena and then walk towards a small door on the side. At the same time, a killer whale should swim in circles and jump just as the pelicans fly by. After the jump, the sea lion should swim past the whale, jump Eureka! Remember requirements statement? out of pool, and walk this towards the center stage where n the Some OOA/D methodologies are the Maybe “Flier” is announcer is waiting for conducive tohim. ” the discovery ofofroles a role of a lot – Wirfs-Brock et. al. animals here? Designing with Roles – Andersen et. al. “The show shall start with every flying animal in our zoo flying across the stage. are Theynevertheless are to land at one end of the by arena and then n Roles found walk towards a small door the side. Atviews the sameof time, inspecting theondynamic a a killer whale should swimsomething in circles and jump just as the birds fly by. It could’ve been like this. . . sufficiently system. After the jump, the sea complex lion should swim past the whale, jump out of the pool, and walk towards the center stage where the announcer is waiting for him. ” 16

Personality - Concept n n Encapsulate popular functions independent of any specific class hierarchy Template Method Pattern++ – “micro-framework” n Not abstract classes – Embody one, and only one role n Not interfaces (a-la Java) – More constrained – Contain behavior implementation 17

Personality - Architecture Users of the object only deal with the Personality’s “Upstream Interface” The role behavior is encapsulated here. . . …and defined in terms of the “Downstream Interface”, which classes in the hierarchy must implement. ) ” r e n i “Tra ( ) r” (“Flie ) n” a c i l e (“P 18

Personality - Components n Upstream interface – popular functions go here n Downstream interface – functions to be implemented by personifying class n Private functions – no visibility either upstream or downstream n Role-specific attributes – to keep the role’s state n Constructor – to initialize the role-specific attributes 19

Personality - Definition Syntax c ti c a t Syn r a g u S Each method in the UI is declared and defined. Each method in the DI is declared but not defined. Constructor Private aux. functions and attributes. 20

Personality - Usage Syntax Declare intent. . . Implementation of the Bat class. Nothing to do with the Flier personality here. . . The Bat class implements the DI of the Flier personality 21

Law of Personalities Hooray! (Lo. P) - 1 n No default implementation – only abstract functions in DI n Karl Basic types d , e t a b ” to e n d o i e t a m nd so e r m e n Behavioral buffer t m f o A ut b rec ( “ d o e t t e s. UI gra e i e t is onof the object t i –th users communicate only through l n i a n e or rso m e p r ) o f e l ab y llow o a l p e yd n Fixed popular behavior l i s a e s s le te in method signatures o m – only language-defined types allowed e d we – implementation of popular functions is final n Implementation separation – popular functions’ implementation can only use DI to talk to the personifying class 22 Luis

Lo. P - No default implementation n Default implementation does not make // compute and return today’s date sense Easy to check s e k a m automatically ent m – since we can use personality in many m o c he t l l a n i m his s ifference different domains! T VS. d e h t all ! must be clear n Expected semanticsorof DI d l w // compute and return today’s date – so the behavior of the Can’t personality’s check // that in the format “YYYYMMDD” popular guaranteed automatically! String functions Today(); is somewhat String Today(); 23

Lo. P - Basic Types (recommendation) ys a w l a personality Foo { o t o o ith s F w e c d r e o y n No user-defined the losignatures p. . . his f in e Ttypes d be o t ve ! a of either DI or UI methods h // return today ate. Class y. D M – using only language-defined types My. Date. Class Today(); to check automatically. guarantees. Easy deployability everywhere However, since it’s a recommendation, Personalities/J VS. n However, it’s too constraining a switch for “strong syntax” – too many has translations to/from basic types (a-la ANSI C) : -) // return today when deploying a “component” java. util. Date Today(); . . . recommended everywhere, required – thus, } only at the “deployment boundaries” 24

Lo. P - Behavioral Buffer // Sea. World. Show() is a client n n Clients call UI methods // ofonly Swimmer personality Design at the personality void reuse Sea. World. Show(Swimmer s) level { – the popular functions are totally s. Swim(10, 10); ok, UI defined used Easy// to check n automatically. s. Submerge(); // error, Semantic guarantees (sort of) DI used } popular functions are final, (though – the based on the DI implementations) 25

Lo. P - Fixed Popular Behavior n Popular functions’ implementations are final – help provide some kind of semantic Easy to check guarantee to users of the personality automatically. – it keeps the personality “narrow” n oing Subfunctions are easier to implement g s i an o t lic s e n P e y p z ap smaller h – since their. Tscope hopefully t his La is a er i h l F W ! e th ash f r o c s o t nt e i l c e all th lity now? na o s r e p 26

Lo. P - Implementation Separation n Popular functions’ implementation can only use DI methods to access the personifying class – helps make sure that the DI is complete for the intended semantics of the personality – keeps the personality encapsulated n However, requiring “behavior impedance” is too constraining – that is, pass-through UI methods are sometimes needed (and healthy) 27

I can talk to the animals as Mammal and Oviparous. Keeping everybody happy Vets And to me they are just Fliers, Swimmers, Walkers, and Jumpers! (“personifies” relationship) Trainers 28

Dynamic Personalities n Why bother? – Workarounds for object migration n n Shortcomings of “static” personalities What we’d like Partially-dynamic personalities (a. k. a. “indecisive personalities”) Fully-dynamic personalities 29

But wait! What’s wrong here? ? ? Med. Sys { add. Patient(Person p) {…} do. Something() { if (p. age() > 80) … } } Why Bother with Dyn. Pers? n n Roles are very much “dynamic” Object migration problem Person john = new Person(); Medsys. add. Patient(john); // john joins a company. Need // to use the “Employee” // interface, but: john. yell. To. Boss(); // => undef! // so we need to do: Employee tmp = new Employee(); // copy all the state from john to tmp // and get rid of john delete john; tmp. yell. To. Boss(); // now it works 30

Workarounds for the Object Migration problem Using personalities (even the “static” version) n Reclassification helps, since: – need to update every single client that is using the “old” instance // Person will (someday) be Employee and, // with any luck, also a Manager n Delegation class Person personifies Employee, Manager …. . . – counterintuitive since “john” is one entity Person john = state new when Person(); – duplicated overlapping semantics – not the same object instance for all clients (typing) Whoever has the “john” instance, – problem of triggering state changes “up” can still use methods from Manager and/or Employee’s upstream interface without any reclassification! 31

Shortcomings of “static” class Person personifies Employee, Manager … Personalities n However, you need to know at class. If you forget something here, you’ll have to time, recompile yourpersonalities class creation all the you and refresh the instances later! might need in the future – tough to do But wait! John // personality code is still not even an n And, there’s no way for controlling class Person Employee, much personifies Employee, Manager … “access” to the personalities a class less afor Manager! clienttocode –//similar always instantiating a Manager Person john = new Person(); object if using inheritance ((Manager)john). yell. To. Boss(); n No common protocol among personalities 32

What We Would Like n n n Runtime personality attachment and detachment Preservation of object identity Preservation of typing properties Common interface for all personalities Ubiquitous personification Reasonable performance 33

Indecisive Personalities - 1 n n “personifies” semantics change to mean “can” instead of “does” Third-party instructs the class to activate and deactivate the personality – security concerns are ignored n n Still need to declare all potential personalities at class-creation time Very fast implementation 34