Delphi编程进阶指南：Nick Hodges教你编写高质量代码

需积分: 10 87 浏览量更新于2024-07-17 收藏 14.64MB PDF 举报

《More Coding in Delphi》是由Nick Hodges编著的一本专业书籍，该书的ISBN号码是978-1-941266-06-9，版权归属Nepeta Enterprises，出版时间跨度为2014年至2015年。这本书旨在帮助Delphi开发者提升编码技巧和理解现代编程原则。作者鼓励读者在Twitter上使用#morecodingindelphi这一标签来分享和讨论书中的内容，以促进知识的传播。书籍分为几个部分： 1. **序言**：这部分可能会介绍作者的意图，以及为何编写这本书，可能会提到Delphi语言的历史背景及其在当今开发环境中的重要性。 2. **致谢**：列出对支持本书创作的人或机构的感谢，可能包括技术支持、审阅者或其他贡献者。 3. **框架与工具**： - **Spring for Delphi Framework**：这可能是书中推荐的一个用于Delphi开发的框架，它可能提供了模块化、依赖注入等高级特性。 - **DuckDuckDelphi**：这个名字可能是另一个工具或设计模式集锦，强调了灵活性和代码复用。 4. **六点思考**：每章开头的六点思考涵盖了软件设计的关键原则，如封装、耦合、内聚、命令查询原则、Postel's Law（网络编程的艺术）和组合优于继承。这些原则是面向对象编程和SOLID原则的基础。 5. **编写SOLID代码**：这部分深入讲解了SOLID原则，包括单一职责原则（SRP）、开闭原则、里氏替换原则（LSP）、接口隔离原则（ISP）和依赖倒置原则（DIP）。这些原则旨在提高代码的可维护性和扩展性。 6. **设计模式**：书籍还包含对工厂模式的探讨，这是一种创建对象实例的常见设计模式，能够提供灵活的创建机制，避免硬编码依赖。通过阅读《More Coding in Delphi》，读者可以期待学习到Delphi编程的最佳实践，提升编码技巧，并理解如何应用设计原则和模式来构建高质量、易于维护的软件系统。这本书不仅适合现有Delphi开发者深化技能，也对初学者是个有价值的指导资源。

Six Thoughts Before We Start 4

function GetListOfWidgets: TWidgetCollection;

begin

if Widgets.Count = 0 then

begin

Result := nil

end else

begin

Result := Widgets; // Of type TWidgetCollection

end;

This function could return nil. Therefore, any code that consumes GetListOfWidgets had to check for nil

every time. This can be tedious. Rather than returning nil, the code should instead return an empty list to

indicate that there are no widgets in the collection.

A class should never be allowed to present itself to the consumer as nil. Normally, this means you should

create your internal objects in the constructor of the containing class and never free them until the destructor

is called. If you have some need to “reset” your class during its lifetime, then have a routine that does that

explicitly. Always protect your internal classes so that a consumer can never see a bad state – especially nil.

Dependency Injection

But what about the case of Dependency Injection? In Coding in Delphi, I strongly encouraged you to ask for

your dependencies rather than create them. If a reference should ever be nil, then you need to be very careful

about what you accept from external sources. Consider the following class interface:

type

TWidgetProcessor = class

private

FWidgetVerifier: TWidgetVerifier;

public

constructor Create(aWidgetVerifier: TWidgetVerifier);

end;

What should the constructor look like? You may be tempted to make it look like the following:

constructor TWidgetProcessor.Create(aWidgetVerifier: TWidgetVerifier);

begin

inherited Create;

FWidgetVerifier := aWidgetVerifier;

end;

That looks great, right? But what happens if the user passes in a nil reference? Well, you’ll end up with a

nil reference as an internal and that’s not good. Instead, you need to protect your internals from ever being

nil:

Six Thoughts Before We Start 5

constructor TWidgetProcessor.Create(aWidgetVerifier: TWidgetVerifier);

begin

if aWidgetVerifier = nil then

begin

raise ENilParameterException.Create('Cannot pass a nil parameter');

end;

inherited Create;

FWidgetVerifier := aWidgetVerifier;

end;

This is called the “Guard Pattern,” and the notion is pretty simple: you “guard” against bad data trying to

infect your internals. You “Fail Fast” in ensuring – right at the point of entry – that your internals can never

be nil. The Spring for Delphi Framework has a class called Guard in the Spring.pas unit that performs this

protection for you in one line of code. Here’s an example:

constructor TWidgetProcessor.Create(aWidgetVerifier: TWidgetVerifier);

begin

Guard.CheckNotNull(aWidgetVerifier, 'aWidgetVerifier');

inherited Create;

FWidgetVerifier := aWidgetVerifier;

end;

The Guard class has a number of class procedures that allow you to verify input in any number of ways,

ranging from nil checking to making sure strings aren’t empty and that any Boolean condition is either True

or False. Note that the check in the example is done even before the call to inherited. If the condition is

