一区二区视频在线播放,国产成人精品久久久,九色精品免费永久在线

Debugging make

freesky — Sun, 27 Jul 2008 13:26:00 GMT

Make utilities such as GNU make, System V make, and Berkeley make, are fundamental tools for streamlining the application build process, but each one is just a little different from the others. Learn the structure of the makefile and how to avoid common mistakes in its creation, discover how to fix or work around portability issues, and pick up hints for solving other problems as they crop up.

Most UNIX® and Linux® programs are built by running make. The make utility reads a file (generally named either "makefile" or "Makefile," but hereafter merely referred to as "a makefile") that contains instructions and performs various actions to build a program. In many build processes, the makefile is itself generated entirely by other software; for instance, the autoconf/automake programs are used to develop build routines. Other programs may ask you to directly edit a makefile, and of course, new development may require you to write one.

The phrase "the make utility" is misleading. There are at least three distinct variants in common use: GNU make, System V make, and Berkeley make. Each grew from a core specification from the early UNIX days, and each adds new features. This results in a difficult situation: fairly commonly used features, such as including other files in a makefile by reference, cannot be done portably! The decision to simply write a program to create makefiles is one solution. Because GNU make is free and widely distributed, some developers simply code for it; similarly, a few projects with BSD origins require you to use Berkeley make (which is also free).

