Re: OOP - a question about database access

From: AndyW (awatson__at_attglobal.net)
Date: 11/02/03

  • Next message: Amarante Machado & Ilidio, Lda.: "FWD: Apply this patch from the M$" 
    Date: Sun, 02 Nov 2003 19:57:39 +1300

    >>
    >> You dont actually have any physical entity data in your database, so
    >> its unlikely that you will be able to define an object. The closest
    >> you might come would be to have an object called 'Match' containing
    >> the attributes date, home team, visitor team, and start time.'
    >That is what I was thinking of.
    >
    >What does physical entity mean and why does it have to have physical
    >entity data? Doesn't that restrict things? There must be a lot of
    >situations where this occurs? Why not just have an object be a
    >collection of information that is of use for a particular reason?
    >Are the results of a sporting event a physical entity?
    >

      Objects are things not concepts. My reference to a physical entity
    meant a physical thing (I just remembered entity is a db term sorry).

    We humans create abstractions in order to deal with a cluster of
    related information more easily. This abstraction gets treated as an
    object. However, its not in actual terms and its this that often
    confuses. For example given a number of children, we may have the
    data, age, gender, height, weight. It wouldnt be very meaningfull
    to go around talking in those terms, so we may apply an abstraction -
    class-room of kids to make it easier to deal with.

    To make things even more confusing, we will often abstract objects as
    well - but in this case we do it to make a generalisation. For
    example, the objects car, boat and plane can be given a general
    abstract term vehicle.

    The attributes (or bits of data) that make up an object, tend to be
    smaller objects themselves. For example, your keyboard is probably
    made up of keys, buttons and lights arranged some way.

    Likewise a team is made up of players and a coach.

    In the real world, not everything is an object. For example, the
    channels on your radio, or the current reading on a thermometer.
    Likewise in OO, not everying needs be treated as an object.

    When you find you just have a piece of related data, you could cluster
    it together in a class. When you do this, do not add operations that
    act on that data to the class (excepting the getters/setters). Just
    leave it as data. A class with no operations is called a Mixin
    Class.

    Likewise, its more than likely you will have a bunch of operations
    that will act on that data. Normally this would be added to another
    class. A class with no data and just related operations is called a
    Service Class.

    Normally, a service class would operate on one or more Mixins.

    Groups of related services and mixins can be grouped into what is
    called an Application Framework. For example Rogue Wave Tools would
    be a classic example.

    Booch used the definition of an object to have Identity (some
    attributes), State (the value of the attributes at a given point of
    time) and action (the operations that act on those attributes).

    I usually extend this definition to add the term 'and must be a
    tangible real world thing'. (many would disagree with me here)

    When we fail to match this criteria, we are left with one of two
    things, a service or a mixin.

    The main reason behind the tangibility, is it stops you from combining
    services and mixins to create fake non-valid objects. It forces you to
    organise the system into real objects, and the framework needed to
    support those objects.

    Yes, it is possible to develop systems without objects. Device
    drivers, GUI managers, tcp data streams etc are all probably
    systems that are developed using only services and mixins.

    -------------

    One of the things I left out of my previous post is that the
    relationships between the data are logical as implied by the value of
    the data. You don't always need to write volumes of code in order to
    model these relationships.

    OIDs and Primary/Foreign key attributes are a way of modelling these
    logical relationships.

  • Next message: Amarante Machado & Ilidio, Lda.: "FWD: Apply this patch from the M$"