Re: Factories and lazy objects

From: James D Carroll (jamesdcarroll_at_hotmail.com)
Date: 06/13/04

  • Next message: Lee Riemenschneider: "Re: Coherent exposition of OO?" 
    Date: Sun, 13 Jun 2004 01:37:49 -0400

    Responding to Lahman:
    First, thank you very much for your time. If you're ever in the Philadelphia
    area the first round is on me. Oh heck, all the rounds are on me! : )

    > Not a problem per se. The code is just klutzier because explicit
    > setters have to be used to set the references.
    If I have to do it in VB6 I was actually going to give every class an
    "init()" method that could take parameters, would initialize the object, and
    return an error if it hadn't been called before accessing any other members.
    But we can leave the OO-ness of VB6 for other discussions.

    > However, these mysterious Process classes seem like they are becoming
    > more and more important to what's going on. B-)
    You are correct. My OP was about lazy objects and factories. But as for the
    system I'm trying to create a framework whose MOST important concern (among
    many) is that the Process classes can be plugged in and out of the system
    without the rest of the system being aware. This means that it may seem
    complex, but I believe that its needed.

    > However, from an OO construction viewpoint, I am concerned more with
    > Dispatcher. It seems to be a controller object that is sequencing
    > everyone else's behaviors. That's an OOA/D no-no. Objects should
    > collaborate directly as peers.
    Dispatcher IS the controller. There HAS to be someone that sets the course
    of actions to be completed, doesn't there? Treating them as peers would, to
    me, seem to allow any of the objects to do it own thing. This is not what I
    want. I want all the objects to be fairly dumb, but for the Dispatcher to
    orchestrate their actions. In order to collaborate directly with "peers"
    would require them to know of one another and therefore, by knowing, be
    effected by changes. I want to avoid this.

    > I am confused. If one gets Account from MainFrameConnection, how can
    > mainframe be shielded from Account? Isn't MainframeConnection creating
    > it? (I thought MainFrameConnection was a surrogate for reading the DB
    > for Account data.) If not, who is and why doesn't Dispatcher get it
    > from them?
    The MainFramConn isn't shielded from the Account, the Account is shielded
    from the MFC. As I said "It is necessary to
    shield the Account from the mainframe". In fact, the MFC can call methods on
    Account that no other objects can. The Account object is passive (shielded),
    simply accepting those values from the MFC regardless of where they really
    come from. This allows me to tell the MFC that for a particular Process that
    its data should come from 1. the local test data, 2. the mainframe test
    region, or 3. the mainframe production data region. The Account would not
    care (nor would the Dispatcher or the Process) where the data came from.

    >Why doesn't Dispatcher send a message to
    > Mainframe with the account number and then have
    > MainFrameConnection send as message to Process after the relationship to
    > the new Account is instantiated?
    >
    > I could push this even further by asking: why do you need Dispatcher?
    > Whatever message it responds to that causes it to extract the account
    > number could be sent to JobsTable who then sends a message to
    > MainFrameConnection. [I suspect this would be overkill because that
    > would mean JobsTable has behavior responsibilities and it really sounds
    > like a dumb data holder. My point is simply to underscore the need to
    > think in terms of peer-to-peer collaborations rather than controllers.]

    I understand what you're saying, but that's just not the system that I have
    in mind. The Dispatcher is the controller and basically sits there in the
    middle and says:

    Hey, JobsTable, give me the next account and tell me which Process should be
    used
    Hey, MainFrame, give me this Account (don't forget to ask the ProcessTable
    if you should use local, test, or production data)
    Hey, Process, do something to this Account
    Hey, MainFrame, commit these changes (don't forget we're using local, test,
    or production data)
    Hey, Logger, remember what changes were made

    Repeat

    >.... , then [Transaction] reinstantiates R3
    > to a different [Process] subclass and the previous paragraph is
    > repeated. When all the transaction processing is done, [Transaction]
    > kills off [Account], the relationships, and then itself.
    >
    I think we are just thinking of different "Transactions". Think of credit
    cards. You have different "transactions" that occur. Charges that you make
    at stores, payments that you make, late fees, interest, etc. It is
    DEFINITELY subordinate (in this system) to the Account: a Transaction can
    not exist except in the context of an Account (1 Account has many
    Transactions, one Transaction has one and only one Account). If there is
    anything to DO with an account, it will be in a Process class.

    > There are a couple of key points. One is that instantiating
    > relationships involves separate context-related decisions from
    > collaboration. Isolating that responsibility removes it from objects
    > that are simply sending messages to whoever is on the other end of the
    line.
    >
    And that to a large extent is what I want to do. It is my belief/experience
    is that its "the context that binds us". And when that happens any change to
    the context has a ripple effect through the system. The system that I
    envision concentrates context to the Dispatcher (and even then its the tool
    of the JobsTable and ProcessTable). All other objects (MainFrameConnection,
    Account, Process, Logger, etc) are simply puppets to either read and/or
    write data. They are contextless and therefore truly independent in that I
    can change any of their actual implementations without altering any of the
    other parts of the system.

    > The second point is that one can connect the processing dots by sending
    > peer-to-peer messages. In particular, note my reference to "announcing"
    > something happened in a couple of places. Ideally the message sender
    > needs to only send a message to announce that it did something. You, as
    > developer, know who cares about that and direct the message directly to
    > that entity.
    That's true, but the message sender must call those in a particular order.
    Even something as simple as a button with many "listeners" will maintain a
    List of listeners that it calls in order.

    > These two things conspire to eliminate implementation dependencies. In
    > particular, they eliminate hierarchical dependencies like the one I was
    > concerned with above in Dispatcher. In your version Dispatcher must
    > have the entire sequence of operations hard-coded in its implementation.
    > Any change in the collaborations among any of the objects would
    > require a change to Dispatcher's implementation in addition to changes
    > to the collaborators themselves. But in my version such changes can
    > probably be done by simply redirecting messages _at the point where
    > other changes have to be made anyway_.
    This might be yet another case where my poor choose of object names, like
    Transaction, has imbued an object with attributes that it really doesn't
    have.

    I have a feeling that eventually I will lose the MainFrameConnection object
    and make the Account object responsible for getting its data. At least then
    I can do something like:

    class Account{
        private List Comments;

        public List getComments(){
            if Comments = null {
                // tap MainFrame
                // populate Comments
            }
            return Comments;
        }
    }

    I can't think of a way to do that and still keep the MFC without populating
    List even though it may not be needed (by the Process). It would be (given
    my world) very wasteful to do so.

    Again, thank you very much for your help and time. Its been great to talk to
    someone who speaks (most of) the same language that I do. Everyone at work
    tends to give me the "RCA Dog" treatment when I talk about programs. : )

    James 

    ---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.705 / Virus Database: 461 - Release Date: 6/12/2004
  • Next message: Lee Riemenschneider: "Re: Coherent exposition of OO?"
    • Quantcast