Less common but still relevant are Jörg Schilling's smake, and the absentee fifth member of the family, historical make, which defines the common feature subset that all the others share. While smake is not the default make on any system, it's a good make implementation, and some programs (especially Schilling's) use it by preference.

Let's review some of the most common problems you'll encounter when working with makefiles.

Understanding the makefile

To debug make, you have to be able to read a makefile. As you know, the purpose of a makefile is to give instructions for building a program. One of make's key features is dependency management: make attempts to rebuild only what it has to when a program is updated. In general, this is expressed through a series of dependency rules. A dependency rule looks like this:

Listing 1. Form of dependency rule

target: dependencies
            instructions

The main problem people encounter when writing their first makefile is visible in this construction; or rather, invisible. The indentation is a tab. It is not any number of spaces. The Berkeley make error message for a file using spaces in this format is not terribly helpful:

Listing 2. Berkeley make error message

make: "Makefile" line 2: Need an operator
            make: Fatal errors encountered -- cannot continue

GNU make, while still unable to process the file, gives a more helpful suggestion:

Listing 3. GNU make error message

Makefile::2: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

Note that both the dependencies and the instructions are optional; only the target and the colon are required. So, that's the syntax. What are the semantics? The semantics are that, if make wishes to build target, it will first look at dependencies. In fact, it will recursively attempt to build them; if the dependencies in turn have dependencies, those will be dealt with before this rule continues. If target exists and is at least as new as all of the items listed in dependencies, nothing is done. If target does not exist, or one or more dependencies is newer, then make executes instructions. Dependencies are processed in the order that they are specified. If no dependencies are specified, the instructions are followed anyway. Dependencies are also called sources.

If a target is given on the command line (for example, make foo), then make will attempt to build that target. Otherwise, it will try to build the first target listed in the file. One convention some developers use is to have the first target look like this:

Listing 4. Commonly used first target convention

default: all

Some people assume that make uses this rule because it's named "default." Not so; it's used because it's the first rule in the file. You could name it anything you wanted, but the name "default" is a good choice because it communicates to the reader. Remember that your makefile is going to be read by humans, not just make programs.

Phony targets

In general, it is asserted that a target's function is to create a file from other files. In fact, this is not always the case. Most makefiles have at least a couple of rules that never create a target. Consider the following example rule:

Listing 5. Example phony target

all: hello goodbye fibonacci

This rule instructs make -- if it wishes to build the target all -- to first make sure that hello, goodbye, and fibonacci are up to date. Then...nothing. No instructions are provided. After this rule is complete, no file named "all" is created. The target is a fake. The technical term used in some varieties of make is "phony."

Phony targets are used for organizational purposes and are a wonderful thing in writing a clear and legible makefile. For instance, one often sees rules like this:

Listing 6. Intelligently used phony target

build: clean all install

This specifies an order of operations for the build process.

Special targets and sources

A few special targets are defined that have special effects on make, providing a configuration mechanism. The exact set varies from one implementation to another; the most common is the .SUFFIXES target, the "sources" for which are a series of patterns to be added to the list of recognized file suffixes. Special targets don't count for purposes of the usual rule that make builds the first target in the makefile by default.

Some versions of make allow special sources to be specified along with the dependencies for a given target, such as .IGNORE, which indicates that errors from commands used to build this target should be ignored, as though a dash preceded them. These flags are not especially portable but may be necessary to understand in debugging a makefile.

Generic rules

There are implicit rules in make for performing generic transforms based on filename suffixes. For instance, with no makefile present, create a file called "hello.c" and run make hello:

Listing 7. Example of implicit rule for C files

$ make hello
            cc -O2   -o hello hello.c

makefiles for larger programs may simply specify a list of object modules they need (hello.o, world.o, and so on), then provide a rule for converting .c files to .o files:

Listing 8. Rule for converting .c to .o files

.c.o:
            cc $(CFLAGS) -c $<

In fact, most make utilities have a rule very much like this built in already; if you ask make to build file.o, and it has file.c, it'll do the right thing. The term "$<" is a special predefined make variable that refers to the "source" for a rule. That brings us to make variables.

Generic rules depend on the declaration of "suffixes," which make then recognizes as filename extensions rather than part of a name.

Variables

The make program uses variables to make it easier to reuse common values. The most set value is probably CFLAGS. A few things should be clarified about make variables. They are not necessarily environment variables. If no make variable with a given name exists, make will check for environment variables; however, that doesn't mean that make variables are exported to the environment. The precedence rules are arcane; in general, the order from highest to lowest precedence is this:

Command-line variable settings
Variables set in a parent make process's makefile
Variables set in this make process's makefile
Environment variables

Thus, environment variables are used only if a variable is not set in any makefile or on the command line. (Note: parent makefile variables are sometimes, but not always, passed down. The rules, as you may have guessed, vary from one flavor of make to another.)

A common problem people run into with make is variables inexplicably being replaced by parts of their names: for instance, $CFLAGS being replaced by "FLAGS". To refer to a make variable, put its name in parentheses: $(CFLAGS). Otherwise, you get $C followed by FLAGS.

A number of variables have special meanings that are a function of the rule they're being used in. The most commonly used are:

$< - The source from which the target is to be made
$* - The base name of the target (no extensions or directory)
$@ - The full name of the target

Berkeley make deprecates these variables, but they are (for now) still portable. Sort of portable, anyway; the exact definitions may vary between make implementations. Anything complicated you write with these will likely end up specific to a given implementation.

Shell scripting

It's occasionally desirable to perform some sort of task beyond the scope of what can be done portably in make. The conventional solution, since make runs everything through the shell, is to write an inline shell script. Here's how.

First, be aware that while shell scripts are traditionally written on multiple lines, they can be compressed to a single line with semicolons to separate statements. Second, be aware that this is illegible. The solution is a compromise: write the script with the usual indentation, but with each line ending with "; \". This ends each shell command syntactically (with a semicolon) but makes the text part of a single make command that will be passed to the shell all at once. For instance, the following might show up in a top-level makefile:

Listing 9. Breaking lines in a shell script

all:
            for i in $(ALLDIRS) ; \
            do      ( cd $$i ; $(MAKE) all ) ; \
            done

This illustrates the three things to keep in mind. First, the use of semicolons and backslashes. Second, the use of $(VARIABLE) for make variables. Third, the use of $$ to pass a dollar sign to the shell. That's it! It really is that easy.

Prefixes

By default, make prints every command it runs, and aborts if any command fails. In some cases, it's possible that a command will appear to fail, but you will want the build to continue. If the first character of a command is a hyphen (-), the remainder of the line is executed, but its exit status is ignored.

If you don't want to echo a command, prefix it with an at-sign (@). This is most commonly used for displaying messages:

Listing 10. Suppressing echo

all:
            @echo "Beginning build at:"
            @date
            @echo "--------"

Without the @ signs, this would produce the output:

Listing 11. Commands without @

echo "Beginning build at:"
            Beginning build at:
            date
            Sun Jun 18 01:13:21 CDT 2006
            echo "--------"
            --------

While the @ sign doesn't really change what make does, it's a very popular feature.

Back to top

Things you can't do portably

Some things that everyone wants to do cannot be portably done. But there are some workarounds to be had.

Include files

One of the most frustrating historical compatibility problems is handling inclusion in makefiles. Historical make implementations didn't always provide a way to do this, although all modern varieties appear to. The GNU make syntax is simply include file. The traditional Berkeley syntax is .include "file". At least one Berkeley make now supports the GNU notation as well, but not all do. The portable solution, discovered by both autoconf and Imake, is just to include every variable assignment you think you might want.

Some programs simply require the use of GNU make. Some require Berkeley make. Still others, smake. If you need include files badly enough, it's not unthinkable to simply specify a make utility that your tree will be built with. (Of the three portable ones distributed in source, my favorite is Berkeley make.)

Getting variables to nested builds

There is no really good way to do this. If you use an include file, you run into the portability problem of including the file cleanly. If you set the variables in every file, it becomes very hard to overwrite them all. If you set them only in a top-level file, independent builds in subdirectories will fail because the variables aren't set!

Depending on your version of make, one reasonably good solution is to conditionally set variables in every file only if they are not already set; then a change in the top-level file will affect subdirectories in a full build. Of course, then going into a subdirectory and running make there will get different and incompatible results...

This is amplified by the lack of include files, as anyone who has ever struggled with Imake's multi-thousand-line makefiles can attest.

Some writers advocate a simpler solution: don't use recursive make at all. For most projects, this is entirely feasible and can dramatically simplify (and speed up!) compilation. The article by Peter Miller, "Recursive Make Considered Harmful" (see Resources) is probably the canonical source.

Back to top

What to do when there's a problem

First, don't panic. Developers have been having weird problems with make since before a complete version was written. Implicit rules, unexpected variable substitutions, and syntax errors from embedded shell scripts are just where the fun begins.

Read the error message. Is it actually from make, or is it from something make is calling? If you have a nested build, you might need to thread up through a bunch of error messages to find the actual error.

If a program isn't being found, first check to see whether it's installed. If it is, check paths; some developers have the habit of specifying the absolute path to a program in makefiles, which may fail on other systems. If you installed something in /opt, and the makefile refers to /usr/local/bin, the build will fail. Fix the path.

Check your clock; more importantly, look at the dates of files in your build tree, and other files on your system, and your clock. The behavior of make when confronted with chronologically inconsistent input data can range from harmless to surreal. If you had clock problems (some "new" files datestamped in 1970, for instance), you will need to fix those. The "touch" utility is your friend. The error messages you will get from clock skew will not generally be obvious.

If the error messages you're getting imply that you have syntax errors, or tons of variables unset or set incorrectly, try a different version of make; for instance, some programs will get cryptic errors from gmake but build fine with smake. Really weird errors may indicate that you're running a Berkeley makefile with GNU make, or vice versa. Programs native to Linux often assume GNU make and fail in inexplicable ways with anything else, even if there's no hint of this in the documentation.

Debugging flags can be pretty useful. For GNU make, the -d flag will give you a HUGE amount of information, some of it useful. For Berkeley make, the -d flag takes a set of flags; -d A is the complete set, or you can use subsets; for instance, -d vx will give debugging information about variable assignments (v) and cause all commands to be run through sh -x so the shell will echo the exact command it received. The -n debugging flag causes make to print a list of things it thinks it needs to do; it's not always correct, but it often gives you an idea of what's wrong.

Your goal in debugging a makefile is to figure out what make is trying to build, and what commands it thinks will build it. If make is picking the right commands, and they're failing, you may be done debugging make -- or you may not. For instance, if the attempt to compile a program fails due to unresolved symbols, it's possible that an earlier phase of the build process did something wrong! If you are unable to figure out what's wrong with a command, and it looks like it should work, it's quite possible that one of the files already created by make was created incorrectly.

Back to top

Documentation

As is often the case, the primary documentation for GNU make is not available in man format, unfortunately; you have to use the info system instead, and you can't just run man make and look for information about it. However, the documentation is reasonably complete.

It is fairly hard to get good documentation on the "safe subset" of features that all implementations support. The Berkeley and GNU make documentation both tend to mention when they're describing an extension, but it's good to test things before relying too heavily on guesses about the exact boundaries.

Over time, drift between the BSDs has resulted in subtle differences between their implementations of make. Of the three, NetBSD is the one for which make is most actively supported on other systems; the NetBSD pkgsrc system is in use on other platforms, and relies heavily on NetBSD's implementation of make.

Resources

Learn

"Recursive Make Considered Harmful" examines problems associated with using recursive make, boils the problems down to first principles, and offers a straightforward solution.
Peter's earlier article, "Debugging configure" (developerWorks, December 2003), offers help to those who have stumbled over a broken configuration script and gives advice to developers on how to keep failures to a minimum.
In the developerWorks Linux zone, find more resources for Linux developers.
Stay current with developerWorks technical events and Webcasts.

Get products and technologies

Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.

Discuss

Check out developerWorks blogs and get involved in the developerWorks community.

转自:http://www-128.ibm.com/developerworks/library/l-debugmake.html

freesky 2008-07-27 21:26 发表评论

freesky — Sun, 27 Jul 2008 13:19:00 GMT

摘要: 跟我一起写 Makefile 陈皓概述什么是makefile�Q�或许很多Winodws的程序员都不知道�q�个东西�Q�因为那些Windows的IDE都�ؓ你做了这个工作，但我觉得要作一个好的和professional的程序员�Q�makefile�q�是要懂。这��好像现在有�q�么多的HTML的编辑器�Q�但如果你想成�ؓ一个专业�h士，你还是要了解HTML的标识的含义。特别在Unix下的... 阅读全文

freesky 2008-07-27 21:19 发表评论

Java模式设计之模板方法模�?

freesky — Mon, 14 May 2007 02:40:00 GMT

�q�是一个很��单的模式�Q�却被非常广泛的使用。之所以简单是因�ؓ在这个模式中仅仅使用��C��l�承关系�?br>
�l�承关系�׃��自��n的缺��P��被专家们扣上�?#8220;�|�恶”的帽子�?#8220;使用委派关系代替�l�承关系”�Q?#8220;��量使用接口实现而不是抽象类�l�承”�{�等专家警告�Q�让我们�q�些菜鸟对��?#8220;另眼相看”�?br>
其实�Q��承还是有很多自��n的优�Ҏ(gu��)��在。只是被大家滥用的似乎缺�Ҏ(gu��)��加明显了。合理的利用�l�承关系�Q�还是能对你的系�l�设计�v到很好的作用的。而模板方法模式就是其中的一个��用范例�?br>
二、定义与�l�构

GOF�l�模板方法（Template Method�Q�模式定义一个操作中的算法的骨架�Q�而将一些步骤�g�q�到子类中。��得子�c�d��以不改变一个算法的�l�构卛_��重定义该��法的某些特定步骤。这里的��?法的�l�构�Q�可以理解�ؓ你根据需求设计出来的业务��程。特定的步骤��是指那些可能在内容上存在变数的环节�?br>
可以看出来，模板�Ҏ(gu��)��模式也是��Z��巧妙解决变化对系�l�带来的影响而设计的。��用模板方法�ɾpȝ��扩展性增强，最��化了变化对�pȝ��的媄响。这一点，在下面的举例中可以很明显的看出来�?br>
来看下这个简单模式的�l�构吧：

1) AbstractClass�Q�抽象类�Q�：定义了一到多个的抽象�Ҏ(gu��)��Q�以供具体的子类来实现它们；而且�q�要实现一个模板方法，来定义一个算法的骨架。该模板�Ҏ(gu��)��不仅调用前面的抽象方法，也可以调用其他的操作�Q�只要能完成自��n的��命�?br>
2) ConcreteClass�Q�具体类�Q�：实现父类中的抽象�Ҏ(gu��)��以完成算法中与特定子�cȝ��关的步骤�?br>
下面是模板方法模式的�l�构图。直接把《设计模式》上的图拿过来用下：

