为何面向对象优于结构化?

Object-Oriented really is better than Structured

By Gary Warren King


Everyone talks about it but no one defines it

'Object-oriented' has clearly become the buzzword of choice in the industry. Almost everyone talks about it; Almost everyone claims to be doing it (or using it); and almost everyone says its better than sliced bread. But very few people seem to spend much time justifying it. This unexamined exploitation of the term does a great disservice to the Object-oriented method. Objects may be the best way devised so far to cut through the miasma of complexity found in large, real-world software systems. But as long as vendors and marketers are allowed to misuse and mangle the concept beyond recognition (and claim benefits that it will never be able to realize), Object-Orientation will be unable to fulfill its true promise. In order to use the tool wisely, we need to examine closely what Object-Orientation is about and discover whether or not it can live up to the claims of its proponents. Does Object-Orientation really produce better software than more traditional structured techniques?

I'd like to take a step back from the day in and day out tasks of software construction and think about what it is we are doing. What, in its barest form, is software construction? What are we doing when we sit down to design a new system or program a new feature into an existing one? Only after we have placed our activity in a framework of this sort can we evaluate the tools and methods that we use and decide how we can do better. If our goal is to produce better systems in a shorter time, then finding tools that support this goal ought to be one of our chief concerns. It's possible (and I believe it to be the case) that Object-Oriented methods and techniques are, for the moment, the tool for which we have been looking.

What is Software?

What is computer programming? Niklas Wirth sums it up eloquently in the title of his book: Algorithms + Data = Programs. To put it another way, "A Software system is a set of mechanisms for performing certain actions on certain data."

This means that there are two orthogonal (yet complementary) ways to view software construction: we can focus primarily on the functions or primarily on the data. The heart of the distinction between traditional structured design methodologies and newer object-oriented methodologies lies in their primary focus: Structured Design techniques center on the functions of the system: "What is it doing"; Object-oriented techniques center on the data (objects) of the system: "What is being done to". As we will see, this seemingly simple shift in focus radically changes the process of software design, analysis and construction. Object-Orientation really can provide tools to produce software of higher quality.

What is Quality software?

Software engineering is primarily about finding ways to produce quality software. What do we mean when we speak of "quality" in software? Quality in software can be measured in external characteristics (e.g. easy to use, runs fast) or internal characteristics (e.g. modular design, readable code). The external metrics are the only ones that really matter in the end. No one really cares if you used a good modular design to construct your software, they just care that it runs well. However, since the internal (hidden) metrics are key to producing the external ones, both must be taken into account during the course of software design and construction. Table 1 is a list of the more common external factors found in quality software. More details on some of these will be provided below.

Factor Meaning
Correct Does the right thing on normal data
Robust Fails "gracefully"
Extendible Can adapt easily to changing requirements
Reusable Can be used in systems other than the one for which was created
Compatible Can be used easily with other software
Efficient In time, computer memory, disk storage, etc…
Portable Can be transferred easily to other hardware and software environments
Verifiable Easy to test, easy to design test cases for, Easy to detect when (and where) the software failed, etc…
Maintains Integrity Protects itself from abuse and misuse
Easy to use For the user and for the future programmers

Table 1: Characteristics of Quality Software

Correctness and Robustness

It is easy to confuse Correct software and Robust software. Correct software works properly when fed normal inputs. It meets all of the requirements in its specification and does not fail within the range for which it was designed. Software robustness implies correctness and more. Robust software is able to handle circumstances outside of its design. These circumstances include inappropriate user input, hardware failure and run-time errors. Robust systems fail gracefully, without the lost of critical data. It is easy to see that both characteristics are necessary for any system to be judged high-quality software. If a system is not correct, then it is not useful. If a system is not robust, then it will be fragile and unable to cope with real-world situations.

Extendibility

Requirements change. This is one of the indisputable facts of software engineering. High quality software is able to deal with changes relatively painlessly. This sort of adaptability is not an issue for small projects but becomes crucial when programming-in-the-large. The two main principles of creating extendible software are:

  • Design Simplicity: A simpler design and architecture lends itself to change much more readily than a complex one.
  • Decentralization: Breaking up complex problems into small, manageable and independent chunks means tha
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值