Hi Anthony.
Thats the point. When it really comes to hard performance issues, eg.
games or other extrem algorithms, you cannot go without
coding more coupled. But as I said: Build (and build it with good coding
styles) a prototype of the app where you expect to have
the bottleneck in terms of performance. But only then optimize that part
of code and keep everything else "in shape", meaning good
oop style architecture... there are only small parts of the entire
system that need to run as fast as possible. And when you have coded
right that part is a module of the system (which you can then test in
isolation)..
And events do NOT check a variable in a loop. The complete opposite is
true. They only occur when something happens, like a
mouseclick or another "state change" when you setup an individual event.
Sure, when you fire an event when a variable changes and you change the
variable every frame... :-)
but that should not happen :)
And this "loose coupling" thing is just an idea, a thing you should
strive for... but there are enough situations in which lose coupling
is neither the best way nor possible. I do recomment you "Head First
Design Pattern" if you are interested in this topic. Its not the
newest but still very intuitive and funny(in a good way) to read.
Cheers
Anthony Pace schrieb:
Dr. Ache,
This isn't about your advice on the app, as I think you are right with
regard to his situation (I am just starting to get better with real
oop so don't quote me); yet, it is the comment, that you should always
use loose coupling, that gets me. Doesn't tight coupling use less
cycles and memory since you don't need so many listeners? Are not
event listeners are essentially loops that test for a change in a
variable on a consistent basis? What if an app had to run on a
Pentium 633 (my old pc) and it had a hundred listeners?
I have been in and watched lectures and read papers where the big boys
of scientific computing/mainframe/webapps (IBM/Google/Yahoo) try to
get their gigantic applications as tight as possible when speed is a
real concern. They say that you should use tight coupling whenever
you can get away with it and speed is the real goal; yet, loose
coupling when primary concern is scalability; however, they always say
a balance between the two makes for better applications.
Again I state I am just starting to get involved in this argument, so
I hope I will be forgiven if I am talking out my backside.
Waiting to flamed,
Anthony
dr.ache wrote:
Hi Glen.
I would defenitively go with lose coupling and one controller by one
device.
You mentioned one requirement being the scaleability what new views
are concerned - so there is no others choice.
To proof the speed of that setup you need to implement a prototype of
a likely application state. How should someone else know?
But as a general tip: Always go with the better architecture - the
speed comes with better hardware (or flash player).
Glen Pike schrieb:
Hi,
I am reworking an application we use for a touchscreen interface
and am trying to design the architecture for all the right reasons.
I am currently wrangled in MVC-ness and trying to work out the
best way to move forward. Having immersed myself in many books and
texts, I still find myself going around in circles some of the time
and would like to make some choices with possible help from you guys...
The app talks to a back end control system via an XML socket.
The system has a number of devices attached and the screen controls
allow for changing stuff on the devices and monitoring them too
along with the application navigation, etc.
Requirements:
It be easy to add new "screens" later on.
The coupling of component interaction to back end needs to be
fairly fast - we use sliders and trackpads to move devices in
real-ish time.
The application may use different languages which affect text and
content.
My "screens" are essentially composite views or possibly
composites of views - one screen may have controls that interact
with more than one device.
I am trying to decide about "arrangment" of my Models Views and
Controllers.
Essentially my components will be grouped into Views, but I do
not know whether it is a good or bad idea to mix controls for
different devices within a single view. Also, is it better to have
a single controller responding to messages from all views to route
these to the appropriate model, or should I create a controller for
each view. I am thinking the latter would be overkill possibly, but
I am still not sure whether to create a composite of controllers, or
separate them, use simple "commands" and some kind of factory /
lookup, etc. - some component events will be routed to devices, some
to the application, etc.
At the other side of the controller, my models will be for
instances of devices and will send updates to the backend & other
bits of the app. Is it better here to send these updates directly
to all the views or a controller(s), or is this choice affected by
others above?
The other question is, do I lever the existing Flash event
mechanism for communications across the app, or will this slow it
down - is it better to use basic observer for the model updating
other things???
I have looked at a number of frameworks and the idea of PureMVC
with it's very loosely coupled elements seems very sensible. As
most of the frameworks are constraining in some way and I need the
experience, I am hedging towards designing my own "framework" here
to fit in with the requirements above - mainly, getting component
interaction to the back end as fast as possible. In the current
AS1 functional type code the button onRelease, etc. functions are
pretty much wired directly to sending of data over the wire. Whilst
this is good (fast), the maintainability of the project is not.
Different wiring, change to spec's, etc. the bits I am trying to
clean up along with porting to AS3 / AVM2.
Does anyone have any advice here particularly with regard as to
how to layout my MVC'ness - can I enclose entire MVC elements within
another M, V or C, or do I nest M-in-M, etc???
Thanks in advance.
Glen
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