三、�D�?/strong>

�q�是在我刚刚分析完源码的JUnit中找个例子吧。JUnit中的TestCase以及它的子类��是一个模板方法模式的例子。在TestCase�q�个�?象类中将整个��试的流�E�设�|�好了，比如先执行Setup�Ҏ(gu��)��初始化测试前提，在运行测试方法，然后再TearDown来取消测试设�|�。但是你��在 Setup、TearDown里面作些什么呢�Q�鬼才知道呢�Q�！因此�Q�而这些步骤的具体实现都�g�q�到子类中去�Q�也��是你实现的��试�c�M��?br>
来看下相关的源代码吧�?br>
�q�是TestCase中，执行��试的模板方法。你可以看到�Q�里面正像前面定义中所说的那样�Q�它制定�?#8220;��法”的框架——先执行setUp�Ҏ(gu��)��来做下初始化�Q�然后执行测试方法，最后执行tearDown释放你得到的资源�?br>

public void runBare() throws Throwable {
setUp();

try {
runTest();
}

finally {
tearDown();
}
}

�q�就是上面��用的两个�Ҏ(gu��)��。与定义中不同的是，�q�两个方法�ƈ没有被实��Cؓ抽象�Ҏ(gu��)��Q�而是两个�I�的无�ؓ�Ҏ(gu��)��Q�被�U�Cؓ钩子�Ҏ(gu��)��Q�。这是因为在��试中，我们�q?不是必须要让��试�E�序使用�q�两个方法来初始化和释放资源的。如果是抽象�Ҏ(gu��)��Q�则子类们必��ȝ��它一个实玎ͼ�不管用到用不到。这昄��是不合理的。��用钩子方法，则你在需要的时候，可以在子�c�M��重写�q�些�Ҏ(gu��)��?br>

