多线程编程与面向对象技术探索

需积分: 10 58 浏览量更新于2024-07-27 收藏 469KB PDF 举报

"这篇文档可能源自一本关于NeXT开发者的图书馆，主要探讨了多线程编程和面向对象的编程概念，特别是与Objective-C语言相关的实践。文档内容可能涉及如何在Objective-C中实现多线程以及如何利用面向对象设计原则来构建高效、可维护的软件系统。" 在计算机科学中，多线程编程是并发处理任务的一种方式，允许一个程序同时执行多个任务或子任务。这可以提高系统的效率和响应性，特别是在现代多核处理器的环境下。在多线程环境中，每个线程都拥有独立的执行路径，它们可以共享数据和资源，但同时也要处理好同步和互斥问题，以防止数据竞争和死锁。 Objective-C是一种面向对象的编程语言，它是C语言的超集，增加了Smalltalk风格的消息传递机制。在Objective-C中，面向对象编程（OOP）的关键概念包括： 1. 类（Class）：定义了一组相关属性（实例变量）和行为（方法）的模板，可以创建多个该类的实例。 2. 对象（Object）：类的实例，具有特定的属性和行为。 3. 消息传递（Message Passing）：通过发送消息给对象来调用其方法，这种动态绑定的方式使得代码更加灵活。 4. 继承（Inheritance）：一个类可以继承另一个类的属性和方法，从而实现代码重用和扩展。 5. 多态（Polymorphism）：同一种消息可以被不同类的对象响应，允许编写更抽象和通用的代码。 6. 封装（Encapsulation）：通过将数据和操作这些数据的方法打包在一个类中，实现数据的安全性和隐藏内部实现细节。在多线程编程中，Objective-C提供了NSThread、NSOperation和GCD（Grand Central Dispatch）等工具来管理线程。例如，NSThread可以方便地创建和控制线程，而GCD则提供了一种更高级的并发编程模型，它基于队列和块，能够自动调度工作在合适的线程上。在文档中，开发者可能还会讨论如何使用锁（Locks）、条件变量（Condition Variables）、信号量（Semaphores）以及互斥量（Mutexes）来保证线程安全，或者如何利用NSOperationQueue和NSLocking协议来实现线程间的协调和同步。最后，文档中提到了关于政府使用权限的法律条款，表明此技术资料可能受到特定的法规限制，如DFARS252.227-7013等，这些条款通常涉及到非商业用途的技术数据和软件的使用、复制和披露。这个文档旨在帮助开发者理解如何在Objective-C中有效地进行多线程编程，并利用面向对象的特性来构建健壮的多线程应用。

Programming languages have traditionally divided the world into two parts—

data and operations on data. Data is static and immutable, except as the

operations may change it. The procedures and functions that operate on data

have no lasting state of their own; they’re useful only in their ability to affect

data.

This division is, of course, grounded in the way computers work, so it’s not one

that you can easily ignore or push aside. Like the equally pervasive distinctions

between matter and energy and between nouns and verbs, it forms the

background against which we work. At some point, all programmers—even

object-oriented programmers—must lay out the data structures that their

programs will use and deﬁne the functions that will act on the data.

With a procedural programming language like C, that’s about all there is to it.

The language may offer various kinds of support for organizing data and

functions, but it won’t divide the world any differently. Functions and data

structures are the basic elements of design.

Object-oriented programming doesn’t so much dispute this view of the world as

restructure it at a higher level. It groups operations and data into modular units

called objects and lets you combine objects into structured networks to form a

complete program. In an object-oriented programming language, objects and

object interactions are the basic elements of design.

Every object has both state (data) and behavior (operations on data). In that,

they’re not much different from ordinary physical objects. It’s easy to see how a

mechanical device, such as a pocket watch or a piano, embodies both state and

behavior. But almost anything that’s designed to do a job does too. Even simple

things with no moving parts such as an ordinary bottle combine state (how full

the bottle is, whether or not it’s open, how warm its contents are) with behavior

(the ability to dispense its contents at various ﬂow rates, to be opened or closed,

to withstand high or low temperatures).

It’s this resemblance to real things that gives objects much of their power and

appeal. They can not only model components of real systems, but equally as

well fulﬁll assigned roles as components in software systems.

Interface and Implementation

As humans, we’re constantly faced with myriad facts and impressions that we

must make sense of. To do so, we have to abstract underlying structure away

from surface details and discover the fundamental relations at work.

others, so a complex arrangement of information can be built from simpler

layers.

In modern C, the ﬁelds of a structure live in their own name space—that is,

their names won’t conﬂict with identically-named data elements outside the

