SoFunction
Updated on 2025-04-14

Understanding Programming Work in Flash Page 2/4


18.2 Important Concepts in Object-Oriented Software Development

In Chapter 4, I have briefly introduced what object-oriented software development is. You should still remember the example of "people" as the object, and when an incident occurs when an evil dog is chased by an evil dog, he can call the "showing away" method as a response to this event.
 
But no matter what, I don't want you to underestimate object-oriented software development because of these examples. In fact, object-oriented has a profound meaning and involves many important concepts. Only by fully understanding the meaning of these concepts can you truly understand what object-oriented is. You should know many concepts, but due to space, I will explain the nine most important ones in this section.
There are nine most basic concepts in object-oriented software development: classes, objects, properties, methods, abstraction, encapsulation, inheritance, polymorphism, and events.

18.2.1 Classes and Objects

Classes are software abstractions of objects and templates for creating objects. For example, if a person is regarded as an object, the species of human can be regarded as a class. Class definitions describe structures including data and functions, and objects are created by them. A class represents a set of similar objects. An object is an instance of a class.

Why do we need classes? Imagine a situation where if we want to write a Flash game, there are some villains who can move independently, and these villains have the same physical characteristics and mobility abilities, then if we want to write programs for each villain, the workload will undoubtedly be huge and repetitive. In this case, we should create a "villain" class, and in the future, we should generate a villain from the "villain" class whenever a new villain is needed.

Having said that, you must have thought of the relationship between components and instances. Yes, the relationship between classes and objects is the same as the relationship between components and instances, because components are actually built-in classes for Flash.

18.2.2 Attributes and methods

Attributes are data, and methods are functions. Attributes are things that classes know, while methods are things that classes complete. Attributes and methods are the responsibilities of the class. Object-oriented software development is based on the concept that systems should be created by objects, and objects have data and functions. Attributes define data, while methods define functions.

Obviously, in object-oriented development, the most important task is to define classes. When defining a class, it must define its properties and methods. The definition of a property should be straightforward and clear, and its name and data type need to be defined. The definition of a method is the process of creating a function. As needed, you can create a method that can accept parameters and return values.

18.2.3 Abstract

The world is very complex. In order to deal with its complexity, in software design, when it is necessary to generalize or abstract things when it is necessary to build mathematical models of things. It is still about taking people as the object. From the perspective of recruitment, we need to know the person’s name, gender, age, educational background, work experience, contact information, and personality characteristics; from the perspective of blind date, we need to know the person’s age, height, appearance, educational background, family background, and even the birth date. It’s still the same person, just to abstract him (or her), and the abstraction of a thing will depend on the program you want to design.

Abstraction is a process of analysis, a process of drawing a clear framework around things. Abstraction should include functions, properties, and methods that are of interest to the application, and ignore other factors. This is why the abstraction of recruitment includes educational background and work experience, but does not include birth dates and eight characters. The abstract process is the process of defining what the class knows and wants to accomplish.

18.2.4 Packaging

Although the abstraction tells us that for recruitment, we should store the candidate’s educational background and work experience, it does not tell us how to accomplish these things. Packaging solves the problem of how to model system functions. In an object-oriented world, we need to model systems into classes, and classes must also be modeled as properties and methods. The process of how the design class will accomplish these things is called encapsulation.

Encapsulation describes the problem of how to divide functions in the system. We don't need to know how the object is implemented inside. Encapsulation implies that we can build the system in any way, and if necessary, we can also modify its internal structure again in the future. As long as the interface between different functional components in the system does not change, the change to one functional part of the system will not affect other functional parts of the system.

Encapsulation is the process of blackening the frame around things. You can define anything you want to define, but you don't need to inform the outside world what you do. For example, when you deposit and withdraw cash from the bank, you don’t need to know how the bank’s data center uses mainframes, minicomputers and PCs to record your account information. It doesn’t matter what kind of databases and operating systems they use, because they have encapsulated the functions of account services. You just need to walk to the counter and hand the passbook to the bank staff. By hiding the details of realizing account functions, banks can freely change their functions at any time without having to worry about changing every user's passbook.

