Scott,

Yeah I totally get what your saying. I think when I was talking with roger I had mentioned that I wanted to access like getItemAt() through the ArrayCollection but, if it was used as a public or passed, I would want the client to use the IViewCursor interface.

My reasoning is that for internal manipulation of what I want to a complish, it was esier to use ArrayCollection's public api. I know I could use IViewCursor but, it ends up being a lot more code to accomplish simple things that I need.

Maybe with this scenario, it comes down to personal preference? ;-)

PS, yeah I really didn't need a Strategy implementation with what I was trying to accomplish. The ArrayCollection is always going to be an ArrayCollection.

Peace, Mike

On 3/23/06, Scott Langeberg <[EMAIL PROTECTED]> wrote:
I'm not sure if this is what you're looking for, but this is what i'm trying to illustrate:

Class A {
    var collection:ICollectionView

   function setCollection(newCollection:ICollectionView) {
       collection = newCollection;
   }
}

In this case, an instance of A can change its collection implementation at runtime, as long as that implementation is from ICollectionView. This may be unapplicable in your case, but this approach is very flexible in OOP. For instance, in the Strategy pattern, an object is able to change its behaviors at runtime, based on the behavior object(s) it contains internally.

Scott


On 3/23/06, Michael Schmalle < [EMAIL PROTECTED]> wrote:
Thanks Scott,

The question was really aimed at ArrayCollection, so internally I type it as ArrayCollection and if say a public methods returns it, I would use ICollectionView, then this as you said allows me to swap behaviors in the client class.

Peace, Mike

On 3/23/06, Scott Langeberg < [EMAIL PROTECTED]> wrote:
2 pc:
If you ever want to swap behaviors internally at runtime, use interfaces

: : ) Scott



On 3/17/06, Michael Schmalle < [EMAIL PROTECTED]> wrote:
Thanks roger,

That answers my question exactly! :)

This is how I program, so that makes me happy. Sometimes intuition of feeling goes along way with oop.

Peace, Mike


On 3/17/06, Roger Gonzalez < [EMAIL PROTECTED]> wrote:
My rules of thumb:
  • When passed in from the outside, use an interface.  There's generally no reason to bake in a dependency to a particular implementation, whereas adding a concrete type reference will make it strongly coupled; whenever your class is compiled, it will always force the other type to be linked in (ka-ching!).  If using the interface feels awkward, there's probably a "thinko" in your (or our) design abstraction.
  • When used internally, can you imagine any situation where you might use a different implemetation?  If not, use a concrete type.
-rg


From: [email protected] [mailto:[email protected]] On Behalf Of Michael Schmalle
Sent: Friday, March 17, 2006 6:05 AM
To: [email protected]
Subject: [flexcoders] AS3 :: Interface type verses Concrete type return

Hello,

The question I have is what is the general concensus dealing with how you pass and type a property.

Would you type a property with a concerte type if it is used internally in a class ?

Or with say ArrayCollection, you need to type it IListViewCollection?

I guess the real question is, where is the line between interface implementation and concrete implementation?

It's a lot easier to use the getItemAt() of array collection then the cursor internally sometimes, but for a returned type I do understand that you want to hide that by using the interface of ArrayCollection's  IListViewCollection.
 

If I keep the interface type this is forcing the client to use the IViewCursor right?

Now, is this the standard practice the methods like getItemAt() are only supposed to be used by the objects owner not a client?

I'm just trying to nail standard practices here.

This question really pertains to the ArrayCollection for me right now.

Peace, Mike

PS Yes, program to an interface not to an implementation. Sorry if this post might not be clear. I am having a hard time explaing what my true question is :)

--
What goes up, does come down.

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS






--
What goes up, does come down.

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS






--

: : ) Scott

YAHOO! GROUPS LINKS






--
What goes up, does come down.


--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS






--

: : ) Scott


--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS






--
What goes up, does come down.


--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




YAHOO! GROUPS LINKS




Reply via email to