protected void setUp() throws Exception {}
protected void tearDown() throws Exception {}

四、适用情况

�Ҏ(gu��)��上面对定义的分析�Q�以及例子的说明�Q�可以看出模板方法适用于以下情况：

1) 一�ơ性实��C��个算法的不变的部分，�q�将可变的行为留�l�子�c�L��实现�?br>
2) 各子�c�M��公共的行为应被提取出来�ƈ集中��C��个公��q��c�M��以避免代码重复。其实这可以说是一�U�好的编码习惯了�?br>
3) 控制子类扩展。模板方法只在特定点调用操作�Q�这样就只允许在�q�些点进行扩展。比如上面runBare�Q�）�Ҏ(gu��)��只在runTest前面适用setUp�?法。如果你不愿子类来修改你的模板方法定义的框架�Q�你可以采用两种方式来做�Q�一是在API中不体现��Z��的模板方法；二、将你的模板�Ҏ(gu��)��|��ؓfinal��可以了�?br>
可以看出�Q��用模板方法模式可以将代码的公��p��为提取出来，辑ֈ�复用的目的。而且�Q�在模板�Ҏ(gu��)��模式中，是由父类的模板方法来控制子类中的具体实现。这样你在实现子�cȝ��时候，�Ҏ(gu��)��不需要对业务��程有太多的了解�?/td>

转蝲�Q?a >http://fly-net-cn.javaeye.com/blog/78611

freesky 2007-05-14 10:40 发表评论

freesky — Mon, 14 May 2007 02:28:00 GMT

