Smalltalk design advice - how to implement generic bi-directional pointers?

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de itsme213
> Enviado el: Viernes, 21 de Diciembre de 2007 04:33
> Para: [hidden email]
> Asunto: [Seaside] Smalltalk design advice - how to implement
> genericbi-directional pointers?
>
> I don't think I have grasped the "Smalltalk Way" to deal with
> this and am looking for some design advice ...
>
> I often repeat this kind of code to maintain relations that I
> have implemented as bi-directional pointers (illustrative
> example only):
>
> Object subclass: #House
>    instanceVariableNames: 'rooms'
>
> House>>addRoom: aRoom
>     self basicAddRoom: aRoom
>     aRoom basicAddHouse: self
>
> House>>basicAddRoom: aRoom
>     rooms add: aRoom
>
> House>>removeRoom: aRoom
>     self basicRemoveRoom: aRoom
>     aRoom basicRemoveHouse: self
>
> House>>basicRemoveRoom: aRoom
>     rooms remove: aRoom
>
> Object subclass: #Room
>     instanceVariableNames: 'house'
>
> Room>>addHouse: aHouse
>     self basicAddHouse: aHouse
>
> Room>>basicAddHouse: aHouse
>     house notNil ifTrue: [house basicRemoveRoom: self]
>     house := aHouse
>
> etc.
>
> How can I make this relation-management code generic, so I
> can easily add it to any class with any named accessors, any
> number of times? I prefer to avoid DNU approaches if possible
> as this code will be called in several inner loops that need
> to run fairly tight. I thought traits might help but now
> don't think so.
>
> Thanks - Sophie
>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de itsme213
> Enviado el: Viernes, 21 de Diciembre de 2007 13:03
> Para: [hidden email]
> Asunto: [Seaside] Re: Smalltalk design advice - how
> toimplementgenericbi-directional pointers?
>
>
> "Sebastian Sastre" <[hidden email]> wrote in message
>
> > observe the world enough but I don't know of real rooms in wich you
> > can add real houses in them,
>
> OK, so if you change the #addHouse to #setHouse, or use other
> naming conventions for 1-N, 1-1, M-N relations etc ... how
> would you implement the recurrent code patterns?
>
> I appreciate the point about bi-directional pointers, but
> find them useful often enough that I would like to know how
> to solve the code duplication.
>
> Thanks - Sophie
>

> I don't think I have grasped the "Smalltalk Way" to deal with this and am
> looking for some design advice ...
>
> I often repeat this kind of code to maintain relations that I have
> implemented as bi-directional pointers (illustrative example only):
>
> Object subclass: #House
>    instanceVariableNames: 'rooms'
>
> House>>addRoom: aRoom
>     self basicAddRoom: aRoom
>     aRoom basicAddHouse: self
>
> House>>basicAddRoom: aRoom
>     rooms add: aRoom
>
> House>>removeRoom: aRoom
>     self basicRemoveRoom: aRoom
>     aRoom basicRemoveHouse: self
>
> House>>basicRemoveRoom: aRoom
>     rooms remove: aRoom
>
> Object subclass: #Room
>     instanceVariableNames: 'house'
>
> Room>>addHouse: aHouse
>     self basicAddHouse: aHouse
>
> Room>>basicAddHouse: aHouse
>     house notNil ifTrue: [house basicRemoveRoom: self]
>     house := aHouse
>
> etc.
>
> How can I make this relation-management code generic, so I can easily add it
> to any class with any named accessors, any number of times? I prefer to
> avoid DNU approaches if possible as this code will be called in several
> inner loops that need to run fairly tight. I thought traits might help but
> now don't think so.
>
> Thanks - Sophie
>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> However, a better solution, one that relies on real code and not dnu, is to
> stop thinking objects are relational tables and start thinking in objects.
> Rooms don't know what house they're in, tires don't know what car they're
> on, products don't know what basket they're in, line items don't know what
> order they belong to.  They don't need to, because if you have access to a
> room/tire/product/line item, it's because you already have the
> house/car/basket/order object.  The house/car/basket/order is the aggregate
> root, it's the meaningful object. It's composite parts are only interesting
> in relation to their parent and ideally only accessible through their
> parent.  
>
> Other objects should not reference the children of an aggregate, only the
> aggregate itself.  This being the case, they don't need to know how their
> parent is.  They're actually more composeable and better objects when they
> don't.  I should be able to remove a room/tire/product/line item from one
> house/car/basket/order object and put it into another house/car/basket/order
> object without any weird side effects like on of them pointing to the wrong
> parent.  
>
> Objects are not tables and bi-directional relationships, in general, are not
> desirable.

