Forums: Flash:

OOP Building User Interfaces Properly

alright, as you know I've struggled with the philosophy of OOP vs. Procedural vs. State vs Whatev because even when people were explaining OOP I still struggled to understand where some of those things were OOP. I'd be meeting with "Pure OOP Flash Agencies" and I'd end up saying "that's not OOP!"

But coming up with how I need to switch my mind into using OOP approaches was killing me. How do I begin a project when I come from a push-pull object mentality where each thing is a thing and they can pass data and objects around to each other. I needed a real explanation and I finally got it.

This guy's ATM example with the Teller not knowing how the Bank officer makes the decision is brilliant in my mind. He also dispels some of the truths of some mistakes developers make and call it OOP.

It's worth a read if you're anything like me.

Nice link. I spend so much time away from the tools these days it's nice to have a refresher now and then

Even though he was a java guy, he made a lot of sense I thought.

Now if I can just get a good AS example like this I'd be happy.

eg.
If you want to compile with the Flash IDE, make a new document and use the Document Class field and make your document a class. Your 'Document class should always extend MovieClip because.......or Sprite because.....

Then write and assign a Controller class that extends EventDispatcher because....

blah blah blah.....

Shit like that and WHY in non-computer science language would be perfect. I think no one ever explains WHY probably because they don't really know. It's just what they were told. I have yet to see any AS article like that.

interesting link, thanks. It made sense to me too and I don't think I've ever heard it explained like that - the idea of not asking objects for any data about themselves, but ask them to do something with their data.

I kind of just stumbled on one of bit's old presentations too that I had never read....
bit-101.com/blog/?p=1453

I follow this site as they have a lot of focused Design Pattern and other OOP discussions as related to AS - and a lot of it is written pretty clearly and without the melting-of-the-brain side effects.

HOT XXX OOP PORN

My point from the first article is that a lot of "OOP" discussions aren't even OOP.

I read that link and I got 3 sentences in...

The Decorator Design Pattern is an enigma wrapped in a perfectly clear casing. I can think of fewer design patterns that are clearer in terms of what they do or seem more practical. By using concrete decorations, you can change an object without touching its structure.

The Pattern is an Enigma in a Clear Casing? WTF is that?
So, he's trying to be CLEAR.... but he's not saying anything in real English language. And why is the term now "a decoration" versus "a hippopotamus" or what it truly is "an OBJECT"? Why is he just trying to make fancy new words?

Furthermore, and deeper down, he relates the "Abstraction Dependency Principle." Ok, that's fine. Introduce what you want to. But please discuss WHY you made that choice....WHY it is an advantage.....counter WHY this is a more thorough approach than the other approach (whatever that is).

The pricing of the car was based on both on the base price (Component) and the whistles and bells (Decorators) the buyer selected.

Now tell me why the whistle whistles when the car starts or the user chooses to interact with the whistle component and why your approach is an advantage to other approaches for making the whistle whistle.

His/Her summary is this:

As you can see in both the diagram and code snippets, all dependencies are on the Abstract class. That’s what the principle means at its core.

That's not a summary or a conclusion in any way whatsoever.

That's like saying:
"As you can see in in the daylight, the sky is blue. That’s what we mean when we say the sky is blue.

Before AS3, there was NEVER ANY DOUBT as to how we should approach projects. We, as Flash designers/developers made our own standards.....'actions' top most layer, frame labels, load external .SWFs for more content, build preloaders for each separate SWF, etc, etc.

Now, with 5 minutes of reading, you could be presented with 8 million different "programming theories" which have evolved from 8 million programming languages (exaggerating of course) and it doesn't seem like Flash people have a way of comparing what approach we as a community should take. If you want to propose 'The Decorator Design Pattern'....GREAT but you've got to write about WHY and what advantages it brings for you as a Flash developer and all the while making sure if you say its OOP, then you make sure it IS OOP. A lot of the theories / approaches aren't even OOP.

I'm sorry but the writing on that site is not well written or clear in any way whatsoever. Its programmer babble. Big words for the sake of being heard.