not properly met, the framework will raise an EArgumentException, using the second parameter as part of

the error message to tell you which parameter was not valid. The first parameter is obviously the item to be

validated.

Whether you choose to use the Guard class or write your own Guard code, it is imperative for proper

encapsulation that you use a guard clause to protect your internal classes and other references from ever

becoming nil or any other state where they are anything less than usable. Part of the contract you make

when you provide a class interface is that the class will always work, and if you allow your class to get itself

into an unusable state, then you are breaking the contract you have with the consumer of your code.

Thus, encapsulation becomes a touch more important than mere “information hiding,” eh?

Thoughts on Coupling

In Coding in Delphi I talked a lot about coupling, but I feel like I assumed that you knew what it meant. I’m

guessing most of you do, but I thought I’d talk about it a bit here in more detail.

Coupling is the measure of how dependent your code modules are on each other. Strong coupling is bad and

weak coupling is good. Strong coupling means that your modules cannot be easily separated from each other,

due to the fact that the internals are mixed and intertwined. When your system is strongly coupled, it is said

to be “spaghetti” code, as everything is all mixed up together like a bowl of spaghetti noodles.

Strong coupling often means that a change in one place can have unforeseen effects in unknown other places.

It means that your code is harder to understand because complex, intertwined relationships are difficult to

Six Thoughts Before We Start 6

understand. Strongly coupled code is difficult to reuse because it is difficult to extract it for use elsewhere

due to of all the intertwined dependencies. One should strive to reduce coupling in one’s code to as much as

possible.

Of course, your code can’t be completely decoupled. A collection of completely decoupled modules can’t do

anything. They need to be coupled in a thin and light manner. I’ve said before that an interface is like a wisp

of smoke – there is something there, but it is really hard to grab onto it. Code that is coupled via interfaces is

coupled as thinly as it can possibly be coupled in Delphi.

A real world example of heavy coupling is the Space Shuttle. Now I’m no rocket scientist, but my guess

is that the Space Shuttle is made up of hundreds of thousands – if not millions – of unique parts that fit

together in one way and one way only. The parts are not generally reusable, and if you need to alter one part

– especially if you have to alter the interface of a part – you have a problem because the other parts around it

will probably need to be altered as well. This initial alteration could spread a long way throughout the craft

and have far-reaching ramifications. The Space Shuttle, then, is a highly coupled system with high cohesion.

What’s an example of loose coupling? How about a Space Shuttle built out of Legos. Sure, it won’t go

anywhere, but it would be easy to change its design as Lego pieces are easily put together and taken apart to

make whatever you want. A Lego Space Shuttle would have low coupling.

Most of what I wrote about in my previous book and much of what I’m writing about in this book will be

about reducing the coupling of your code.

In summary, uncoupled code will be:

1. Easier to read because it will be simple and not complex.

2. Reusable because it will be connected only by very thin interfaces

3. Easy to change and maintain because changes to the code will be isolated.

Thoughts on Cohesion

Well designed code will have good cohesion, but I really didn’t mention this facet of developing clean code

in my previous book. I thought it would be a good topic to cover here.

What is cohesion? Wikipedia defines it as the “degree to which the elements of a module belong together⁹”

High cohesion is considered a good thing. That is, it is a good design to have your classes work well together

to form a whole.

An example of good cohesion is an electric drill. It is made of a motor, a power supply, a casing, a trigger, a

holder for drill bits, as well as the drill bits themselves. These separate components –- as different as they are

individually –- all work together to create something useful.

The same is true for your code: if your classes can be easily combined together to create something useful,

then that code is said to be cohesive. There’s one catch, though: as we saw in the previous section, you don’t

want to achieve cohesion at the expense of coupling. A properly designed system has good cohesion and is

loosely coupled.

⁹http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

Six Thoughts Before We Start 7

Think about your drill. I bet a well designed drill can be easily taken apart using the proper screwdriver.

The motor can be removed from the casing, the electrical system easily fixed or replaced, the drill bit holder

removed and repaired, and then the entire drill put back together again. This happens because the drill is both

loosely coupled together – each part is replaceable – and has high cohesion among its component parts.

Your code should be the same way: as was said above, it should be loosely but properly coupled. The modules

you build should be able to be composed together to form something useful, but in a way that makes the

system’s decomposition relatively easy. If you realize that a piece of your system is useful for another project,

you want to be able to easily reuse that module elsewhere without baggage from the current project. This is

what good coupling is about: easily fitting together modules that were not originally intended to do so.

As mentioned above, Legos show high cohesion. They can easily be pieced together to create almost anything

you can imagine. Even Duplo blocks have an interface to regular Legos that makes them very cohesive and

easy to combine. Legos can be taken apart very easily. They can be put together very easily. There is a reason

why they are the one of the most popular toys on the planet. Legos exhibit low coupling and high cohesion –

the main reason that they are so popular.

Your code should be like Lego blocks – easy to combine to create useful things.

Thoughts on Command Query Principle

