Home >
As we have previously mentioned, Flex 3 makes use of ActionScript 3.0, a powerful object-oriented programming language. Before we dive into the specific syntax used in ActionScript, let's take a look at what makes a language object-oriented in the first place, and the benefits to using and object-oriented language versus a procedural language.
ﾠ
One of the benefits of object-oriented programming is the manner used to describe the elements that make up an application. We can analogize describing elements of an application to the way a human would describe the elements that make up a physical room.
ﾠ
If you were asked to describe your immediate surroundings as thoroughly as possible, you'd likely start by listing the various objects you see in front of you. If you're in a room with some furniture that includes a few chairs and a table, for example, you could talk about how many chairs there are, what color they are, and whether they have cushions. If there's a door, you could report whether it's closed or open. If there's a clock, you may indicate what time it is. By touching on the various elements that make up your surroundings, and by describing the specific state that they're in, we could get a clear picture of what you're seeing. This is true because even though we have never seen your particular chair, or door, we have a abstract notion on what chairs and doors are. Your chair is brown, it's got a cushion, and your door is closed? No problem, I can dig that. It would be a problem if you reported that your chair was closed and your door had a cushion because that wouldn't jive with my expectations of chairs and doors.
ﾠ
If you were to use this approach of using objects and their behaviors to write computer programs, you'd be applying the object-oriented programming paradigm. Central to object-oriented programming is the use of objects which are specific representations of classes. In the above example, the door that we refer to is an object that has been derived from the class "door". A class can be thought of as a template from which objects are created. The class defines the various behaviors (methods), and qualities (properties), that an object will have. In object-oriented terms, an object's methods and properties are known as members. An object should almost always contain both properties and methods.
ﾠ
The above example describes a room with furniture as it exists in the real world. Let's explore the way an object-oriented program would describe the same scene. First of all, we have an object called Room. Room can be thought of as the parent object in our example. In object-oriented programming, the process of creating an object that contains several other objects is known as composition. So, our Room object is composed of many other objects (Clock, Chair, Door, etc). The language used to describe these relationships is "Room has a Clock", because Clock is a property of Room.
| Room |
| Clock Chair Door |
| Enter the Room Leave the Room |
As you can see, our Room has a Clock, Chair, and a Door. There are also two methods available as part of Room: "Enter the Room" and "Leave the Room". These are both things that you'd like to "do" to a Room. Now let's take a look at the rest of the items that our Room has, modeled as objects.
| Clock |
| Hours Minutes Seconds AM or PM Position in Room |
| Set the Time Move Clock in Room Move Clock to new Room |
| Chair |
| Cushion Number or Legs Height to Seat Total Height Position in Room |
| Sit in Chair Stand up from Chair Move Chair in Room Move Chair to new Room |
| Door |
| Height Can be Locked Is Locked Wall Positioned On |
| Open Door Close Door Lock Door Unlock Door |
A fundamental aspect to object-oriented programming is the notion that classes are relatively self-contained pieces of code. What this means is that the functional information contained within a class is separated from the objects that act on it. This aspect of object-oriented programming provides protection for a class so that objects that aren't relevant to the class can't access its resources. In the above example, a chair cannot be open or closed because that's not part of "chair behavior". A class protects its contents through encapsulation. Encapsulation dictates the level of access a program may have on the methods and properties of a given class.
A programmer controls the type of access an application can have to its objects by using access modifiers. In ActionScript, parts of a class may be declared public, private, or protected. A method or property of a class that's determined to be public may be accessed by all objects in a program. A method or property that's private may only be accessed by members of the same class. Finally, a method or property that's protected can be accessed by object of its own class type and any class type that's derived from that class. This leads us to another major part of object-oriented programming -- inheritance.
A class in an object-oriented program may give rise to many related sub-classes. To use a real-world example, a chair could be thought of as a relative of the furniture class. Chairs, after all, have characteristics in common with all furniture, even though they have their own unique qualities as well. You may extend the chair class even further and introduce a rocking chair class, or a barstool class. Both rocking chairs and barstools are types of chairs, and therefore also furniture. Rocking chairs and barstools are said to inherit the methods and properties of furniture and chairs. They are both movable structures that are designed to support the human body (or however you may define furniture), and they are specifically designed for sitting. What inheritance does for object-oriented programming is allow for scalability without having to completely rewrite code for every single object. Inherited objects have an "is-a" relationship with the classes they inherit from. A rocking chair "is-a" chair, and a chair "is-a" piece of furniture.
So returning to our real world "room with furniture" example, suppose we'd like to add another chair to our room. We found a really sweet barstool on eBay using the eBay Desktop application (because we're hip to RIAs), and we decided to add it to our collection. It's safe to say that when it arrives we won't have to completely relearn how to use it. We've got a lot of experience with chairs of all kinds after all, and sitting on this one shouldn't be much of a stretch. This may sound obvious, but when it comes to programming such a scenario, unless we do some tricky stuff we would actually have to re-code part of our application every time we wanted to add a new component. This is because unless we explicitly state how a program should interact with an object, it will have no way of knowing what to do. We solve this potential headache by using what's known as an interface. An interface is simply a collection of methods that governs how new instances of a class should behave. An interface for the chair class would outline behavior that every chair, regardless of type, would demonstrate. It wouldn't include rocking, for example, because barstools probably don't do this. It may include "supporting a human" though, because all chairs regardless of type do this. Using an interface goes a long way in making a program scalable. Because the original code doesn't need to be modified any time an addition is made, programmers can quickly add to an application.
The development of the object-oriented paradigm has given programmers a powerful model for creating applications that mimic real world scenarios. In addition to providing a real world perspective, object-oriented programs are by nature scalable considering they are composed of self-contained units of code known as objects. Although a thorough exploration into object-oriented programming goes beyond the scope of this article, a sound understanding of its basic principles is important for anyone learning Flex. In our next post we'll discuss more specific syntax as it applies to the object-oriented language of Flex -- ActionScript 3.0.
Current Glossary of Terms
ﾠ
Access Modifier A keyword that declares what part of a program may access the methods and properties of an object. Commonly used access modifiers are public, private, and protected.
ﾠ
Class In object-oriented programming, a class is used as a template to create objects. The class contains the behaviors and attributes of the objects that are created from it.
ﾠ
Composition The process of creating an object that contains one or more other objects.
ﾠ
Encapsulation The protection of an object's methods and properties through the use of access modifiers.ﾠ
Inheritance The relationship of classes with a shared origin. A specific rocking chair class is inherited from a base chair class.
ﾠ
Interface A collection of method and/or property descriptions that are used to define how a program interacts with members of a class.
ﾠ
Member A method and property of a class.
ﾠ
Method Behaviors associated with a class.
ﾠ
Object An instantiation of a class
ﾠ
Object Oriented Programming A programming paradigm that is centralized on the use of classes and objects to abstract the functional element of a piece of software.
ﾠ
Private An access modifier that declares that only the same class may access an object's methods and properties.
ﾠ
Property A characteristic of an object. Also known as the object's data.
ﾠ
Protected An access modifier that declares that only members of the same class and its derived classes may access an object's methods and properties.
ﾠ
Public An access modifier that declares that an objects methods and properties are accessible throughout the entire program.ﾠ
Next: LFFS - 4: ActionScript 3.0
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Object Oriented Programming is powerful stuff. Me I love it. It allows me to express my ideas easier.
The thing is with OOP is that it separates the designers from developers. That doesn't mean all designers will not be able to develop with Flex because OOP. Flex's MXML API is fantastic for designers. When it comes to working or developing a hard coded component object, that is where the designers will be left behind.
Good old Adobe though, they have thought about the designers and are working on really advance interface designer, so that what a designers develops can be reality. It was presented at ADOBE MAX 2007.
OOP is the future for RIAs.
@Rhys Tague
Thanks for the comment. Our next post is on ActionScript and the following will be on MXML. Some of the language features that you've discussed in your comment will be addressed in those posts.
Flex is definitely designed to be used by people with various skills and background. Our series focuses on the knowledge essential to being a Flex developer, but it is fair to mention that the Flex Builder design mode as well as MXML are tools that make Flex accesible to designers as well as developers.
thanks again... keep reading!
-adam
For an answer book explaining OOP, check out "Head First Java". Although it focuses on the Java language, the majority of what you learn will be a huge help when coding AS3 (along with many other languages)
thank's for all insideRIA !
I'm kind of curious as to why a chair has any knowledge of something called a room. Also, shouldn't a Person object be tasked with moving "Movable" items. Not many clocks move themselves.
I understand you are trying to get across basic principles regarding OO. I just believe it can be done without including bad design practices in your examples (e.g. chair's "Stand up from Chair" method). I believe that's what a Person would do.
@phil
Thanks for the feedback.
So, as a caveat for this series, we've stated that this is a series focused towards beginners and written (partly) by a beginner. In a sense, of course you are correct, in the real world a chair really "does" nothing. We are anthropomorphizing a bit, however, there is relevance here. In the Flex Framework, as well as in almost every UI framework I've used, UI components "know" often about their parents and do, in fact, have methods that involve moving themselves.
This exercise all depends on the way you look at the abstraction. The question is how would the average non-programmer abstract the idea of a chair? In our example we're analogizing an object that invokes a method on an instance of Chair to the real world user of a chair. So, in this example I admit, the abstraction gets a bit fuzzy, but I think it's just that, fuzzy abstraction, not necessarily bad design patterns. After all, this example is not about how to program, how to design software, or even elegant OO Theory, it's to introduce a beginner having no conceptual knowledge of programming to what a Class and an Object are.
I would have to agree with you, in a "real" implementation a better design would be an approach where Room has a moveItem( item : IMovable ) method. Again, we were trying to talk more about what these objects "do". In the case of items in a room it's more accurate to say that "being moved" is a quality of these items and "moving" is not a behavior.
There are of course volumes of classic and current OO texts written, but most, it not all, of these texts are geared towards an audience ranging from a junior programmer to an experienced OO architect. When we set out to do the series we knew that reproducing something like that for Flex/ActionScript again would simply be regurgitation. That's where Scott comes in as a non-trained (academic or self) programmer. He's learning this stuff as we write about and on top of that learning how to talk about the way to learn it. This is not trivial task.
I'm glad you stopped by and thanks again for the feedback. In addition, it sounds like you already have a fairly advanced knowledge of the topic. So, as a fair warning, these posts might not be that interesting to you. I encourage anyone who finds it interesting to read the series, but at the same time realize that our target audience is those that have little or no programming experience. That's a pretty difficult audience to address as a programmer who's been in it for a while, so I'm glad to be co-writing with Scott and to have the opportunity to glean his perspective as a novice in this area.
This is as much a how-to series as it is a chronicle of Scott's findings while learning how to be a Flex developer. Unpacking knowledge that I have often taken for granted and translating has been a challenging and fun part of this process. It would have been much more difficult for me to write from this perspective on my own.
-adam
Thanks for the series.
As a designer learning to become a developer, I'm trying to get my head around the terminology.
I'm puzzled by these two sentences: "So, our Room object is composed of many other objects (Clock, Chair, Door, etc). The language used to describe these relationships is "Room has a Clock", because Clock is a property of Room."
It sounds like Clock is both an object in and of itself (perhaps a child object of Room??) and a property of Room.
Can something be an object and a property at the same time?
Thanks for any clarification you can offer.
@David
Sorry for the confusion. Let me see if I can express it a little clearer for you...
A Class is the description of an Object. A Class is typically written by the programmer before compile time. In the case of Flex we write ActionScript or MXML classes. An Object is said to be an "instantiation" or "instance" of a Class. Objects exist during runtime (while your application is running). A Class description includes the properties and methods that belong to that Class. At runtime the instantiated Object "has" these properties and methods. In most OO languages the properties of an Object are either a primitive value (like int, boolean, etc) or another Object.
So, in our example, both Room and Clock are types of Objects (or Classes). When instantiated there's a relationship between Room and Clock such that Room "has a" Clock. Meaning that one of the properties of Room is an Object of type Clock. This is a pretty simple relationship. It's known as a one-to-one, because for each one Room Object there is one Clock object. As you can see, this limits a Room to having just one Clock. If we wanted to make this more flexible we could say that Room "has a" set of Clocks. This would be known as a one-to-many relationship.
Object Oriented Design Patterns are almost entirely concerned with relationships like these simple examples all the way up to very complex relationships between Objects.
Hope that made things more clear and not less
-adam
Thanks, Adam. Yes, this is helpful.
I had been thinking of Properties as descriptive characteristics (such as height, width, color, etc.) - something to which a value can be given.
Your point that "one of the properties of Room is an Object of type Clock" - because of the relationship between them - is helpful.
So, to extend the example, if Clock were in BellTower instead of in Room, Clock would still be an Object but not a property of Room because there would be no relationship to Room. Clock would be an Object and a property of BellTower.
And Clock's Properties could include HourHand, MinuteHand, and SecondHand, all of which could be Objects of the Class Hand.
Am I on the right track? I don't mean to belabor the point or the example; just want to make sure I'm getting it.
Thanks.
@David
Exactly! You got it man. If you think about it... an Object as the value of a property is the same idea like saying "height=43", it's just that instead of your property being set to some primitive value it's value is a reference to an Object that is in memory. If you looked under the hood of our example, into whatever environment this code might run in, you'd see that the property "Clock" of "Room" is actually just a big long int value. That int value is the reference to a point in memory where the instance of Room's Clock object 'lives'. So it's really just associates built on top of associations in the end.
-adam
Hey Adam,
Terrific, thanks!
It's good to get to the "ah ha!" stage!
I appreciate the conversation.
David
I agree with the people who are experiencing confusion regarding the use of real-world objects in explanations of OOPS. I was actually seriously put off Java after scratching my head trying to understand how OOPS was a great way of programming things like dogs and bicycles, using arguments like "Dogs have state and behaviour" (referring to fields and methods). I struggled with this because to my mind the state and behaviour of a dog are not separable things. My supposition in the end was that this analogy provides a gross overestimate of the use of OOPS, which is not a good way of describing real things, it is actually a modern way of organising digital computer programs.
I also felt, being a programmer of the old school, that I couldn't quite see the gap between OOPS and procedural programming as it's pretty usual to organise procedural programs into named modules which combine program code and variable data into discrete units.
When I were a student in university I hated Object Oriented Language very much but after I graduated and join the word's market I love understood its' and love it very much.
Phan mem ke toan
An excellent article indeed!
I understood all the OOP concepts really well except 'encapsulation'.
This aspect of object-oriented programming provides protection for a class so that objects that aren't relevant to the class can't access its resources. In the above example, a chair cannot be open or closed because that's not part of "chair behavior".
Are these 2 sentences related? Even when the class Room is related to Chair, a room can't open or close a chair.
Thanks in advance.