Hahaha - I think you have to start somewhere and as you get more into these concepts it makes more sense. That site definitely has a range of complexity with its articles, but I found quite a bit of it helped me where I previously wasn't so sure. I think it will always prove tricky when you are trying to express concepts and you don't want to give too many examples because that ties you into a particular case scenario and doesn't always demonstrate the concept itself.
I think the point is not to confuse you, but to take concepts that have been proven successful in coding practices (namely the GOF book on design patterns) and implement them in AS3. But really this is also not a thing about AS3 either - these are coding concepts and you could just as well implement them in AS2.

You're missing my point about all of it. But that's ok.

but to take concepts that have been proven successful in coding practices

This is the problem. Code Junkies have never been able to decide upon approaches. They argue all the time. Now those same arguments are enveloping the Flash community which somehow over the 10 years of its existence and worked on by ALL SORTS OF TYPES OF PEOPLE had Best Use Practices.

Article 1 was brilliant in that it called bullshit on a lot of the "OOP Theories" because they weren't really OOP.

as you get more into these concepts it makes more sense

Translation (in real English):
You have to have an understanding to come to an understanding.

That's not teaching and that's not learning. I might as well have my own theory, write it and then say....

"Once you understand my concepts, you will be able to understand my concepts."

I don't expect you to understand, it's ok. It's more about the philosophy of design and development. Programmers are small thinkers. it's completely technical knowledge (techne according to the Greek Intellectual Virtues).