In keeping with our previous discussion on encapsulation, let’s look at the notion of separating “commands”

and “queries” by using the Command/Query Principle. The notion was first discussed by Bertrand Meyer in

his book Object Oriented Software Construction¹⁰. This means that the idea is not new. In its basic form, it

means we should separate the things that read data from the system and the things that write data to the

system.

The Command/Query Principle states that there should be a clear separation between the updating of

information and status in your program and the way that you read information from it. Commands and

queries should be separately declared (though you’ll find that commands can call queries but not vice-versa).

It can be as complex as ensuring that reading and writing take place in completely separate classes, or as

simple as ensuring that commands and queries are put in different methods of your classes.

Of course, the first question you’ll have is “What do you mean by ‘command’ and ‘query’?” Well, I’ll tell you.

Queries

A query is an operation that returns a result without changing the state of the class or the application. In

Object Pascal, this is typically a function. As a general rule, queries should not change the state of a class. They

should be “idempotent,” meaning “denoting an element of a set that is unchanged in value when multiplied

or otherwise operated on by itself.” (I had to look that up, by the way….)

Queries should exhibit two main behaviors: they should return a single value and “asking a question should

not change the answer.” They should be referentially transparent, which means that they should be perfectly

replaceable with their literal result without changing the meaning of the system.

¹⁰http://www.amazon.com/gp/product/0136291554/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0136291554&linkCode=

as2&tag=nickhodgeshomepa&linkId=IVMYKYZ22AWZJ2LQ

Six Thoughts Before We Start 8

Your functions shouldn’t change the status of the system you are working on, whether that be a class, a

framework, or an application. You should be able to run a query, i.e. a function, a hundred times in a row and

get the same answer back each time when the input is the same. This makes calling a function at any time

possible without repercussions, because it doesn’t change the status of the system.

Commands

A command is any operation that has an observable side effect. It is any code that changes something in

your class or application. Typically, in Object Pascal a command will be a procedure – that is, code that takes

actions without returning a value. Commands can call queries (but queries should never call commands,

because commands change the status of the system).

Commands should not in general return values. Thus, the use of var parameters should be discouraged, if

not outright banned.

Don’t Mix the Two

As a general rule, all your methods and routines should be easily identifiable as either a command or a query.

Commands and queries should be separate entities in your code – with the exception that a command can

call a query if need be. A query can’t call a command, because commands change the system, and that should

really not be allowed.

The use of var or out parameters in a procedure will confuse this issue and thus should be discouraged.

Following the above rules, you should more easily be able to understand and modify your code.

The Command/Query Principle also encourages you not to violate what I consider to be a bedrock of sound

development technique: don’t try to make one thing do two things. Here is some code that does exactly that:

procedure ProcessWidgets(aCollectionOfWidgets: TWidgetCollection; out aNumberOfProcessedWidgets: integer);

This method is a clear violation of CQP as it obviously is trying to be a command and alter the state of the

system by processing widgets, but it also tries to be a query by returning, through an out parameter, the

number of processed widgets.

Instead, the system should have a simple command to process widgets and a separate query to return the

number of widgets that were processed. The procedure is trying to be two things at once, and all kinds of

mischief comes from making one thing do two things.

For instance, instead, the code should probably look something like this:

procedure ProcessWidgets(aCollectionOfWidgets: TWidgetCollection);

function CurrentProcessedWidgetCount: integer;

In this way, you can process widgets all that you want, and any time you want, you can check the state of

processed widgets. But you don’t do both in one statement, which would be a violation of the admonition to

have one thing do one thing.

Following the CQP in the design of your code will help to ensure the proper separation of concerns, resulting

in cleaner, easier to read and easier to maintain code.

剩余230页未读，继续阅读

chunyangsuhao

粉丝: 102
资源: 7382

Delphi编程进阶指南：Nick Hodges教你编写高质量代码

Nick Hodges - Coding in Delphi.pdf

More Coding In Delphi.pdf

Dependency Injection in Delphi.Nick Hodges.pdf

select file: chunked-coding-converter.0.2.1.jar

zet中兴-verilog_coding_style.pdf

读取process.bmp或者process.raw，产生1组二进制序列（长度为16），通过‘异或’操作，完成图像的编码，另存为coding.bmp或者coding.raw；

读取 coding.bmp 或者 coding.raw，利用之前的 1 组二进制序列（长度为 16），通过‘异或’操作，完成图像的解码

Coding me scipy.spatial.Delaunay create mesh

读取coding.bmp或者coding.raw，利用之前(1)的1组二进制序列（长度为16），通过‘异或’操作，完成图像的解码，另存为decoding.bmp或者decoding.raw；

Traceback (most recent call last): File "/data/user/0/coding.yu.pythoncompiler.new/files/default.py", line 12, in <module> class yihuohe: File "/data/user/0/coding.yu.pythoncompiler.new/files/default.py", line 23, in yihuohe print(yihuohe.yihuo(w)) NameError: name 'yihuohe' is not defined

最新资源