Re: [flexcoders] AS3 class constructors can't be private? Abstract classes?

Mon, 13 Feb 2006 05:28:29 -0800



On 2/12/06, Michael Hansen <[EMAIL PROTECTED]> wrote:
Please explain why Roger Gonzalez (last 4 lines) construct is a hack (other than different from the Java way)?


Well, it's a bit difficult to me to explain this (I'm not english :P), but let me give a try...
 
To start with I'm not saying that without private constructors we can't emulate a singleton but it'll be a tedious work, and not conceptually suitable.

Facade it's quite different from a Singleton. To start with Singleton it's a creational pattern while Facade is a structural one, so one does one thing and the other another. If both would be the same, one of them wouldn't exist. Roger says that when Manager "gets too porky" we can use an interface... We all know that programming to interfaces is a good practice, but only when they are necessary. An interface isn't always needed. To my mind this is one of this cases ;)

 Let me show you 2 approaches, one using a Facade approach and another, IMHO more suitable, based  on a Proxy approach:

[File name="TestProject.as"]
package {
    import com.code4net.CanvasFacade;
    import com.code4net.CanvasProxy;
    import com.code4net.ICanvas;
   
    import flash.display.MovieClip;
    import flash.util.trace;
   
    public class TestProject extends MovieClip {
        private var canvas_proxy:ICanvas;
        private var canvas_facade:ICanvas;
       
        public function TestProject() {
            canvas_proxy = CanvasProxy.getInstance();
            canvas_proxy.myMethod1();
            canvas_proxy.myMethod2();
           
            canvas_facade = CanvasFacade.getInstance();
            canvas_facade.myMethod1();
            canvas_facade.myMethod2();
        }
    }
}
[/File]

[File name="CanvasProxy.as"]
package com.code4net {
    import com.code4net.ICanvas;
   
    public class CanvasProxy {
        private static var instance:ICanvas;
       
        public static function getInstance():ICanvas {
            if (instance == null) {
                instance = new CanvasImpl();
            }
           
            return instance;
        }
    }
}

import com.code4net.ICanvas;
import flash.util.trace;

class CanvasImpl implements ICanvas {
    public function myMethod1() {
        trace ("MyMethod1");
    }
   
    public function myMethod2() {
        myPrivateMethod();
        trace ("MyMethod2");
    }
   
    private function myPrivateMethod() {
        trace ("myPrivateMethod");
    }
}
[/File]

[File name="CanvasFacade.as"]
package com.code4net {
    import com.code4net.ICanvas;

    public class CanvasFacade implements ICanvas {
        private static var instance:ICanvas;
       
        public static function getInstance():ICanvas {
            if (instance == null) {
                instance = new CanvasImpl();
            }
           
            return instance;
        }
       
        public function myMethod1() {
            getInstance().myMethod1();
        }
       
        public function myMethod2() {
            getInstance().myMethod2();
        }
    }
}

import com.code4net.ICanvas;
import flash.util.trace;

class CanvasImpl implements ICanvas {
    public function myMethod1() {
        trace ("MyMethod1");
    }
   
    public function myMethod2() {
        myPrivateMethod();
        trace ("MyMethod2");
    }
   
    private function myPrivateMethod() {
        trace ("myPrivateMethod");
    }
}
[/File]

[File name="ICanvas.as"]
package com.code4net {
    public interface ICanvas {
        function myMethod1();
        function myMethod2();
    }
}
[/File]

CanvasProxy.as is shorter than CanvasFacade.as and conceptually more correct. Proxy controls the access to a sorrounding object while Facade is just a way to minimalize the public interface of a more complex class or a set of classes.

Why is this buggy? Well the question I think should be: why must I create 2 classes and 1 interface when I could do it just in 1 class? I think this way of implementing a simple Singleton is totally against Flash Platform (which is stablishing as a RAD - Rapid Application Development).

On the other hand with both approaches objects are not being well encapsulated. They are losing knowledge about themselves. They don't know that they only can be instantiated once, instead the wrapper class knows it. A side effect of this is the high coupling between 2 classes. One hasn't sense without the other, and the other doesn't work properly without the wrapper, this means we should use only one class ;-) So having in mind all this, it's imposible to implement a Singleton in AS3 (as it's commonly defined).

I don't know C#2 approach so maybe I'm totally wrong about all this :S

While trying this code I've noticed two bugs. When declaring a public class on a package and a class outside the package (say it's internal/private to the package):

    · If press ctrl+O to organize imports the internal class gets removed.
    · You have to import twice the classes being used in the public classes and in the internal classes. First you need the import statement inside the package, and second the same import statement outside the package.

Abstract classes approach needs also this strangea and tricky implementations. Wouldn't it be better to implement all this needed things instead of other new functionalities? I think it's better to have one working thing than several things working without all they power :-(

Just my thoughts.
Cheers
X.
 

It is interesting to note that private constructors are discouraged in C# 2.0 and replaced by statics. (much like in AS3)

cheers

 -michael



On 2/12/06, Xavi Beumala < [EMAIL PROTECTED]> wrote:
Hi there,
I also completely agree with you. If it's a fact of architecture why not let us (programmers) decide what to use (internal vs private) ??

All new features on AS3 and FES are really amazing, but I think two main things are being forgotten as has been said: abstract classes and private methods.

It's really tricky and weird to use runtime exceptions to control what can be controlled at compile time.

And despite patterns are language agnostic and can have different implementations on different languages they must be easy to identify on the code. Using hacks like the ones explained isn't easy to identify them. Implementing a template method using exceptions IMHO also looks really bad...

Just my opinion
X.



On 2/12/06, Carlos Rovira <[EMAIL PROTECTED] > wrote:
Thanks to god! I thought was completly alone in this topic! : )

2006/2/12, Jens Halm < [EMAIL PROTECTED]>:

> again from other people's coming to the Flash platform  they look at
 > all this stuff as the typical flash hacks from old days.

> I don't know why are you so reactive to introduce private
> constructors that are very clear and precise to resolve this kind of
> things and don't need any trick.

> Another question is what's about Abstract classes that are again very

 

needed.

> Please rethink this two things so we could get a very flexible
> languaje and bring more people form other backgrounds to our beloved
> platform without think that we have a platform full of hacks.

I have to second all those points.

Ok, now we know Adobe had long discussions internally about this
issue, but I still can't see any disadvantages in permitting
non-public constructors which might have led to this decision.
As it seems evident from this and other similar threads the
proposed workarounds for singletons are ugly and confusing for
most developers.

As for abstract classes: Maybe they are not part of ECMA 4 yet?
I tried to google it up, but somehow I am not able to find an
up-to-date specification draft. (The newest one I was able to find is
from 2003). In AS 3 abstract is a reserved keyword but it's not used
yet. But again: If we don't get abstract classes we need non-public
constructors to fake them. In AS 2 I combine private constructors with
empty (pseudo-abstract) template methods to accomplish this.

AS 3 is a huge step forward, but I still miss some pieces in the core
language:

- Private constructors

- Abstract classes and methods

- Enumerations!

- Class.instantiate(args:Array) method


Jens
www.oregano-server.org




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

YAHOO! GROUPS LINKS





--
::| Carlos Rovira
::| http://www.carlosrovira.com

--
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





--
Xavi Beumala
http://www.code4net.com


--
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





--
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





--
Xavi Beumala
http://www.code4net.com

--
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



Reply via email to