My point is I'm NOT from Java and I'm NOT a Programmer (I program and have since Lingo and ActionScript began..but I'm not a programmer nor do I want to be). I completely understood EVERYTHING the guy in Article 1 said because he communicated effectively through writing. He had a point. He presented it. He gave reasons and justifications for his theory. He made his point.

The reason I took exception with your link was because it is not effective communication or teaching except to those who think exactly like him.

The whole reason I linked to Article 1 was to help EVERYONE not just those who think like me. We've got too many "experts" who aren't teaching or working together to further to processes together....they're babbling.

mystic_juju

Maybe I am tired from reading other stuff, but that link you posted talks comvoluted rubish, maybe it gets better but I lost interest before it started on examples, I felt it was badly written and typical of much of new breed as3, often not able to explain simple ideas simply and jumping on some other coding bandwagon.

Storm posted was interesting I have certainly found issues with my own flavor of MVC but I tried reading the second section on some implementation and it assumes rather a lot of familiarity with java, it starts out ok but by the time it gets practical I have lost all interest. I would love to see some real implementations in flash, what often worries me is that as flash creatives we seem to have to create far more complex interfaces than a lot of java apps in no time and try keep them manageable and simple, but most of the examples have a couple of visual elements and seem convoluted to the nth degree. I wonder if OOP is not suitable! Maybe I should be looking at functional programming or something!

Wow - well I wasn't really trying to get anyone riled up. I've just enjoyed going over the stuff on that site, and found quite a lot of it useful for me. But yeah, I guess I can only speak for myself. But also, I don't really think the two sites are in a competition - you can take what you want from either, and if you aren't interested in as3dp, I have no beef - I am in no way attached to it.

I think a discussion about the value of Design Patterns and OOP methodologies is not a simple one and you are right, Storm, when you say that people argue over the way to do things. And it is in the balance (between complexity and practicality) of your coding practices that one finds what works for you and what makes sense at the end of the day. I agree that there is a whole bunch of bullshit out there and people can get way too crazy over the jargon and methodologies, but attempting to get your head around concepts like this and succeeding will end up being a good thing. A broader understanding will give you more ammo for rejecting theories. And yes, I think that many of those discussions on as3dp DO broaden understanding - albeit in some cases over time and a bit of hard work (it's ok to need to read some things twice - I don't feel that complex things ought to always be clearly expressed in a first read - thats just too demanding). When you say that you have to have an understanding to have an understanding - well most things in life are like this. Take any field or discipline, take language, whatever...you learn a bit which gives you insight into the more complex aspects and so on.

Also - if you aren't a programmer, there is no need to get incensed about people discussing programming concepts in programming jargon. That's sort of weird. I don't attack people writing in medical terms about medical conditions just because it is complicated and the terms are written all medical-like. And I don't think these Design Pattern discussions are done just for the sake of it - they make sense in that context.

No one's riled up. What we're trying to do is bring "Flash" back to the same language it used to have so that people who "knew Flash" can have some resources to continue to "know Flash" without adding a Computer Science degree. Devigners should still be able to do what they need to do quickly and there will still be cases where hard-core programmers are needed too.

The point is trying to get Flash back to where we stop fighting over "concepts" and start finding our agreed Best Practices.

The funny thing is you've totally confirmed what I originally said....

I think no one ever explains WHY probably because they don't really know. It's just what they were told. I have yet to see any AS article like that.

We've had AS3 for way too long for us not to have begun communicating with all Flash people (not old Flash devigners talking only to old Flash devigners nor new Flash CompSci programmers talking only to new Flash CompSci programmers) in order to start to develop our new "best practices."

So, really if you're offended by me and my statements or simply think I'm riled up and "incensed" then you've got some learning about me to do. I want the dialogue we used to have in order to move Flash development (with full OOP AS3) into a good stream where we're all following similar dev styles because they work for Flash. Right now, we're inundated with processes that work elsewhere so maybe they'll work for Flash too.

And for a lot of them, their OOP isn't even OOP so the original article was to point out that those who claim OOP need to learn and stop proclaiming them as OOP when they're not. In fact if you apply Article One to your Link, there are many cases where your guy has done what Article 1 said should NOT be done following OOP, so it makes me think you didn't read Article 1. Whether you learned from your link or not is fine, but it proves that what guy in Article 1 has said is completely true.

But man, you question any "OOP Guy" these days and they defend themselves to no end but without really being able to claim where their processes are right or wrong other than simply, "it exists so it must be."

A Flash "OOP" article that begins with "Open Flash" would be fantastic. I've yet to find one. That's the funny thing about it all. Most of us still like drawing on the stage because we're artists and designers. Some of us are also wicked fucking programmers but don't relate to Computer Science language. That's all. So, if Computer Science guys want to help work along side us, they need to communicate better. Java Guy in Article 1 wrote a brilliant article and was very clear. That's why I posted it. Him and I speak completely different languages but he also understood where I might be coming from along with all his readers. That's the sign of a good teacher and someone who knows how to pass on his knowledge effectively. If Computer Science guys want to keep masturbating each other with "The Pattern is an Enigma in a Clear Casing" language, that's fine but it doesn't really help the community. It helps a segment of the community and in the current time, we need both sides of Flash coming together not further separating themselves.

Why? Because Flash has always been a tight tight community but it's straying badly in new directions.

The 'why' you are after is not a hidden secret that only compsci techies know about. These discussions are about better code - that's the why. More clearly - it is about doing something the right way, so that it holds together well, doesn't break, allows for flexibility, extensibility, or modifications along those lines. It is so that you don't get a bug and have no idea where it came from or what is causing it, because you have a good overview of your code and you can spot oddities a mile away.
Or from the as3dp site - the third sentence in that article you reference, "By using concrete decorations, you can change an object without touching its structure." The why in this case is not hidden - it's pretty clear to me. I create an object and then I can decorate it (add functionality) over and over without changing its structure. There is nothing mysterious about that - that IS the why. Or even more explicitly - the why is so that I don't write code over and over that shouldn't be written over and over again. I start from a solid base and work from there, but moreover I have flexibility in my project, so if one of my dumbass clients come to me for a change I can whip it up quickly, because I've written it right in the first place.

But ok, maybe, at least to some degree, you aren't arguing about the virtues of WHAT is being discussed, but rather HOW it is being discussed, and that is a fair point. But then, maybe you should also allow some room for the flash community to grow and spread and incorporate your so-called masturbating Computer Science guys. Maybe they have something worthwhile to say too. Contrary to what you might think, some of these processes that are talked about DO work for flash, and maybe you should be open to that. In my opinion there have been a shitload of terrible sites in flash history (obviously together with a shitload of good ones), but certainly a lot of bad ones because they didn't incorporate the complexities of really good coding practices.

As for me, I am not a CompSci student, but I dig getting into the meat of what proper computer theory has to offer and see how it can apply to Flash so that my Flash is better off for it, and I really enjoyed what I read on as3dp, so I don't know.

You're such a technical thinker.

The WHY in this case isn't a systemic list as you've provided. Those are always there as "selling points" but not what I'm talking about. You really need to get outside of code for this.

I'll still try to keep it within technical language for you though, so we can discuss.....

Example, code within MovieClips does exactly what you've said. It's reuseable (drag it from the Library anytime, in any movie), it doesn't break anything else if you remove it due to a client request (because it was coded properly inside of it), it can be easily replaced (Swap in the Properties Panel), it can be handed to a designer for graphic tweaks (they open the file and don't touch the Actions Panel). If its done right and by those who followed the standards of the Flash community, this was already in Flash. Everything you listed was possible in Flash already. It was Object Oriented. Always has been.

