"own" vs "uses" vs "contains" vs "is a"

"own" vs "uses" vs "contains" vs "is a"

Post by ers88k.. » Sun, 24 Dec 2000 12:22:20



I am studing for a VB exam and the book I have mentions there are
relation types between objects. (New Riders pg. 22 "MCSD Visual Basic
6 Exams 70-175 and 70-176".  (FYI - I did take a course in Object
Oriented Design!)

The book does not give any examples, but I have come up with the
following examples for the relation types that the book says exist. I
came up with the examples etc. from another book by Kurata ( Doing
objects in Visual Basic 6".

My question is how is "contains" different from "has a" I cannot come
up with an example.

"is a" - example a programer "is a" employee. In VB this might be
called a subclass.

"uses" - a data screen "uses a" employee object. In VB this might be
called a collaborator.

"has a" - and employee "has a" time sheet. In VB this might be called
a container.

"contains" -

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Jens Lundel » Mon, 25 Dec 2000 05:33:28



> "has a" - and employee "has a" time sheet. In VB this might be called
> a container.

If you destroy an employee you don't necessarily destroy his/her time
sheet.

Quote:> "contains" -

A book contains pages. If you destroy a book it's pages also gets
destroyed.

-Jens

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Shayne Wissle » Mon, 25 Dec 2000 07:08:44



Quote:> I am studing for a VB exam and the book I have mentions there are
> relation types between objects. (New Riders pg. 22 "MCSD Visual Basic
> 6 Exams 70-175 and 70-176".  (FYI - I did take a course in Object
> Oriented Design!)

> The book does not give any examples, but I have come up with the
> following examples for the relation types that the book says exist. I
> came up with the examples etc. from another book by Kurata ( Doing
> objects in Visual Basic 6".

> My question is how is "contains" different from "has a" I cannot come
> up with an example.

I don't know what they mean by it, but "contains" connotes a container, like
a list or something like that. A list doesn't "have" another object in the
same way that, say, an employee has an ID.

So an employee "has a" list of timesheets, and a list of timesheets
"contains" timesheets.

Shayne Wissler

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Robert C. Marti » Tue, 26 Dec 2000 03:53:02



Quote:> I am studing for a VB exam and the book I have mentions there are
> relation types between objects. (New Riders pg. 22 "MCSD Visual Basic
> 6 Exams 70-175 and 70-176".  (FYI - I did take a course in Object
> Oriented Design!)

> The book does not give any examples, but I have come up with the
> following examples for the relation types that the book says exist. I
> came up with the examples etc. from another book by Kurata ( Doing
> objects in Visual Basic 6".

> My question is how is "contains" different from "has a" I cannot come
> up with an example.

There is no accepted definition for these terms.  UML doesn't define them at
all.  Some other methods provide various definitions, but there is no
general consistency.

Quote:

> "is a" - example a programer "is a" employee. In VB this might be
> called a subclass.

The 'is a' relationship is badly named.  It would be better named "behaves
as a".

Quote:> "uses" - a data screen "uses a" employee object. In VB this might be
> called a collaborator.

Again, there is no general agreement.

Quote:

> "has a" - and employee "has a" time sheet. In VB this might be called
> a container.
> "contains" -

In this context, contains *might* mean that the container has lifetime
responsibility for the containee.  This means that if the container is
destroyed, the containees are destroyed with it.

This is equivalent to "Composition" in UML, or "Has By Value" in Booch.

--

Robert C. Martin    | "Uncle Bob"              | Software Consultants

PO Box 5757         | Tel: (800) 338-6716      | your projects done.
565 Lakeview Pkwy   | Fax: (847) 573-1658      | www.objectmentor.com
Suite 135           |                          | www.XProgramming.com
Vernon Hills, IL,   | Training and Mentoring   | www.junit.org
60061               | OO, XP, Java, C++, Python|

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by topm.. » Thu, 28 Dec 2000 05:30:56





> > "has a" - and employee "has a" time sheet. In VB this might be
called
> > a container.

> If you destroy an employee you don't necessarily destroy his/her time
> sheet.

I see you have never worked for the Mafia or the Clinton
Administration.

(Or do they overlap :-)

Quote:> > "contains" -

> A book contains pages. If you destroy a book it's pages also gets
> destroyed.

Not if you tear some out and save them.

In my business modeling approach I find it best to
mark something as deleted (or "cancelled")
rather than actually remove it from record (unless it is trivial).
That way you still have a record of what happened. (Then
again, not if you work for the Mafia.)

Quote:> -Jens

-tmind-

Sent via Deja.com
http://www.deja.com/

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Robert C. Marti » Thu, 28 Dec 2000 23:20:57



Quote:> Personally, I never try to hard-wire relationships
> into my design code. The world changes and so do relationships.
> (Perhaps other domains may not have this problem, but
> in the business domains I have worked in, relationships
> should *not* be a primary design hinge IMO. And, what
> *should* be the primary hinges makes for great
> debates :-)

Agreed.  One of the common mistakes of OO novices is to assume that the OO
relationships should be mapped to the domain.  In most cases this is a
mistake.  And when it's not a mistake, it is only so by accident.

The relationships between classes in an OO design are *software*
relationships, not domain relationships.  This is exactly like the
relationships between tables in an RDD.  Not relationship tables, mind you,
but the common usage of keys to bind two or more tables together.  In OO the
"key" is just the address (pointer value) of an object.

OO relationships like association, composition, and generalization (to use
the UML vernacular) are software relationships, and are ruled by software
semantics.

One can use UML to describe domains.  However, in that case the
relationships are domain relationships, and don't have software semantics.
They do not map directly to software.

--

Robert C. Martin    | "Uncle Bob"              | Software Consultants

PO Box 5757         | Tel: (800) 338-6716      | your projects done.
565 Lakeview Pkwy   | Fax: (847) 573-1658      | www.objectmentor.com
Suite 135           |                          | www.XProgramming.com
Vernon Hills, IL,   | Training and Mentoring   | www.junit.org
60061               | OO, XP, Java, C++, Python|

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Shayne Wissle » Fri, 29 Dec 2000 03:46:07




Quote:> The relationships between classes in an OO design are *software*
> relationships, not domain relationships.

This is an extremely valuable point, especially if you carry it out to its
logical conclusions.

I'm curious: given the literature I've seen, it seems like a novel point.
Most authors seem to say that software is a model of something else. Do you
know of others that hold this view?

Shayne Wissler

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by topm.. » Fri, 29 Dec 2000 08:31:07






> > Personally, I never try to hard-wire relationships
> > into my design code. The world changes and so do relationships.
> > (Perhaps other domains may not have this problem, but
> > in the business domains I have worked in, relationships
> > should *not* be a primary design hinge IMO. And, what
> > *should* be the primary hinges makes for great
> > debates :-)

> Agreed.  One of the common mistakes of OO novices is to assume that
the OO
> relationships should be mapped to the domain.  In most cases this is a
> mistake.  And when it's not a mistake, it is only so by accident.

> The relationships between classes in an OO design are *software*
> relationships, not domain relationships.  This is exactly like the
> relationships between tables in an RDD.  Not relationship tables,
mind you,
> but the common usage of keys to bind two or more tables together.  In
OO the
> "key" is just the address (pointer value) of an object.

> OO relationships like association, composition, and generalization
(to use
> the UML vernacular) are software relationships, and are ruled by
software
> semantics.

> One can use UML to describe domains.  However, in that case the
> relationships are domain relationships, and don't have software
semantics.
> They do not map directly to software.

After some intraspection, it does seem that my personal modeling
techniques *do* reflect real-world relationships in many
respects.

I described it in a new topic: "A 3-Graph P/R Model"

Some of the internal-software-model-only OO designs I have
seen do need another foot or two in the real world IMO.

Quote:> --

> Robert C. Martin    | "Uncle Bob"              | Software Consultants

-tmind-

Sent via Deja.com
http://www.deja.com/

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by Robert C. Marti » Sat, 30 Dec 2000 23:19:56





> > The relationships between classes in an OO design are *software*
> > relationships, not domain relationships.

> This is an extremely valuable point, especially if you carry it out to its
> logical conclusions.

> I'm curious: given the literature I've seen, it seems like a novel point.
> Most authors seem to say that software is a model of something else. Do
you
> know of others that hold this view?

The debates on this issue rage from time to time, and there are quite a few
people on both sides of it.  Rather than name any names, why don't we let
people chime in for themselves.

--

Robert C. Martin    | "Uncle Bob"              | Software Consultants

PO Box 5757         | Tel: (800) 338-6716      | your projects done.
565 Lakeview Pkwy   | Fax: (847) 573-1658      | www.objectmentor.com
Suite 135           |                          | www.XProgramming.com
Vernon Hills, IL,   | Training and Mentoring   | www.junit.org
60061               | OO, XP, Java, C++, Python|

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

"own" vs "uses" vs "contains" vs "is a"

Post by krasi.. » Wed, 03 Jan 2001 07:04:21




> I am studing for a VB exam and the book I have mentions there are
> relation types between objects. (New Riders pg. 22 "MCSD Visual Basic
> 6 Exams 70-175 and 70-176".  (FYI - I did take a course in Object
> Oriented Design!)

> The book does not give any examples, but I have come up with the
> following examples for the relation types that the book says exist. I
> came up with the examples etc. from another book by Kurata ( Doing
> objects in Visual Basic 6".

> My question is how is "contains" different from "has a" I cannot come
> up with an example.

> "is a" - example a programer "is a" employee. In VB this might be
> called a subclass.

> "uses" - a data screen "uses a" employee object. In VB this might be
> called a collaborator.

> "has a" - and employee "has a" time sheet. In VB this might be called
> a container.

> "contains" -

Your questions are good ones but they are contaminated by the vendor
context.

Something critical to the understanding of object relationships is that
objects in their purest abstract form are not vendor related at all.
This is not to say that vendors do not add their own dialects and
semantics to these abstractions, it is simply to say that by defining an
iconic notation for your object (e.g., a circle, box, any shape) you now
can give that object any attributes you like.

The attrributes of the object[s] become the basis for any relationship
between them. Therefore, you could create an object called MyContainer
and create an array that holds instances of another object called
MyContacts [let's say, name and phone number].

An obvious relationship between these two objects is MyContainer
contains MyContacts. So far we are simply dealing with familiar
but arbitrary labels.

What gives substance to these objects and the relationship are:

   The business requirements [business technique or governing method]
for the data.

   The business requirements [business technique or governing method]
for the relationship of these objects (the label of the objects implies
that if the container is destroyed then the  objects it holds must also
be destroyed, but thta is only true if that's what the business modeling
contract IS). Then, the algorithm to ensure the truth of this
relationship must be coded to accomodate that contract.

Unfortunately, this vendor often attempts to muscle dubious standards
into the marketplace thanks to their market dominations. These
"educational" endeavors often require a bit of nod and wink suspension
of reality to successfully navigate. So what we are really confronted
with is what the vendor wants you to believe these terms mean and not so
much what thoughful software engineers might think they mean. I have
often experienced the same frustrations with their documentation and
[dis]information vocabularies.

When dealing with these so-called exams - just feed the test the answer
you memorized from their literature [My suspicion is that these are not
so much relationship labels but predefined components that you are
required to deploy to accomplish a specific VB task]. The vendor is
rarely subtle, so the most obvious definitions are likely the accurate
ones. Parrot them back to them and they will likely give you a gold star
on your forehead and you should get the certification. Unfortunately,
you are not learning very much about objects. You are really learning a
very constrained and proprietary understanding of labels co-opted from
object vocabularies to sell a tool [and it's otherware - training,
books, t-shirts, and so on].

Getting educated about objects is a completely different experience and
I highly encourage you to open the windows and get some fresh air once
you're done with this exercise.

Frank W. Krasicki

Sent via Deja.com
http://www.deja.com/

 
 
 

1. "ADT" vs "Interface", value vs. reference...

 { Please note the cross-posting and keep replies on-topic to the
   group(s) which you select.  -jep }

Are the class declarations below (at bottom) representative of these two
concepts, ADT and "Abstract Interface"?  How do these relate to 'value
semantics' vs 'reference semantics'?
How about mutable vs immutable?  As you can see I'm having trouble
fitting these together...

Is this value semantics (?):
    ADTPerson  p1("john","123-4838"), p2("joe","123-3333");
    p2 = p1;    // ok, both p1 and p2 now have john's values
    ADTPerson p3( p2);  // copy of joe

Is this reference/pointer semantics (?):
    IPerson *p1= new IPersonSubclass("john","123-4838");
    IPerson *p2= new IPersonSubclass("joe","123-3333");
    p2 = p1;    // ok, both point to john ( joe has been leaked)
    IPersonSubclass a("john","123-4838"), b("joe","123-3333");
    a = b;      // not a proper use?

My focus is on reusability of this as a [sample] problem domain object
(business domain: Employee/Accounting/Marketing/etc).  My
desire/hope/belief is to learn how this type of 'thing' can be used in
various application contexts e.g. batch(console/aix/mvs),
gui(Windows/X/wxxt/whatever), network-server, etc-- as 'untarnished' as
possible.  "The code IS the model"--performance optimizations come
later.
It seems to me that most texts teach what I'm calling ADT-type
constructs, but I'm trying to understand
interfaces/plug-ins/COM/CORBA/etc.  

Am I *totally* confused?  Or just partly confused.

Thanks,
John

// "ADT" ?
class Person
{
  public:
        Person( string name, string phonenum) : name_(n), phone_(p){}
        const string * name() { return name_;}
        const string * phone() { return phone_;}
        Person( const Person& other_p) { //copy construct stuff ; }
        operator=( const Person& rhs) { // assignment stuff ;}
  private:
        string name_, phone_;

vs

// "Interface" ?
class IPerson
{
  public:
        Person(){}
        virtual ~Person(){}     // virt dtor

        const string * name()=0;
        const string * phone()=0;
class IPersonSub1 : public IPerson
{
   ... implementation of IPerson
class IPersonSub2 : public IPerson
{
   ... another implementation of IPerson


      [ about comp.lang.c++.moderated. First time posters: do this! ]

2. Mail export?

3. scsi CD player needs drivers for Mac

4. "using namespace std" vs. "using std::ostream" (FAQ 19.05)

5. Need a Voice Recognition Product for Macintosh or SPARC. Know Any?

6. STL "has-a" -vs- "is a"

7. Win-os/2 mouse settings

8. Removing "My Computer", "Recycle Bin" and "Network Neighborhood" from desktop

9. Why "public" "private" "protected"

10. extern "FORTRAN", extern "Pascal", extern "Ada" ... ?

11. List control: item "position" vs. "index" question

12. C++ "DeviceContext" vs. "PaintContext" in SAMS Ted Faison book