the multiplicity of the contributor/libraryitem relationship is many-to-manyas indicated by the character at both ends of one relationship any one library item might have more than one contributor (for exampleseveral actors and director on dvdand many authors write many booksso they would be attached to multiple library items this little changewhile it looks bit cleaner and simplerhas lost some vital information we can still tell who contributed to specific library itembut we don' know how they contributed were they the director or an actordid they write the audio bookor were they the voice that narrated the bookit would be nice if we could just add contributor_type attribute on the contributor classbut this will fall apart when dealing with multitalented people who have both authored books and directed movies one option is to add attributes to each of our libraryitem subclasses that hold the information we needsuch as author on bookor artist on cdand then make the relationship to those properties all point to the contributor class the problem with this is that we lose lot of polymorphic elegance if we want to list the contributors to an itemwe have to look for specific attributes on that itemsuch as authors or actors we can alleviate this by adding getcontributors method on the libraryitem class that subclasses can override then the catalog never has to know what attributes the objects are queryingwe've abstracted the public interfacelibraryitem catalog +search( +title +upc +subject +contributors +locate(+getcontributors(book +isbn +title +subject +dds number +authors cd magazine dvd +genre +actors +directors +volume +issue +editors contributor +name +artists