Re: [Flashcoders] Best Practices question...

2007-06-02 Thread Ron Wheeler

It is called encapsulation.
No one should know how a class does its magic. The external classes are 
programmed to the interface (methods)(preferably to an interface class 
rather than directly to the implementation) , they are not allowed to 
peek inside.


What if you find a better way to persist the data or change your coding 
standards for variable names?


If you have allowed/encouraged others to access your classes' properties 
directly, their code will now fail to function.
How do you know who to warn or what other classes are at risk;  your 
code has no links to who calls it.


Using getters and setter for anything other than Inversion of Control is 
probably not a good thing either for the same reason and do not normally 
appear in the Interface class. If they do, you are committed to 
respecting their names as long as you support the interface.


Maybe OK to ignore encapsulation if you are a one man show building 
small demo apps but if you are building something serious with a team or 
building something that others will use and maintain you have to be careful.


It is a good practice to get into so that when you build something 
significant, you already have the coding practices that will make people 
respect your work.



Ron

Steven Sacks wrote:
And since we're talking best practices, you don't 

 have any public instance variables anyhow, hmm? :)

I don't know what best practice you're referring to that claims that 
you shouldn't have public instance variables.


The Wikipedia says NEED CITATION.

Which I will promptly ignore as rubbish.  ;)
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com



___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


[Flashcoders] Best Practices question...

2007-06-01 Thread sean
Hi all,

   this should be kind of a simple one. I have been creating my Private
variables as simple camelCased names.

   private var variableName:VariableType;

I have seen other people creating them as underscore camelCased names and
recently I was challenged that the underscore was the correct and best
practice.

   private var _variableName:VariableType;

I'm not convinced. Does any one have any definative information or
experience of this from an OO best practices perspective and an
explanation of why the right answer is right?

Thanks all

S.

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Steven Sacks
I only use underscore for private variables if I have a public getter 
and/or setter for that private variable.  Otherwise, I don't use 
underscore.  It's also a easy way to see, at a glance, which private 
variables are private and which are public but private.


private var _title:String;

public function get title():String
{
return _title;
}
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Steven Sacks
Also, when it comes to flags, I use the isSomething naming convention 
regardless of private/public status. If it's a private flag with a 
public getter, I make the public getter the name of the flag without the is.


private var isActive:Boolean;

public function get active():Boolean
{
return isActive;
}

Steven Sacks wrote:
I only use underscore for private variables if I have a public getter 
and/or setter for that private variable.  Otherwise, I don't use 
underscore.  It's also a easy way to see, at a glance, which private 
variables are private and which are public but private.


private var _title:String;

public function get title():String
{
return _title;
}
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Ammon Lauritzen
[EMAIL PROTECTED] wrote:
this should be kind of a simple one. I have been creating my Private
 variables as simple camelCased names.
 
private var variableName:VariableType;
 
 I have seen other people creating them as underscore camelCased names and
 recently I was challenged that the underscore was the correct and best
 practice.
 
private var _variableName:VariableType;
 
 I'm not convinced. Does any one have any definative information or
 experience of this from an OO best practices perspective and an
 explanation of why the right answer is right?

When it comes to best practices, the best thing you can do is be
consistent. Whether that means consistent with your other library of
work or consistent with the rest of the code in a project you have
joined, making your code as reliably similar to other associated code
should probably be your highest priority.

Thus, if you are editing a class that uses underscores for instance
variables, you should too. If they don't, then you probably shouldn't
either - it gets confusing fast.

Personally, I do lean toward using underscores for my instance variables
if I can get away with it. This allows for a clean distinction between
instance and local variables and is a very easy habit to get into. It's
certainly a whole lot nicer and easier to parse visually than having
bunches of myThis and myThat ;)

It is especially handy to use underscores when you are writing getters
and setters for those variables to further distinguish them - you don't
have to pick a different name for your public property. And since we're
talking best practices, you don't have any public instance variables
anyhow, hmm? :)

Some people will use two underscores for private vars and one for
protected or will come up with some other way to use more underscores. I
would recommend against mixing and matching - that degrades readability
and gets confusing.

You should use either one or two... and two doesn't really gain you
anything. I don't know when the last time I used two underscores before
a variable name was. Probably in another language when I'm not camel
casing things, private instance vars might be named __core_temperature,
or something like that. But it's been a while, and since the AS
convention is camel casing... consistency above all else ;)

Ammon
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Muzak
There is no right answer ;-)
When the first Flash component framework was released, private variables had a 
double underscore.

__width
__height
etc..

Basically because they usually replaced existing built-in properties, like 
_width, _height, etc..
So what we ended up with was:

Built-in
_width
_height

Private
__width
__heigth

Public
width
height

Personally, I wouldn't use single underscores, because built-in properties use 
them (in AS1 and AS2).

A component that needs its own sizing capabilities would then look something 
like this:


class MyComponent extends MovieClip {

 private var __width:Number;
 private var __height:Number;

 function MyComponent() {
__width = _width;
__height = _height;
// remove scaling that occured on stage
_xscale = _yscale = 100;
 }

 private funcion size():Void {
//use __width and __height for sizing..
 }

 public function setSize(w:Number, h:Number):Void {
__width = w;
__height = h;
size();
 }

 public function get width():Number {
return __width;
 }

 public function get height():Number {
return __height;
 }

}


Might be some errors in the above code as I quickly wrote it down.

regards,
Muzak

- Original Message - 
From: [EMAIL PROTECTED]
To: flashcoders@chattyfig.figleaf.com
Sent: Saturday, June 02, 2007 12:25 AM
Subject: [Flashcoders] Best Practices question...


 Hi all,

   this should be kind of a simple one. I have been creating my Private
 variables as simple camelCased names.

   private var variableName:VariableType;

 I have seen other people creating them as underscore camelCased names and
 recently I was challenged that the underscore was the correct and best
 practice.

   private var _variableName:VariableType;

 I'm not convinced. Does any one have any definative information or
 experience of this from an OO best practices perspective and an
 explanation of why the right answer is right?

 Thanks all

 S.


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Steven Sacks
And since we're talking best practices, you don't 

 have any public instance variables anyhow, hmm? :)

I don't know what best practice you're referring to that claims that 
you shouldn't have public instance variables.


The Wikipedia says NEED CITATION.

Which I will promptly ignore as rubbish.  ;)
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Best Practices question...

2007-06-01 Thread Ammon Lauritzen

On 6/1/07, Steven Sacks [EMAIL PROTECTED] wrote:

 And since we're talking best practices, you don't
  have any public instance variables anyhow, hmm? :)

I don't know what best practice you're referring to that claims that
you shouldn't have public instance variables.


Grin. Well, he said OO best practices, not ActionScript ;)

Traditional OO design rules state that you should always encapsulate
your instance data in getters and setters. The general idea being that
external classes should never have the ability or need to manipulate
your data for you - they should have to ask nicely and then accept
whatever you're willing to do in stead. And I agree with that for the
most part.

While I can understand the use of public instance variables in AS2 and
AS3 them because of backwards mental compatibility with AS1... I only
use them in AS2 when the project already does - which is often since
most of the AS2 I work with was written by former AS1 devs ;) It's
also kind of unreasonable to expect people to use private properties
in such a weakly typed language anyway.

I find this regrettable in AS2 but acceptable in AS3 since you can
still just hook into the property and listen for changes and respond
accordingly. That gives you the control you need to safeguard your
internal data.

Ammon
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com