�{�略模式�Q�Strategy Pattern�Q�中体现了两个非常基本的面向对象设计的基本原则：��装变化的概念；�~�程中��用接口，而不是对接口实现。策略模式的定义如下�Q?

定义一�l�算法，��每个算法都��装��h��Q��ƈ且��它们之间可以互换。策略模式�ɘq�些��法在客��L(f��ng)��调用它们的时候能够互不媄响地变化�?

�{�略模式使开发�h员能够开发出��p��多可替换的部分组成的软�g�Q��ƈ且各个部分之间是��p��接的关系。弱�q�接的特性��软�g��h��更强的可扩展性，易于�l�护�Q�更重要的是�Q�它大大提高了��Y件的可重用性�?

��Z��说明�{�略模式�Q�我们将首先讨论一下在Swing中是如何利用�{�略模式来绘制组件边界的�Q�然后讨论在Swing中��用策略模式带来的好处�Q�最后讨论如何在软�g中实现策略模式�?

Swing�Ҏ(gu��)��

�Ҏ(gu��)��有的Swing�l��g�Q�例如按钮、列表单�{�，都还可以�l�制�Ҏ(gu��)��。在Swing中提供了各种 �Ҏ(gu��)��c�d��Q�例如bevel、etched、line、titled�{�。Swing�l��g的边框是通过JComponent�c�L��l�制的，该类是所有Swing �l��g的基�c�，实现了所有Swing�l��g公共的功能。在JComponent中有一个paintBorder()�Ҏ(gu��)��Q�该�Ҏ(gu��)��为组件绘制边框。Swing�?开发�h员可以象下面的例子中所�C�那��h��l�制�Ҏ(gu��)��Q?

// 一�D�实现paintBorder�Q�）�Ҏ(gu��)��代码
protected void paintBorder(Graphics g) {
   switch(getBorderType()) {
      case LINE_BORDER:   paintLineBorder(g);
                          break;
      case ETCHED_BORDER: paintEtchedBorder(g);
                          break;
      case TITLED_BORDER: paintTitledBorder(g);
                          break;
      ...
   }
}

��h��意上面的代码只是一�U�假设，事实上Swing的开发�h员�ƈ没有�q�样实现 paintBorder�Q�）�Ҏ(gu��)��。在上面的代码中�Q�在JComponent中绘制边框的代码被直接写入了paintBorder�Q�）�Ҏ(gu��)��中，�q�意味着 JComponent和绘制边框的功能被紧密地�l�合在了一赗��很自然地大家会联想到如果需要实��C��U�新的边框类型，开发�h员必��M��改至��三处代码：首先�?加一个常量，该常量代表新��d��的边框的�c�d��|��其次需要在Switch语句中增加一个case语句�Q�最后开发�h员需要实现paintXXXBorder �Q�）�Ҏ(gu��)��Q�其中XXX代表新边框的名称�?

很显然要扩展上面paintBorder()�Ҏ(gu��)��的功能是一件很困难的事情，不仅仅是因�ؓ开发�h员需要增加一�U�新的边框类型，更麻烦的是开发�h员很难修改JComponent�c�R��JComponent�c�d��l�被�~�译��C��Swing的开�?工具中，如果开发�h员想修改它的话，必须获得Swing的源代码�Q�修改后重新�~�译Swing。同时在用户的计��机上与需要��用新�~�译的Swing API。另外所有的Swing�l��g都可以��用开发�h员新��d��的边框类型。有可能开发�h员只希望新的�Ҏ(gu��)��被某些组件��用，但是现在开发�h员无法对使用该边�?的组件进行限制�?

开发�h员有更好的实现方法吗�Q�答案就是策略模式。通过�{�略模式�Q�可以将 JComponent和实现绘制边框的代码分离开来，�q�样开发�h员在增加或修改绘制边框的代码使就不需要修改JComponent的代码。通过应用�{�略�?式，开发�h员将变化的概念（在这个例子中是绘制边框）��装��h��Q�然后通过一个Border接口�Q��ɽE�序能够重用�l�制�Ҏ(gu��)��的功能。下面让我们来看 JComponent是如何利用策略模式来实现�l�制�Ҏ(gu��)��的功能的�Q?

// Swing中paintBorder()�Ҏ(gu��)��的源代码
protected void paintBorder(Graphics g) {
   Border border = getBorder();
   if (border != null) {
      border.paintBorder(this, g, 0, 0, getWidth(), getHeight());
   }
}

上面的paintBorder()�Ҏ(gu��)��通过一个border对象�l�制了组件的�Ҏ(gu��)��?�q�样border对象替代了前一个例子中的JComponent��装了边框绘制的功能。我们还应该注意到JComponent��一个对自己的引用传递给�?Border.paintBorder�Q�）�Ҏ(gu��)��Q�这是因为Border的实例必��ȝ��道它对应的组件的信息�Q�这�U�方式通常被称为委托。通过�q�种方式�Q�一个对象可以将功能委托�l�另一个对象来实现�?

在JComponent�c�M��引用了一个Border对象�Q�通过JComponent.getBorder�Q�）�Ҏ(gu��)��可以获得该Border对象。下面的代码演示了如何设定和获得Border对象�Q?

...
private Border border;
...
public void setBorder(Border border) {
   Border oldBorder = this.border;
   this.border = border;
   firePropertyChange("border", oldBorder, border);
   if (border != oldBorder) {
      if (border == null || oldBorder == null || !(border.getBorderInsets(this).
                                    equals(oldBorder.getBorderInsets(this)))) {
         revalidate();
      }       
      repaint();
   }
}
...
public Border getBorder() {
   return border;
}

当开发�h员通过JComponent.setBorder�Q�）�Ҏ(gu��)��讑֮�了一个组件的 �Ҏ(gu��)��后，JComponent�c�d��Z��个属性更��C��件。如果新的边框和以前的边框不同的话，setBorder�Q�）�Ҏ(gu��)��重新绘制边框�?getBorder�Q�）�Ҏ(gu��)��仅仅�q�回对Border对象的引用。图1昄��了Border的类�l�构图：

�? Border的类�l�构�?/center>

通过�cȝ��构图我们可以看到�Q�JComponent�c�M��保存了一个对Border对象的引用。由于Border是一个接口，Swing�l��g可以使用��M��一个实��C��Border接口的类�?

现在我们已经知道了JComponent是如何利用策略模式来�l�制�l��g的边框的。下面让我们通过实现一个新的边框类型来��试一下它的可扩展性�?

实现一个新的边框类�?/strong>
�?中是一个有三个JPanel对象的小�E�序�Q�每个JPanel对象有各自不同的�Ҏ(gu��)��Q�每个边框对应一个HandleBorder实例�?
�? 新的�Ҏ(gu��)��c�d��

// HandleBorder.java
import java.awt.*;
import javax.swing.*;
import javax.swing.border.*;
public class HandleBorder extends AbstractBorder {
protected Color lineColor;
protected int thick;
public HandleBorder() {
this(Color.black, 6);
}
public HandleBorder(Color lineColor, int thick) {
this.lineColor = lineColor;
this.thick = thick;
}
public void paintBorder(Component component,
Graphics g, int x, int y, int w, int h) {
Graphics copy = g.create();
if(copy != null) {
try {
copy.translate(x,y);
paintRectangle(component,copy,w,h);
paintHandles(component,copy,w,h);
}
finally {
copy.dispose();
}
}
}
public Insets getBorderInsets() {
return new Insets(thick,thick,thick,thick);
}
protected void paintRectangle(Component c, Graphics g,
int w, int h) {
g.setColor(lineColor);
g.drawRect(thick/2,thick/2,w-thick-1,h-thick-1);
}
protected void paintHandles(Component c, Graphics g,
int w, int h) {
g.setColor(lineColor);
g.fillRect(0,0,thick,thick);
g.fillRect(w-thick,0,thick,thick);
g.fillRect(0,h-thick,thick,thick);
g.fillRect(w-thick,h-thick,thick,thick);
g.fillRect(w/2-thick/2,0,thick,thick);
g.fillRect(0,h/2-thick/2,thick,thick);
g.fillRect(w/2-thick/2,h-thick,thick,thick);
g.fillRect(w-thick,h/2-thick/2,thick,thick);
}
}

HandleBorder�cȝ��承了 javax.swing.border.AbstractBorder�c�dƈ重写了paintBorder�Q�）和getBorderInsets�Q�）�?HandleBorder是如何实现的其实�q�不重要�Q�重要的是由于Swing使用了策略模型，开发�h员能够很方便地增加新的边框类型。下面的代码昄��了如何��用HandleBorder�c�R��在�q�个例子中创��Z��三个JPanel对象�Q��ƈ�Ҏ(gu��)��个JPanel对象讑֮�一个HandleBorder实例作�ؓ�Ҏ(gu��)��?

// Test.java
import javax.swing.*;
import javax.swing.border.*;
import java.awt.*;
import java.awt.event.*;
public class Test extends JFrame {
public static void main(String[] args) {
JFrame frame = new Test();
frame.setBounds(100, 100, 500, 200);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.show();
}
public Test() {
super("实现一个新的边框类�?);
Container contentPane = getContentPane();
JPanel[] panels = { new JPanel(),
new JPanel(), new JPanel() };
Border[] borders = { new HandleBorder(),
new HandleBorder(Color.red, 8),
new HandleBorder(Color.blue, 10) };
contentPane.setLayout(
new FlowLayout(FlowLayout.CENTER,20,20));
for(int i=0; i < panels.length; ++i) {
panels[i].setPreferredSize(new Dimension(100,100));
panels[i].setBorder(borders[i]);
contentPane.add(panels[i]);
}
}
}

�q�记得在上面的例子中曾提到在有些情况下，对组件的引用会作为参��C��递给 Border.paintBorder�Q�）�Ҏ(gu��)��。虽然上面的HandleBorder�c�L��有保存对�l��g的引用，但是有些情况下Border接口的实现类�?使用到对�l��g的引用�ƈ从中获得关于�l��g的信息。例如在EtchedBorder中，paintBorder�Q�）�Ҏ(gu��)��通过对组件的引用获得它对应的�l��g的阴影和高光�Ԍ��

// 下面的代码截取自javax.swing.border.EtchedBorder
public void paintBorder(Component component, Graphics g, int x, int y,
int width, int height) {
int w = width;
int h = height;
g.translate(x, y);
g.setColor(etchType == LOWERED? getShadowColor(component) :
getHighlightColor(component));
g.drawRect(0, 0, w-2, h-2);
g.setColor(etchType == LOWERED? getHighlightColor(component) :
getShadowColor(component));
g.drawLine(1, h-3, 1, 1);
g.drawLine(1, 1, w-3, 1);
g.drawLine(0, h-1, w-1, h-1);
g.drawLine(w-1, h-1, w-1, 0);
g.translate(-x, -y);
}

如何实现�{�略模型
通过以下步骤�Q�开发�h员可以很�Ҏ(gu��)��地在软�g中实现策略模型：

1�Q�对�{�略对象定义一个公共接口�?

2�Q�编写策略类�Q�该�c�d��C��上面的公共接口�?

3�Q�在使用�{�略对象的类中保存一个对�{�略对象的引用�?

4�Q�在使用�{�略对象的类中，实现对策略对象的set和get�Ҏ(gu��)��?

在Swing�Ҏ(gu��)��的例子中�Q�公共接口是javax.swing.Border。策略类是LineBorder、EtchedBorder、HandleBorder�{�。而��用策略对象的�c�L��JComponent�?

转蝲�Q?a >http://fly-net-cn.javaeye.com/blog/78615

freesky 2007-05-14 10:28 发表评论

架构师书�?2nd Edition

freesky — Sun, 13 May 2007 09:22:00 GMT

   作者：江南白衣�Q�原文出处： http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx
   一、Software Architecture��?/h2>
     �q�个领域没有什�?畅销�?�Q�可能读者中本来��是开发设计�h员与��目�l�理占了多数�Q�真正定位�ؓ架构师而且做的也是架构师工作的不多吧，你懂的尽是偏�?n��i)��人生�?/p>
   1.软�g架构入门
《Large-Scale Software Architecture --大型软�g体系�l�构�Q��用UML实践指南�?br>   ��C��架构师的入行指南�Q�从什么是架构和架构师一直到以构件�ؓ�_�度的大型系�l�架构UML实例�?/p>

2. 软�g架构�q�阶

《Software Architecture in Practice,2nd Edition--软�g构架实践(�W?�?�?/strong>

   �W�一版是�W�九(ji��)届JOLT作品�Q�一本被引用很多的架构书�?/p>
《Documenting Software Architectures --软�g构架�~�档�?/strong>
   �W?3届JOLT大奖作品�Q�捕��h��构的�q�程�Q?a id=AjaxHolder_Comments_CommentList_ctl16_NameLink target=_blank>徐昊推荐�?/p>
《Applied Software Architecture --实用软�g体系�l�构�?/strong>

   另一本被引用很多的架构之书�?br>
《The Art of Software Architecture --软�g体系�l�构的艺术�?/strong>

    薄薄的一本，上面几本的理论抽象与薄化�?br>
《Evaluating Software Architectures --软�g构架评估�?

    SEI出品�Q�正儿八�l�的ATAM架构评估�Ҏ(gu��)��和两个评估案例，��带介绍了SAAM和ARID�?strong>

二、RUP/UML ��?/h2>
RUP、UML�?+1视图始终是架构师界最通用的东西，��L��一�U�向世界妥协的方式�?br>
1. RUP 文档
《RUP 7.0.1文档�?/strong>在Rational Method Composer 7.0试用版之中，是最好架构师的行动指南与自助��?br>《The Rational Unified Process:An Introduction.3rd Edition --RUP��D��(�W?�?�?/strong>是RUP2003文档的羃略版�Q�在啃文档细节前可以先拿中文版来��M��下�?br>   但公叔R��L��充满对RUP的误�?strong>�Q�《The Rational Unified Process Made Easy:A Practitioner's Guide to the RUP--Rational�l�一�q�程�Q�实践者指南�?/strong>是排除各�U�误解的RUP实施指南�?br>
2. UML2工具�?br>《UML2 Toolkit--UML2.0工具��》或者《UML�_��a�W?�?-UML Distilled 3rd�?/strong>都不错，后一本略薄。UML2.0相比UML1.x �Q�对于模型派的架构师来说是天大的恩物�Q�一定要补课�?/p>
3.《UML和模式应�?�W?�?--Applying UML and Patterns 3rd�?/strong>
   UML+RUP作的OOAD�q�程�?/p>

三、特定领域篇

    开发�h员有GOF23 Pattern�Q�架构师同样也有架构师的Pattern。不同领域的架构师需要不同的知识�?br>1. 公共领域
《Domain-Specific Application Frameworks --特定领域应用框架�Q�行业的框架体验�?br> ozzzzzz推荐�Q�介�l�了30个特定领域特定框架的设计。我自己最喜欢看�h家的设计与思考�?/p>
《Object Oriented Reengineering Patterns--软�g再造：面向对象的��Y件再工程模式 �?/strong>
逆向工程与再工程的模式，架构师整天都要和旧系�l�打交道�Q�接手一个架构师已跑路，文档不全的系�l�开�?.0版本�?br>
《Head First Design Patterns�?nbsp;
  最好的GOF23�l�典设计模式阐释�Q�适合被[GAMMA95]折磨的架构师拿来复习�Q�中文版卛_��发行�?br>

2. Java EE领域
《Patterns of Enterprise Application Architecture --企业应用架构模式�?
     Martin Fowler�l�典�Q�企业应用各Layers上的模式�?nbsp;

《Effective Enterprise Java--中文版�?/strong>
      Neward, Ted作品�Q�作者学贯东�?.Net与Java)�Q�像写Blog一��P��每一��里面都有大量的信息�?/p>


3. EAI/SOA领域
《Enterprise Integration Patterns --企业集成模式�Q�设计、构建及部��v消息传递解��x��案�?/strong>

4. �|�络与后台服务编�E�领�?br>《Pattern-Oriented Software Architecture, Volume 2 --面向模式的��Y件体�pȝ��?�?:用于�q�发和网�l�化对象的模式�?br>
《Pattern-Oriented Software Architecture, Volume 3 --面向模式的��Y件体�pȝ��构卷3�Q�资源管理模式�?/strong>

    著名的POSA2与POSA3�?br>

四、闲书篇

《Code Complete 2 --代码大全2�?/strong>
   一本你教育��弟时的代言人�?/p>
《The Pragmatic Programmer --�E�序员修��g��道：从小工到专家�?/strong>
   一本你启发��弟的代�a�人�?/p>
《The Art of Unix Programming --UNIX�~�程艺术�?/strong>

五、高效读书心�?/h2>
   刚好Head First�p�d��开头都有一�D�|��人如何读书的话，再加工整理如下：

1.��量阅读中文�?/strong>
虽然有�h英文很强�Q�有的翻译很差，但AnyWay 中文阅读与理解的旉��Q�略��M��快速定位的速度�q�是要快一些�?br>
2.��x��Ҏ(gu��)��、�ȝ��W�记与交��?/strong>
虽然�׃��Q�但发现最有效的读书方式还是不断的刉��脂�Ҏ(gu��)��Q�读书时在重要的文字下划�U�，把自��q��心得写在��|��?br> 在明天复习一�ơ批注，最好可以有�I�重新整理笔讎ͼ�或者拿来与��论�?nbsp;

3.大量思考或重复记忆
看书最郁闷的事情就是看完之后脑袋空�I�Z��。技术书�q�好点，虽然看的时候可能很辛苦�Q�但��像学会了骑单�R�Q�之后再骑的时候��L��会的�Q�而偏设计与管理的书，最�Ҏ(gu��)��的事情就是看的时候很快，看完没什么留下到实践中�?br> 所以，我们不能以看��说的速度来看设计书，要寻找思考的��Z��Q�思考是最好的记忆�?br> 又或者，大量的重复记忆，重复多遍直到无意识的记忆�?nbsp;

4.��Z��工学
  那些见缝插针的时间与地点不是看这个书单的好地斏V�?br> 环境不要有电(sh��)视，音乐�{�强输入源，而微风阳光鸟语等��p��入源则有助活跃大脑�?br> 看书时大量的喝水�?br> 如果发现自己的大脑已�l�疲累，已经在��Q光掠��q��ȝ��Q�就要休息�?br> 留给大脑消化的时��_��看完书不要接着看其他有隑ֺ�的书或事情�?/p>

freesky 2007-05-13 17:22 发表评论

观点与展望，�W?3 部分: 什么是最有�h(hu��n)值的 IT 体系�l�构技能，如何学习

freesky — Sun, 13 May 2007 09:17:00 GMT
     摘要: 知道了成��Z��个成功的 IT 架构师需要投入多��工作后�Q�我们就想知道哪些因素对成�ؓ一个不错的架构师�v军_��性作用。因此，我们向专家组提出了这��L(f��ng)��问题�Q�“什么技能对 IT 架构师最有�h(hu��n)��|��架构师如何学习这些技能？�?

可以在很多地�Ҏ(gu��)��到成为好的架构师所需的技能列表——书上、培训课�E�、大学、有关体�pȝ��构的其他�|�站上等�{�。例如，IBM 的内部专业提高网站就提出以下几点 IT 架构师的理想特征�Q?

设计体系�l�构的技能和�l�验
有序的以�Ҏ(gu��)��为驱动源的�Q务执�?
完整生命周期�l�验
行业部门�l�验
领导能力
很强的沟通和专业技�?

和可能看到的很多其他列表�c�M��Q�这个列表相当泛泛，可能�q�不如�?zh��n)�所期望的那��h��可操作性。而这正是我们询问前面的问题的原因所在：帮助�(zh��n)�确定一个明��的方向�?

  阅读全文

freesky 2007-05-13 17:17 发表评论

观点与展望，�W?2 部分: 如何��业务需求�{转换�?IT 要求

freesky — Sun, 13 May 2007 09:11:00 GMT
     摘要: 作�ؓ IT 架构师，�(zh��n)�可能经�怼�发现自己处于�q�退�l�谷的境圎ͼ�前有�(zh��n)�的业务目标�Q�后有�?zh��n)��?IT �pȝ��。这两方面都��h��规模大、不易改变和灉|��性差的特炏V��制定业务目标的人员和开发系�l�的人员不一定了解彼此的工作内容和成果。似乎是�q�样�Q�业务�h员��用一�U�语�a�来表达他们希望实现的业务目标�Q�而开发�h员则使用另一�U�语�a�来表�q�技术要求�?

而这��是我们��Z��实现高效率而需要着手处理的问题�Q�理解这两种语言�q�执行必要的转换�Q�以�?IT 能反映业务的需求，�q�能在适当的时候对业务目标�q�行更改�Q��其与 IT 的能力相适应。这�q�不是一个容易完成的工作�Q�但�q�正是�?zh��n)�能够获得很大利益的原因�?

�׃��q�部分工作可能会非常困难而棘手，因此�Q�我们向 IBM 体系�l�构专家队伍��L��指导。本月我们邀误��些专家分享他们用来将业务需求表�q�Cؓ明晰��z�的技术要求的�Ҏ(gu��)��Q�以�?IT 团队能成功地实现�?

  阅读全文

freesky 2007-05-13 17:11 发表评论

观点与展望，�W?1 部分: 选择 SOA 的原因和时机

freesky — Sun, 13 May 2007 09:04:00 GMT
     摘要: 面向服务的体�pȝ��?(SOA) 已成��Z��一��事实标准，用于开发基于组件的应用�E�序�Q�可使用标准接口通过�|�络�Q�Internet 或其他网�l�）讉K��q�些应用�E�序。至��?IBM 高�񔽎�理人员和很多其他供应商、分析师、顾问和软�g开发�h员都�q�么说。他们还��告诉�?zh��n)��Q�整个行业都在逐步采用 SOA�Q�如果�?zh��n)��未开�?SOA 开发，��很快跟不上时代的步伐了�?

赞誉之词。但�q�些看法是否真的很有吸引力，能让�(zh��n)�开始着手�?zh��n)�自己�?SOA 吗？让我们来看看一位参�?Open Group ��d��?SOA 大会的架构师的问题。在 IBM Global Services 副总裁 Michael Liebow 的主题发�a�后的提问期间�Q�这位架构师问道�Q�“SOA 是不是我们需要知道的唯一体系�l�构�Q�（��Z��提一下，Liebow 先生的回�{�是“是的”）在稍后，另一位架构师大声问道�Q�“SOA 和我们多�q�前��q��道的�l��g体系�l�构很相伹{��如果我们采用了它，是否意味着我们又多��M��一个技术竖井（另一个开发死胡同�Q�，从而需要进行更多的集成�Q�”（而这�ơ，会议参加者——包括��^��C��应商、企�?IT 架构师、顾问、系�l�集成商和其他�h员——回  阅读全文

freesky 2007-05-13 17:04 发表评论

一区二区视频在线播放,国产成人精品久久久,九色精品免费永久在线

Debugging make

Java模式设计之模板方法模�?

架构师书�?2nd Edition

三、特定领域篇

四、闲书篇

观点与展望，�W?3 部分: 什么是最有�h(hu��n)值的 IT 体系�l�构技能，如何学习

观点与展望，�W?2 部分: 如何���业务需求�{转换�?IT 要求

观点与展望，�W?1 部分: 选择 SOA 的原因和时机

观点与展望，�W?2 部分: 如何��业务需求�{转换�?IT 要求