WASM Phorum :: ООП и асм

Умею делать проги и с помощью MFC и на С++. MFC это ИМХО лучшше что было придумано,отлично продуманная система,Борланд - фигня. Но проги с MFC в раз 5 тормознутей (про .NET не может быть и речи - мегатормоз). Я разрабатываю проги для 386-486 компов поэтому и перешол с MFC\С++ на АСМ.

А это статья ер. "Зачем было придумано ООП":
(влом переводить.)

Data Is Undervalued

In a procedural language, the emphasis is on doing things—read the keyboard, invert the vector, check for errors, and so on. The subdivision of a program into functions continues this emphasis. Functions do things, just as single program statements do. What they do may be more complex or abstract, but the emphasis is still on the action.

What happens to the data in this paradigm? Data is, after all, the reason for a program’s existence. The important part of an inventory program isn’t a function that displays the data or a function that checks for correct input; it’s the inventory data itself. Yet data is given second-class status in the organization of procedural languages.

For example, in an inventory program, the data that makes up the inventory is probably read from a disk file into memory, where it is treated as a global variable. By global, I mean that the variables that constitute the data are declared outside of any function so they are accessible to all functions. These functions perform various operations on the data. They read it, analyze it, update it, rearrange it, display it, write it back to the disk, and so on.

I should note that most languages, such as Pascal and C, also support local variables, which are hidden within a single function. But local variables are not useful for important data that must be accessed by many different functions.

Suppose a new programmer is hired to write a function to analyze this inventory data in a certain way. Unfamiliar with the subtleties of the program, the programmer creates a function that accidentally corrupts the data. This is easy to do, because every function has complete access to the data. It’s like leaving your personal papers in the lobby of your apartment building: Anyone can change or destroy them. In the same way, global data can be corrupted by functions that have no business changing it.

Another problem is that, because many functions access the same data, the way the data is stored becomes critical. The arrangement of the data can’t be changed without modifying all the functions that access it. If you add new data items, for example, you’ll need to modify all the functions that access the data so that they can also access these new items. It will be hard to find all such functions and even harder to modify all of them correctly. It’s similar to what happens when your local supermarket moves the bread from aisle 4 to aisle 12. Everyone who patronizes the supermarket must figure out where the bread has gone and adjust their shopping habits accordingly.

What is needed is a way to restrict access to the data, to hide it from all but a few critical functions. This will protect the data, simplify maintenance, and offer other benefits, as you’ll see.

The Object-Oriented Approach

The fundamental idea behind object-oriented languages is to combine into a single program entity both data and the functions that operate on that data. Such an entity is called an object.

An object’s functions, called member functions in C++ (because they belong to a particular class of objects), typically provide the only way to access its data. If you want to read a data item in an object, you call a member function in the object. It will read the item and return the value to you. You can’t access the data directly. The data is hidden, so it is safe from accidental alteration. Data and its functions are said to be encapsulated into a single entity. Encapsulation and data hiding are key terms in the description of object-oriented languages.

If you want to modify the data in an object, you know exactly what functions interact with it: the member functions in the object. No other functions can access the data. This simplifies writing, debugging, and maintaining the program.

A C++ program typically consists of a number of objects that communicate with each other by calling one another’s member functions. Figure 1-3 shows the organization of a C++ program.

Посл.отвђт	Сообщенiе
infern0 Воин дзена	Дата: Сен 21, 2004 11:48:04 „важно решить конкретную задачу“ добавлю - в максимально сжатый срок. И это действительно _работает_ несмотря на все недостатки. А будет код 3кб или 300кб - мне лично пофигу.
n0p [ HI-TECH ]	Дата: Сен 21, 2004 21:15:04 Ладно, этот спор бесконечен.. Лично мне в программе важна красота и элегантность, а не сроки. Если заказчик не удовлетворен сроками - надо его уломать. Если он не уламывается, то пусть ищет идиотов в другом месте, я не подпишусь. Это ИМХО. Оспорить не удастся, многие пробовали.
Quantum Паладин дзена	Дата: Сен 21, 2004 23:44:39 „добавлю - в максимально сжатый срок“ добавлю - такие ребята обычно юзают RUP с жёстким time boxing'ом. Тут даже не в OOP дело.
zzzyab Воин дзена	Дата: Сен 22, 2004 03:14:57 Умею делать проги и с помощью MFC и на С++. MFC это ИМХО лучшше что было придумано,отлично продуманная система,Борланд - фигня. Но проги с MFC в раз 5 тормознутей (про .NET не может быть и речи - мегатормоз). Я разрабатываю проги для 386-486 компов поэтому и перешол с MFC\С++ на АСМ. А это статья ер. "Зачем было придумано ООП": (влом переводить.) Data Is Undervalued In a procedural language, the emphasis is on doing things—read the keyboard, invert the vector, check for errors, and so on. The subdivision of a program into functions continues this emphasis. Functions do things, just as single program statements do. What they do may be more complex or abstract, but the emphasis is still on the action. What happens to the data in this paradigm? Data is, after all, the reason for a program’s existence. The important part of an inventory program isn’t a function that displays the data or a function that checks for correct input; it’s the inventory data itself. Yet data is given second-class status in the organization of procedural languages. For example, in an inventory program, the data that makes up the inventory is probably read from a disk file into memory, where it is treated as a global variable. By global, I mean that the variables that constitute the data are declared outside of any function so they are accessible to all functions. These functions perform various operations on the data. They read it, analyze it, update it, rearrange it, display it, write it back to the disk, and so on. I should note that most languages, such as Pascal and C, also support local variables, which are hidden within a single function. But local variables are not useful for important data that must be accessed by many different functions. Suppose a new programmer is hired to write a function to analyze this inventory data in a certain way. Unfamiliar with the subtleties of the program, the programmer creates a function that accidentally corrupts the data. This is easy to do, because every function has complete access to the data. It’s like leaving your personal papers in the lobby of your apartment building: Anyone can change or destroy them. In the same way, global data can be corrupted by functions that have no business changing it. Another problem is that, because many functions access the same data, the way the data is stored becomes critical. The arrangement of the data can’t be changed without modifying all the functions that access it. If you add new data items, for example, you’ll need to modify all the functions that access the data so that they can also access these new items. It will be hard to find all such functions and even harder to modify all of them correctly. It’s similar to what happens when your local supermarket moves the bread from aisle 4 to aisle 12. Everyone who patronizes the supermarket must figure out where the bread has gone and adjust their shopping habits accordingly. What is needed is a way to restrict access to the data, to hide it from all but a few critical functions. This will protect the data, simplify maintenance, and offer other benefits, as you’ll see. The Object-Oriented Approach The fundamental idea behind object-oriented languages is to combine into a single program entity both data and the functions that operate on that data. Such an entity is called an object. An object’s functions, called member functions in C++ (because they belong to a particular class of objects), typically provide the only way to access its data. If you want to read a data item in an object, you call a member function in the object. It will read the item and return the value to you. You can’t access the data directly. The data is hidden, so it is safe from accidental alteration. Data and its functions are said to be encapsulated into a single entity. Encapsulation and data hiding are key terms in the description of object-oriented languages. If you want to modify the data in an object, you know exactly what functions interact with it: the member functions in the object. No other functions can access the data. This simplifies writing, debugging, and maintaining the program. A C++ program typically consists of a number of objects that communicate with each other by calling one another’s member functions. Figure 1-3 shows the organization of a C++ program.