In order to make applications easy to maintain and increase security and robustness, access to classes' properties and methods needs to be restricted. The basic idea is as follows: If a class wants to obtain information from another class, it must first obtain consent, rather than just use it. Consider that in the real world, it actually works in this way. If you want to know other people's names, what should you do? Should I ask the person directly about his name, or should I steal his wallet and see his ID card?

18.2.5 Inheritance

There are often similarities between different classes. More than two classes will also often share the same properties and/or the same methods. Because we don't want to write code repeatedly, we have to use this similar mechanism. Inheritance is this mechanism, which allows you to easily reuse existing data and code.

For example, students have names, addresses, and mobile phones, and they can run quickly. At the same time, teachers have these things. There is no doubt that we can develop classes about students and teachers and let them run together. In fact, you only need to develop the Student class first. Once it runs, make a copy, it is called the Teacher class, and make some appropriate modifications to it. This is easy, but not perfect. What happens if the source code in the Student class errors? You will have to correct your mistakes in two places. This would be a boring job. Wouldn't it be better if there was only one copy of the code for development and maintenance?

This is the idea of ​​inheritance. Using inheritance, you can define a class to encapsulate similarities between students and teachers. The new class will have attribute name, address, mobileTelephone, and method run. We can name this class Person.

Once the Person class is defined, the Student and Teacher classes can be inherited from it. We call Person a superclass of Student and Teacher classes, while Student and Teacher classes are subclasses of Person classes. Anything that superclasses know and accomplish, subclasses know. Therefore, since the Person class can run away when encountering a vicious dog, the Student and Teacher classes can do it too.

18.2.6 Polymorphism

Let's consider this example. You love your girlfriend very much, you say "Dear, I love you", your girlfriend hugged you enthusiastically, and you also got a kiss, you thought it was very good. Then, you come to the street and see a very elegant beauty. You also say to the beauty by saying hello to your girlfriend, "Dear, I love you", and you will immediately get some advice on your nerves and morality. Then, you came to the hospital and said to an old Chinese doctor, "Dear, I love you." The old Chinese doctor will pull your wrist without hesitation and start taking your pulse. You think that whenever I encounter these objects and say, "Dear, I love you" this will certainly happen - this is polymorphism.

Polymorphism allows objects to collaborate with other objects without knowing the type of other objects in advance.
You can learn a few interesting experiences from this experience:

First, polymorphism hinders your interactions with other objects. You don't distinguish the types of other objects, you treat them the same way. Your idea is that other objects are humans. Polymorphism is a concept that allows this to happen.

Second, different objects respond differently in their own way. Your girlfriend hugs you and kisses you; a strange beauty gives you advice on nerves and morality; and the old Chinese doctor takes your pulse. The same message arrives at different objects, and each accomplished thing is different. In fact, from the perspective of each object, they did what they should do.

Third, polymorphism can achieve consistent and appropriate method names. Although each object responds to "Dear, I love you" in an appropriate way, different versions of the method are to be implemented.

Polymorphism mainly includes two aspects:
Overloading of operators: The same operator can be used on multiple object types.
Function name overload: The same function name can be applied to different object types and produce different effects.

18.2.7 Event

The operation of object-oriented software is carried out with events occurring, which is called "event-driven". For example, when you appreciate Flash animation, there are actually "entry frames" events happening. In these events, Flash Player will present the content in each frame, so you can see the picture.

Similarly, when you click a button, a button event occurs, and the scripts in the button event are executed. The function of these scripts may be to take you to a specific scene, a specific frame, or to a URL.

In object-oriented programming, the entire software is event-driven, which means that if no event occurs, your program will be difficult to move forward. Fortunately, there are always some things in the program, and even if all other events do not occur, time will pass. This event will happen at all times.

In actual development in the later chapters of this book, you will see the practical application of all of these object-oriented concepts mentioned above.
Previous page1234Next pageRead the full text