> Trying to find an OO model to represent this, I end up with three
> Classes that correspond to the three tables mentioned above ( maybe
> this is wrong already??). Each of the project/employee instances
> would hold a collection of association objects. Each association
> object would have instance vars to reference a project and an
> employee. But that way I would have bidirectional links on both sides
> of the association object...
> I could avoid the collections of associations in employee/project and
> create class-side methods in the association class instead answering
> collections of associations referencing a given employee (or
> project). But that seems even worse  to me - like simulating a
> database table.

> Users of my application would expect to be able to search for
> all the employees working on a given project and vice versa.
> Trying to find an OO model to represent this, I end up with
> three Classes that correspond to the three tables mentioned
> above ( maybe this is wrong already??).
> Each of the project/employee instances would hold a
> collection of association objects. Each association object
> would have instance vars to reference a project and an
> employee. But that way I would have bidirectional links on
> both sides of the association object...
> I could avoid the collections of associations in
> employee/project and create class-side methods in the
> association class instead answering collections of
> associations referencing a given employee (or project). But
> that seems even worse  to me - like simulating a database table.
>
> I would be very thankful if anybody could point me into a
> better direction, ( or recommend some books to read )
>
> Regards, Christoph
>
>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>> Let's say I have employees and projects where each employee
>> might work on many projects and each project has many
>> employees working on it. Now in a RDB I would have three
>> tables one for each projects/employees and a linking table
>> for the m:n relationship, possibly containing details of the
>> association.
>
> If you're trying to think in objects, the first thing you need to  
> stop doing
> is starting by thinking about how you'd do it in a relational  
> database.
> Relational database are meant to store data in such a manner that  
> it'll work
> for any model in any application, all data and no behavior.  That  
> isn't OO
> and that's not what you need to think about.
>
>> Users of my application would expect to be able to search for
>> all the employees working on a given project and vice versa.
>> Trying to find an OO model to represent this, I end up with
>> three Classes that correspond to the three tables mentioned
>> above ( maybe this is wrong already??).
>
> Why?  Seriously, you're still thinking relationally, you're talking  
> about
> nothing but data and searching.
>
>> I would be very thankful if anybody could point me into a
>> better direction, ( or recommend some books to read )
>>
>> Regards, Christoph
>
> First, stop thinking about the data, programs aren't about data,  
> they're
> about behavior.  You have to ask yourself what is this program  
> going to do,
> what is its purpose, what does it accomplish for the user.  Is the  
> program
> about projects, or users, and which one is it going to be centered  
> around?
> What objects are you going to need most?  Modeling a program is  
> about making
> choices, picking a direction, and going for it.  Trying to keep
> bidirectional links everywhere is just a way to avoid making a  
> decision.  An
> object model isn't a relational schema, it's not supposed to be  
> agnostic,
> it's supposed to be opinionated.
>
> Trying to make a model that works for all cases (relational db's)  
> just leads
> to a model that doesn't work well for any case.  Pick your most  
> important
> use cases and make the model work well for them, and make sure to  
> let the
> programs actual behavior dictate which solution is best.  Don't sit  
> down and
> design your object model like a relational schema where you name  
> all the
> attributes and try and normalize the data, rather, use CRC cards  
> and figure
> out how your objects collaborate, behaviorally.  Don't bother  
> listing the
> attributes, that doesn't matter, you can figure that out at  
> implementation
> time.
>
> If you think hard enough, and find that your app really is just  
> data with
> little if any behavior, then you really just stop thinking about  
> trying to
> make a *good object model* and just dump the data to the screen in the
> easiest manner possible, be it sql queries or an active record, it  
> won't
> really matter.  Object models are best suited for behaviorally complex
> applications.
>
> Ramon Leon
> http://onsmalltalk.com
>

> Let's talk again about the "Car" and "Tire" objects. I agree
> with Ramon that generally a Car needs to know about the Tire
> objects but the inverse is not important. A Tire can be
> placed on a different car and it shouldn't care. But what
> about a luxury car? Is that any different? Could be. The Tire
> might want to tell the car when its air pressure is low. For
> this it seems plausible that the tire might want to know that
> it is attached to the Car, that way it can send a message to
> the Car when it's time to replenish the air. You could still
> argue that the Car could "ping" the Tire every five minutes
> to find out the air pressure, or perhaps once each time you
> turn on the ignition, so it all depends.

> Ramon mentioned "Class Responsibility Collaborator" models,
> or just "CRC cards" for short. That terminology is new to me
> and the idea is pretty cool. For the uninitiated, here's a few links:
>
> Bitmap scans of the actual handwritten CRC cards used in the
> creation of "HotDraw":
> ===============
> http://c2.com/doc/crc/draw.html
>
> Review of "Ecode", a CRC card design tool for Squeak:
> ===============
> http://coweb.cc.gatech.edu/cs2340/3372

>> Ramon mentioned "Class Responsibility Collaborator" models,
>> or just "CRC cards" for short. That terminology is new to me
>> and the idea is pretty cool. For the uninitiated, here's a few links:
>>
>> Bitmap scans of the actual handwritten CRC cards used in the
>> creation of "HotDraw":
>> ===============
>> http://c2.com/doc/crc/draw.html
>>
>> Review of "Ecode", a CRC card design tool for Squeak:
>> ===============
>> http://coweb.cc.gatech.edu/cs2340/3372
>
> This is one of the best techniques I've ever picked up from anyone,  
> and it's
> no accident those HotDraw CRC cards are scanned from hand written  
> cards.
> Ward Cunningham does the things he does for very good reasons.  
> Don't use
> software to do CRC design sessions, it defeats the purpose and  
> utility of
> the technique.  3x5 index cards are one of the best thinking tools  
> ever
> invented, they let you design and simulate the execution of an  
> object model
> in minutes and being able to quickly write, pick up, move around,  
> role play,
> and discard the objects is vital to the usefulness of the technique.
>
> Programs and white boards aren't nearly as useful as a handful of  
> index
> cards.  A little play time spent simulating several variations of  
> your model
> (cards are easy to throw away) will really solidify your ideas,  
> finding the
> good ones, and working through and tossing out the bad ones very  
> cheaply,
> before you've invested yourself in code.  Code is much harder to  
> throw away,
> you're more emotionally invested in it (which is why you don't use  
> software
> for CRC).
>
>> Let's talk again about the "Car" and "Tire" objects. I agree
>> with Ramon that generally a Car needs to know about the Tire
>> objects but the inverse is not important. A Tire can be
>> placed on a different car and it shouldn't care. But what
>> about a luxury car? Is that any different? Could be. The Tire
>> might want to tell the car when its air pressure is low. For
>
> Nope, the tire should simply announce its air pressure and make no
> assumptions about who's listening.  It's more composable that way.  
> I might
> have the tire rigged up to a crazy 3 wheeled trike that doesn't  
> care about
> air pressure, and just because the tire can give air pressure readings
> doesn't mean it should only work on cars it was made for.
>
>> Ramon, maybe you can clarify. You mentioned your Tsunami
>> framework but in the same breadth alluded that we shouldn't
>> use it? Or I misunderstand. In what situations *should* we
>> use Tsunami or is it that you once felt it was necessary but
>> later learned it isn't? In the Tsunami framework it mentions
>> inspiration from the book "Streamlined Object Modeling" which
>> has examples for both Java and Squeak. Would you say this is
>> an excellent book for us new guys to read?
>
> It is an excellent book, one of my favorites.  It goes into great  
> detail
> about exactly how to maintain relationships and model rules in  
> business
> objects using a minimal set of patterns they found all rules could be
> reduced to.  Every example in the book is done in both Java and  
> Squeak,
> which ends up being quite an advertisement for Squeak when you see  
> just how
> terse it is compared to Java doing the same thing.
>
> Initially I was so enamored by the book that I adopted the patterns  
> and went
> overboard, using the patterns even when they weren't necessary  
> because I
> wanted consistency.  Here's an example, say I have a Person class,  
> I'd do
> the #name accessor like so...
>
> name
>     ^name
>
> name: aName
>     self testName: aName.
>     set doSetName: aName.
>
> testName: aName
>     "throw exceptions for business rule violations"
>
> doSetName: aName
>     name := aName
>
> This would give me an #x, #doSetX:, #testX: pattern of methods,  
> each with a
> particular purpose, the primary get/set accessors for normal use,  
> internally
> delegating to #textX: and #doSetX: which separate the testing and  
> setting so
> subclasses can easily override and extend them to add new rules and
> behavior, or for allowing the running or bypassing of the rules when
> necessary.  I really liked how they'd thought everything out, the  
> rigor of
> their model and detailed explanations of every technique.
>
> I extended the Squeak IDE with my own create accessors routines that
> generated all this boilerplate every time I added accessors.  What  
> I learned
> very quickly afterwards was all this stubbed out code, this  
> scaffolding for
> rules and subclass hooks, more often than not, went unused.  As my  
> models
> changed and I needed to refactor, I also realized the maintenance  
> burden all
> this extra code created for me, it made things hard to change and  
> hard to
> find.  I'd have 10 test methods but only two or three with actual  
> rules in
> them, the rest just empty stubs waiting to be used.
>
> I grew tired of this, figured there had to be a better way, needed  
> to rid
> myself of the boilerplate code, and the need to maintain it.  
> That's when I
> build Tsunami, I reified those relationships and patterns as  
> runtime objects
> and hacked doesNotUnderstand to deal with all this, I'd only add testX
> methods I needed and they'd be picked up automatically, I'd get
> bi-directional references maintained automatically, I'd get  
> collections
> encapsulated automatically via #addX #testAddX: #doAddX: #removeX
> #testRemoveX: #doRemoveX:, and for a time, I was happy with it.
>
> Later, after working with them for a while, I started to realize that
> working with purely runtime generated constructs was a royal pain  
> in the ass
> (a lot of Ruby folk are find this out as well), debugging was more
> difficult, stepping through the code was more difficult, nice  
> things like
> symbol completion and lookup to navigate the code didn't work so well,
> because I'd gone to far, eliminated all the code including instance
> variables and accessors in favor of runtime meta level constructs.  It
> actually is possible to be too dynamic and too abstract.
>
> I have a strong tendency to get sucked into solving the general  
> case that
> often distracts me from what I'm actually trying to accomplish (often
> because I think it's more fun).  I'm learning to resist this urge,  
> I've
> learned to appreciate simplicity and direct solutions much more.  I  
> still
> use many of the patterns I picked up from streamlined object  
> modeling, but
> only when I actually need them.  I use real instance variables and  
> simple
> ordinary accessors (tools work much better now), and I never stub  
> things out
> ahead of time anymore.  I only write code that's actually needed,  
> when I
> actually need it.  Stubbing boilerplate stuff out for the future is  
> a big
> waste of time and gives you so much velocity in one direction that  
> it makes
> change harder.  Change should be easy, so write as little code as  
> necessary
> to achieve a desired behavior and no more.
>
> I used to assume bi-directional references, now I consider them an  
> exception
> to the rule, something to avoided if at all possible.  Direct  
> references
> flow down from parent to child, but events bubble up from child to  
> parent.
> That's how I see things these days anyway, who knows what I'll  
> think next
> year.
>
> Ramon Leon
> http://onsmalltalk.com
>
>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Imagine "name" was bound up to a text field on an HTML web
> form. Let's say that the testing code required the first
>
> snip...
>
> I would offer a slight variation. I would write your snippet like so:
>
> snip...
>
> The idea here is that "name" will always get set, regardless
> of what is typed, but it might not be saved to your
> persistence layer (object database - Magma, or relational
> database - GLORP). When you type in "rosenzweig" and hit
> "submit", one of the following could occur:
>
> -- Aaron