structure. Partitioning the program name space is essential for keeping

implementation details out of the interface. Imagine, for example, the

enormous task of assigning a different name to every piece of data in a large

program and of making sure new names don’t conﬂict with old ones.

On the procedural side of the world, functions encapsulate behaviors that can

be used repeatedly without being reimplemented. Data elements local to a

function, like the ﬁelds within a structure, are protected within their own

name space. Functions can reference (call) other functions, so quite complex

behaviors can be built from smaller pieces.

Functions are reusable. Once deﬁned, they can be called any number of

times without again considering the implementation. The most generally

useful functions can be collected in libraries and reused in many different

applications. All the user needs is the function interface, not the source code.

However, unlike data elements, functions aren’t partitioned into separate

name spaces. Each function must have a unique name. Although the

function may be reusable, its name is not.

C structures and functions are able to express signiﬁcant abstractions, but they

maintain the distinction between data and operations on data. In a procedural

programming language, the highest units of abstraction still live on one side or

the other of the data-versus-operations divide. The programs you design must

always reﬂect, at the highest level, the way the computer works.

Object-oriented programming languages don’t lose any of the virtues of

structures and functions. But they go a step further and add a unit capable of

abstraction at a higher level, a unit that hides the interaction between a function

and its data.

Suppose, for example, that you have a group of functions that all act on a

particular data structure. You want to make those functions easier to use by, as

far as possible, taking the structure out of the interface. So you supply a few

additional functions to manage the data. All the work of manipulating the data

structure—allocating it, initializing it, getting information from it, modifying

values within it, keeping it up to date, and freeing it—is done through the

functions. All the user does is call the functions and pass the structure to them.

■

Chapter 1 Object-Oriented Programming

With these changes, the structure has become an opaque token that other

programmers never need to look inside. They can concentrate on what the

functions do, not how the data is organized. You’ve taken the ﬁrst step toward

creating an object.

The next step is to give this idea support in the programming language and

completely hide the data structure so that it doesn’t even have to be passed

between the functions. The data becomes an internal implementation detail; all

that’s exported to users is a functional interface. Because objects completely

encapsulate their data (hide it), users can think of them solely in terms of their

behavior.

With this step, the interface to the functions has become much simpler. Callers

don’t need to know how they’re implemented (what data they use). It’s fair now

to call this an “object.”

The hidden data structure unites all of the functions that share it. So an object

is more than a collection of random functions; it’s a bundle of related behaviors

that are supported by shared data. To use a function that belongs to an object,

you ﬁrst create the object (thus giving it its internal data structure), then tell the

object which function it should invoke. You begin to think in terms of what the

object does, rather than in terms of the individual functions.

This progression from thinking about functions and data structures to thinking

about object behaviors is the essence of object-oriented programming. It may

seem unfamiliar at ﬁrst, but as you gain experience with object-oriented

programming, you’ll ﬁnd it’s a more natural way to think about things. Everyday

programming terminology is replete with analogies to real-world objects of

various kinds—lists, containers, tables, controllers, even managers.

Implementing such things as programming objects merely extends the analogy

in a natural way.

A programming language can be judged by the kinds of abstractions that it

enables you to encode. You shouldn’t be distracted by extraneous matters or

forced to express yourself using a vocabulary that doesn’t match the reality

you’re trying to capture.

If, for example, you must always tend to the business of keeping the right data

matched with the right procedure, you’re forced at all times to be aware of the

entire program at a low level of implementation. While you might still invent

programs at a high level of abstraction, the path from imagination to

implementation can become quite tenuous—and more and more difﬁcult as

programs become bigger and more complicated.

剩余177页未读，继续阅读

雨落``惊风

粉丝: 3
资源: 50

多线程编程与面向对象技术探索

C++面向对象多线程编程

c++高级编程 C++面向对象多线程编程

C++面向对象多线程编程1pdf

面向对象程序设计多线程

武汉理工大学-java面向对象与多线程综合实验csdn

武汉理工大学面向对象与多线程

java面向对象与多线程综合实验

第1章 认识java语言 第2章 java语言基础 第3章 面向对象程序设计之一 第4章 面向对象程序设计之二 第5章 java基础类库 第6章 图形用户界面程序 第7章 输入输出流 第8章 多线程并发编程 第9章 网络编程 第10章 数据库编程

java面向对象多线程头哥

武汉理工大学面向对象多线程实验

最新资源

第1章认识java语言第2章 java语言基础第3章面向对象程序设计之一第4章面向对象程序设计之二第5章 java基础类库第6章图形用户界面程序第7章输入输出流第8章多线程并发编程第9章网络编程第10章数据库编程