Re: [CFCDev] Since we are on the subject of "Objects for Maintanable Code"

Doug Arthur Wed, 07 Dec 2005 14:58:55 -0800

Be forewarned, this is all off the top of my head...

Dave, this may or may not be directly what you're looking for being that it's rather simple, but it's what I got from your original message that you were looking for in an example about "types"

One example I like to refer to is a card game example:

You have the deck, and in the deck you have cards. Each card represents a value, suit and rank. Each player in a card game holds cards. So, you give each player an instance of a card. Right?

So, you have a players hand that holds a number of cards in it. You would pass in a card as a the "type" of a method in the player object.

</cffunction>

player.addCard(cardObject);

You can reference the cardObject by a getter method on the player object passing a cardId, or a getCards() method and loop through the array.

player.getCard(cardId).getValue();

player.getCard(cardId).getSuit();

player.getCard(cardId).getRank();

- OR-

Variables.cards = player.getCards();

for(i=1;i lte ArrayLen(Variables.cards);i=i+1) {

Variables.cards[i].getValue();

Variables.cards[i].getSuit();

Variables.cards[i].getRank();

}

Hope this helps. Anyone else, please feel free to chim in here.

- Doug Arthur

On 12/7/05, Nando <[EMAIL PROTECTED]> wrote:

Dave,

As far as i understand it, the thing with typing and polymorphism is that you can specify the type of the superclass in your code, decide at runtime which subclass to use or instantiate, and it works.

Say you have a function that accepts an object as an argument. I've got one here at hand, in a component called Message:

<cffunction name="setLayout" access="public" returntype="VOID" output="false">
<cfargument name="Layout" type="Layout" required="true" />
<cfset variables.Layout = arguments.Layout />
</cffunction>

As you can see, the argument is typed to only allow an object of the type "Layout".

I've also got a bunch of objects, like PF_Patchwork, which are subclasses of Layout. Here's the component tag in PF_Patchwork

<cfcomponent extends="Layout" displayname="PF_Patchwork">

Layout of course is never instatiated. Whenever PF_Patchwork is instatiated, it it passed into Message using setLayout, with that argument type "Layout", and it works.

****

It will also work with an argument type of "any" - so what's the big deal?

I've been working on a fairly complex section of an OO app. It's impossible to keep everything in my mind at once. Typing arguments and returntypes is proving to be a much bigger help than i ever expected as i develop and debug this, because each function in effect is watching what comes in and what goes out, and has the opportunity to say: "Hey you, scarecrow, this isn't what i expected!"

("Oopps ..." i say to myself, a little ruffled, and a bit more straw falls to the floor under my desk...)

So polymorphism allows you to type for subclasses using the supertype, and gain the advantages of typing when you don't know ahead of time which class will actually be instatiated at run time. It's a lot more useful that it looks at first glance in a simple example, because it's value increases with the complexity of the app.

:) Nando

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Shuck
Sent: Wednesday, December 07, 2005 7:13 PM
To: [email protected]
Subject: Re: [CFCDev] Since we are on the subject of "Objects for Maintanable Code"

Yes, it does make sense. I was trying to resolve how you would do that if the decision needed to be made at run time. Maybe in one case it was a programmer and in another it would be a project manager. I can't think of an obvious case for that at the moment, but it just seems like something that might happen in real life. I guess the choice from those two options would be a getEmployeeType() as you said.

Like you, I am interested to hear others' approaches as well.

Thanks for the input.

~Dave

On 12/7/05, Steve Bryant < [EMAIL PROTECTED] > wrote:
Dave,

I would be interested to see what those more experienced at OO than me would say about this, but I will tell you my approach.

(1) For the DataMgr, I have a getDatabase() method that returns the name of the database being used ("SQL Server", for example). I think that a getEmployeeType() would be similarly useful.

(2) On the flip side, if the task is something that seems like something that the employee is "doing", I might add a method to the employee - like "persist". Then you could take advantage of polymorphism and have the "persist" method do nothing except for programmers. Note that you would do this by over-riding the method, not by adding a conditional.

For (1), you could check the results of getEmployeeType() and then take an action.

For (2), you could just call persist() on each object, knowing that the method would only actually do anything for programmers.

Does that make sense? Am I off my rocker?

Thanks!

Steve

At 11:25 AM 12/7/2005, Dave Shuck wrote:

Thanks Steve. From my still very green and limited knowledge of OO, that is an example of polymorphism if I am not mistaken, correct? That being methods in sub-class objects overriding methods in the objects that they extend.

I am fairly comfortable with that concept and created a mini-app yesterday based on Hal's example of employees each having different work() methods for their position that overrode the employee object work() method. Here is where I get kind of hung up is this...

Say I have the following code, and say that each of the objects I am instantiating below extends "employee", and within each object there is only a work() method that represents the work that is done by that position. The rest of the properties and methods are inherited from "employee" object.

<cfscript>
aEmployees = arraynew(1);

dave = createObject("component","cfc.programmer").init();
dave.setemployeeID(createUUID());
dave.setFirstName("Dave");
dave.setLastName ("Shuck");
dave.setHireDate("3/2/2004");
aEmployees[1] = dave;

jane = createObject("component","cfc.projectManager").init();
jane.setemployeeID(createUUID());
jane.setFirstName ("Jane");
jane.setLastName("Doe");
jane.setHireDate("2/15/2000");
aEmployees[2] = jane;

bob = createObject("component","cfc.marketingPerson").init();
bob.setemployeeID (createUUID());
bob.setFirstName("Bob");
bob.setLastName("Marketer");
bob.setHireDate("10/15/1999");
aEmployees[3] = bob;
</cfscript>

If I wanted to loop through that array and only do something [example: persist the data] to employees that were type "programmer", how would that best be accomplished in code?

~Dave

On 12/7/05, Steve Bryant < [EMAIL PROTECTED]

> wrote:

Here is my best example (if my example is wrong, please somebody let me know):

DataMgr

DataMgr_Access is a DataMgr (for MS Access)

DataMgr_MSSQL is a DataMgr (for MS SQL Server)

DataMgr_MySQL is a DataMgr (for MySQL)

DataMgr_PostGreSQL is a DataMgr (for PostGreSQL)

Each of these inherits behavior from the parent object, but extends

that behavior for the specifics of that database.

http://www.bryantwebconsulting.com/cfcs/

Hope that helps!

Steve Bryant.

Bryant Web Consulting LLC

http://www.BryantWebConsulting.com/

http://steve.coldfusionjournal.com/

At 10:28 AM 12/7/2005, Dave Shuck wrote:

>One of the concepts that I read about, and I understand from the

>thousand foot view is making use of "types" of objects, but I am

>having a hard time with translating that to what it means in

>code. In the example, of the AJ Foyt Car Center (or something like

>that), they would only accept vehicles of type "sportsCar", given

>that sportsCar extends "car" and car extends "vehicle". Does anyone

>have a code example of something like that? I realize that once I

>see it it will likely seem glaringly obvious, but for some reason I

>am just having a hard time visualizing that code in a real implementation.

>

>Thanks,

>

>--

>~Dave Shuck

>< mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]

> www.daveshuck.com
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Re: [CFCDev] Since we are on the subject of "Objects for Maintanable Code"

Reply via email to