So, I understand wanting to Class everything from a code perspective but it also counts out the perspective of the designer...and in Flash they are a team or the same person. Flash is not code-only and Flash is not graphic-only. It is a different beast than anything on the planet. It is a Platform and I have never discounted the CompSci guys' perspectives in any of my discussions. My point was why can't the other CompSci guys write or explain their decision making or the WHY of their decisions in a way such as how the writer of Article 1 states? It's not difficult if you're a good teacher.

So, back to my original thoughts which I have not deviated from.......how are we going to start getting AS3 discussions that revolve around a better process for those wishing to stay in Flash, draw their own drop-down lists, buttons, have a custom animation, and then write some wicked Classes to put it all together. It's all great to follow MVC, but when you build your large application, WHY are you choosing to have ONE Controller work with 3 Models and 4 Views.....or WHY are you choosing to have 1 Controller for 1 Model and 1 corresponding View.....or WHY are you using Singletons....or WHY did you deviate from true OOP (according to Article 1) in order to make something work when you've said OOP is THE BEST?

"I use MVC because it's better code" doesn't help anyone. And it's becoming way too common of a theme on all the Flash sites.

I create an object and then I can decorate it (add functionality)

So, you created an Object and then you "decorated" it (a "design" term by the way) to add functionality.......then you need the Object to be BLUE with a gradient that when the mouse goes over it, the animation should take 0.5 seconds, and shows a custom icon. Please tell me your process for getting the graphics in there smoothly and being able to work with the designer who draws that custom for you. NO COMPONENTS are used because it's custom for a client.

People like me do both and do it very well. But there's also Flex guys on the other side of the room who type <mx:Button> and don't care what shows up on screen as a result of their code.

So I want to know the overarching BIG PICTURE WHYs not the small process/systemic WHYs.

The funny thing is (and I'm not being insulting....I'm furthering the discussion) that you haven't commented once on Article 1. I think Article 1 highlights many weaknesses in some of the articles posted at your link. It helps you code better according to you, but are you really REALLY OOPing? If you're following those articles and ignoring Article 1 (whom I believe to be bang on) then I don't think you are.

And I'm trying to improve my OOP skills and when I read these articles such as what you've linked to.....it's not that they're over my head....it's that I think they're wrong. But for me to judge, I want to know WHY they made those decisions. They went to all the work to separate their code into classes and packages and then they revert to a procedural process to push a functions result or used a GET and SET method to make it all work.

Finally....

I dig getting into the meat of what proper computer theory

Cool. No worries mate. S'all good.

But, I think "proper computer theory" has weaknesses. It hasn't provided all the answers on how to build proper applications and interfaces for ordinary users. Flash has the potential to do that by providing new and versatile options because it can be for designers and developers who work together with ideas from both camps, but everyone is targeting the Flash platform as the new place to code the old 'proper computer theory' methods. We end up with Flex apps that do nothing more than what HTML/Ajax had done just with some flashier buttons. Those processes never answered how to build better applications and better interfaces.