一区中文字幕电影,9999久久久久,蜜桃999成人看片在线观看

Thinking in java review

junhong — Tue, 27 Jun 2006 09:40:00 GMT

1�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Java 中所有的 member function 都是动态绑�?/span>

2�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Java 中所有的对象都是通过 new 来动态��?/span>

3�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> 所有的容器 (collection) �?/span> Object array( 对象数组 e.g String []str=new String[10]) 内都包含都是对象�?/span> reference

4�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> �?/span> java 中， java �~�译器有责�Q产生“将 stack 指针前后�U�d��“的�E�序代码�Q�所�?/span> 它必��能够完全掌握它所�~�译的的�E�序中“存�?/span> stack 里头的所有数据的实际大小和存�z�L��间“，如此一来便会限制程序的�Ҏ��?/span> �׃��q�个限制�Q�尽��我们可以将对象�?/span> reference 存储�?/span> stack 内，但却不能��一般的 java 对象攑֜� stack �?/span>
特例�Q�（ primitive types �Q?/span>
基本型别会经常被使用�Q�如果��?/span> new 来��生此�c�L��，极简单的变量�Q�会因�?/span> new ��对象置�?/span> heap 之上�?/span> 而效率不好。因此对于此�c�d��?/span> java 采取 c/c++ 的方式，也就是不�?/span> new 分配器空��_��而是产生一�U�所谓的 ”automatic “变量，存于 static �?/span>

5�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> 当你产生某个存储对象的数�l�，真正产生的是个存�?/span> reference 的数�l�。此数组建立之后�Q�其中的每一�?/span> reference 都会被自动设为某个特�D�的�?/span> null,

6�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> { String s=new String(“ddd�?;} s �q�个 reference 会在生存�I�间之外消失无踪�Q�但是， s 先前所指的那个 String 对象仍然会��l�占用内�?/span>

7�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Class 内的基本型别变量都有初��|��但是在函数内�?/span> local variable 是没有初值的

8�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Java 中，所有传递的对象的场合，传递的都是对象�?/span> reference.

9�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Return �Q?/span> 说明�q�个函数�q�行�l�束�Q�返回到其调用函数�?/span> Return 2 �Q�返回一个数 2 �l�调用者，同时�l�束本函数的�q�行�?/span>

10�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Class 内的 non-static data(state) �?/span> method , 都是和特定的对象�l�定的，一般情况下�Q�你的��生某个对象，再通过该对象取用其数据和函数。所�?/span> non-static 数据 / 函数必须知道他们隶属于哪一个对象，才有办法�q�行 .static 函数内不能��?/span> non-static 数据和函�?/span>

11�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> (object1= = object2 ) 两个对象�?/span> reference �?/span> = = 比较得是两个对象的内存的地址。所以我们不能��?/span> = = 来测试两个对象的内容是否相等。如果想��试对象的内�Ҏ��否相�{�，应该使用 equal(), ��M��一个对象都拥有�q�个函数。不�q�你自己�?/span> class 需�?/span> override �q�个函数�Q�否则默认的 equal() 函数是还是比较的两个对象的内存地址�?/span>
Java 标准�E�序库中的大多数 class �?/span> override �?/span> equal(), 所以他们都会比较对象的内容是否相等�?/span>

12�?span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> 位运��符都是作用于基本正数类型。该�q�算�W�主要是针对��g�~�程使用�Q�我们用得不多，�Q?/span>

待箋

junhong 2006-06-27 17:40 发表评论

junhong — Wed, 19 Apr 2006 15:39:00 GMT

关于输入框中昄��双引号和单引�?/strong>

description="compile the source " >

description="generate the distribution" >

description="clean up" >

Notice that we are declaring properties outside any target. As of Ant 1.6 all tasks can be declared outside targets (earlier version only allowed and for example).

We have given some targets descriptions; this causes the Finally, for this target to work the source in the task for details. Token Filters A project can have a set of tokens that might be automatically expanded if found when a file is copied, when the filtering-copy behavior is selected in the tasks that support this. These might be set in the buildfile by the filter task. Since this can potentially be a very harmful behavior, the tokens in the files must be of the form @, where token is the token name that is set in the Note: If a token with the format @ is found in a file, but no filter is associated with that token, no changes take place; therefore, no escaping method is available - but as long as you choose appropriate names for your tokens, this should not cause problems. Warning: If you copy binary files with filtering turned on, you can corrupt the files. This feature should be used with text files only. Path-like Structures You can specify CLASSPATH-type references using both " Wherever path-like values need to be specified, a nested element can be used. This takes the general form of: The path attribute accepts colon- or semicolon-separated lists of locations. The location attributes should be preferred. As a shortcut, the path and can be abbreviated to: In addition, DirSet s, FileSet s, and FileList s can be specified via nested , and This builds a path that holds the value of lib directory, the classes under the ${build.dir}, except those that have the text If you want to use the same path-like structure for several tasks, you can define them with a References for an example. A path-like structure can include a reference to another path-like structure via nested The shortcuts previously mentioned for .For example: can be written as: generally, you need not to write your builder.xml file started from scratch. you can just modify the following part to meet your demand. basedir="${build.home}"/> destdir = "${doc.home}/api" packagenames = "${javadoc.pkg.top}.*"/> junhong 2006-04-19 21:41 发表评论 how to use sitemesh junhong — Thu, 13 Apr 2006 15:41:00 GMT Copy sitemesh-2.2.1.jar into [web-app]/WEB-INF/lib. Create the file [web-app]/WEB-INF/decorators.xml that contains the following: (Optional) Create the file [web-app]/WEB-INF/sitemesh.xml that contains the following: Add the following to [web-app]/WEB-INF/web.xml within the tag: sitemesh com.opensymphony.module.sitemesh.filter.PageFilter sitemesh /* Decorators are the pages that "decorate" the original, requested page (the page that is handed to the SiteMesh filter from the web container). Most (HTML) decorators are a combination of: meta tags (keywords, description, author) stylesheet (CSS) header navigation footer copyright noticeFirst, define what different navigation/layout schemes you need. For example: Do I need a default decorator (a standard one for all pages)? Do I have a special layout for the index page? Is the header needed for my documentation files? Do I need printable version of my website? Web Application Structure Here is an example structure of a web application. This is not needed for SiteMesh to work. /decorators Directory containing all decorator files (e.g. main.jsp, printable.jsp). /includes Directory containing all files to be included into other files (e.g. header.jsp, footer.jsp, copyright.jsp). /images Directory containing all images (e.g. background.gif, logo.gif). /styles Directory containing all .CSS styles (e.g. ie4.css, ns4.css). /scripts Directory containing all scripts (JavaScript, VBScript files). Good practices: Define a stylesheet to use in the entire application and include it using this script. Use includes in your decorators (e.g. includes/navigation.jsp, includes/style.jsp). Try not to refer to the absolute root ("/") path. Use <%=request.getContextPath()%>/ instead. This will make life easier when moving your web application under another context path. Making your decorators compatible with multiple browsers (IE, Mozilla, Opera, ...) will (probably) make your entire application (all decorated pages) compatible. Be careful when using frames, because decorators may NOT be applied to frames (FrameSetDecoratorMapper). My First Decorator Basically, all you need to know is what decorator tags you can use. The title, head and body tags are most used. Here is an example of a decorator (save it as /decorators/main.jsp): 1: <%-- 2: % This is the main decorator for all SOMECOMPANY INTRANET pages. 3: % It includes standard caching, style sheet, header, footer and copyright notice. 4: --%> 5: <%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator" prefix="decorator" %> 6: <%@ include file=" 7: 8: 9: 10: <b><font color="maroon"><decorator:title default="INTRANET" /></font></b> 11: 12: <%@ include file=" 13: 14: 15: 16: <%@ include file="/includes/header.jsp"%> 17: 18: 19: 20: 21: 22: 23: 26: 27: 32: 33: 34: 23: 24: <%@ include file="/includes/navigation.jsp" %> 25: 28: 29: 30: 31: 35: 36: <%@ include file="/includes/footer.jsp" %> 37: <%@ include file="/includes/copyright.jsp" %> 38: 39: 40: Line 1-4: An explanation of the decorator. This way different people working on the decorator are quickly up to speed. Line 5: This is needed for the decorator: tags to work (also needed on all pages that work with inline decorators (page:applyDecorator). Line 6: Sets the necessary response headers to let the browser cache the page. Omit this line if your application is real dynamic (changing data). Line 10: If the requested page doesn't have a title, the default title is used ("INTRANET"). Line 15: The status bar gets a message when the page is loading. Line 30: The entire body of the requested page has the docBody class. This way the navigation and body do not have to have the same font. Now open WEB-INF/decorators.xml with your favorite editor and let SiteMesh know there is a decorator (with a mapping): /* Now deploy the web application, go to the welcome page, and the main decorator will be applied. When a page has been parsed, it then has to be mapped to a decorator. This mapping is performed by a chain of DecoratorMappers (referred to as mappers from here on). For each request, the first mapper in the chain is asked which decorator should be used. It is passed across a reference to the Page object and HttpServletRequest. It returns either a Decorator object, if it knows which decorator to be used, or null. If null is returned, the next mapper in the chain is queried. This whole process is repeated until there are no more mappers in the chain, or one of the mappers returns a valid decorator. If no mappers return a decorator, the page is not decorated at all and served in its original state. This way the mappers are chained together and queried is known as the Chain of Responsibility design pattern. Examples of mappers: Determine decorator based on path of requested page. Use different decorators based on time, locale or browser. Use simplified decorators for search-engine robots. Switch decorators based on a URL parameter, request attribute or meta-tag. Use custom decorators based on user's saved settings... The main implementation of DecoratorMapper is ConfigDecoratorMapper which reads the decorators and mappings from /WEB-INF/decorators.xml. The appropriate decorator is then applied depending on the URL pattern. DecoratorMappers are simple to write and the distribution includes some samples that demonstrate how to write them and how flexible they can be. These are: AgentDecoratorMapper Can determine the user-agent (i.e. web-browser) requesting a page, and map to a suitable Decorator. ConfigDecoratorMapper Default implementation of DecoratorMapper. Reads decorators and mappings from the config property (default '/WEB- INF/decorators.xml'). CookieDecoratorMapper Will map a suitable decorator based on a cookie value. EnvEntryDecoratorMapper Allows the reference to a web-app environment entry for the decorator name, and falls back to ConfigDecoratorMapper's behavior if no matching environment entry is found. FileDecoratorMapper Will treat the name of the decorator as a file-name to use (in the context of the web-app). FrameSetDecoratorMapper Will use the specified decorator when the Page is an instance of HTMLPage and isFrameSet() returns true. The name of this decorator should be supplied in the decorator property - if no decorator property is supplied, no decorator is applied to frame based pages. InlineDecoratorMapper Used to determine the correct Decorator when using inline decorators. LanguageDecoratorMapper Can determine the preferred language set in the browser requesting a page, and map to a suitable Decorator (using the "Accept-Language" HTTP header). PageDecoratorMapper The actual Page determines the Decorator to be used. The 'meta.decorator' and 'decorator' properties of the page are accessed and if any of them contain the name of a valid Decorator, that Decorator shall be applied. ParameterDecoratorMapper Will choose the decorator based on request parameters. The ParameterDecoratorMapper is configured via three properties. decorator.parameter - the parameter which contains the name of the decorator which will be mapped. The default is "decorator". For example if decorator.parameter is "foobar" then myurl.jsp?foobar=mydecorator will map to the decorator named "mydecorator". You can also supply an optional 'confirmation parameter'. The decorator will only be mapped if the parameter named parameter.name is in the request URI and the value of that parameter is equal to the parameter.value property. For example assuming parameter.name=confirm and parameter.value=true the URI myurl.jsp?decorator=mydecorator&confirm=true will map the decorator mydecorator. where as the URIs myurl.jsp?decorator=mydecorator and myurl.jsp?decorator=mydecorator&confirm=false will not return any decorator. SessionDecoratorMapper Will look at a session attribute to find the name of an appropriate decorator to use. If the session attribute is present, the mapper will not do anything and allow the next mapper in the chain to select a decorator. By default, it will look at the 'decorator' session attribute, however this can be overriden by configuring the mapper with a 'decorator.parameter' property. PrintableDecoratorMapper Will check to see whether 'printable=true' is supplied as a request parameter and if so, use the specified decorator instead. The name of this decorator should be supplied in the decorator property. RobotDecoratorMapper Will use the specified decorator when the requester is identified as a robot (also known as spider, crawler, ferret) of a search engine. The name of this decorator should be supplied in the decorator property. An example of a custom DecoratorMapper could be one that displays different Decorators based on time (e.g. morning, afternoon, Christmas, etc). Custom mapper configuration To be able to specify which mappers will be applied to a request, create the file [web-app]/WEB-INF/sitemesh.xml that contains the following: In this example, the only mapper that will be applied is the ConfigDecoratorMapper, and that will only be applied to responses of type text/html or text/html;charset=ISO-8859-1. Responses of any other content type (eg image/gif) will be ignored by Sitemesh. Additionally, any files that match a pattern specified in the excludes file (in this case '/WEB-INF/decorators.xml') will not be touched by Sitemesh. The excludes file points to an XML file that contains an block similar to the following: /plainPage.jsp /plain/*.jsp The above example would prevent /plainPage.jsp and any JSP pages in the /plain directory from being decorated. (Note that the pattern matching follows exactly the same rules as the decorator mappings used by the ConfigDecoratorMapper.) Typically the block is just added at the start of the decorators.xml file, however this is not a requirement and any other XML file can be specified instead by changing the excludes file specified in sitemesh.xml. This might be useful if for example the ConfigDecoratorMapper is not being used in your deployment. Note that preventing pages from being decorated by adding them to the excludes list superceeds, and is a better approach than, the old method of mapping the pages to a non-existent decorator. This is because when pages were mapped to a non-existent decorator they were still buffered internally by Sitemesh. By using the exclude list Sitemesh will not let the request pass straight through to the servlet container without any buffering. Default mapper configuration If sitemesh.xml is not found in the WEB-INF dir, the default mapper configuration will be used. The default mapper configuration is defined in sitemesh-default.xml (packaged inside the jar) and consists of the following mappers: PageDecoratorMapper FrameSetDecoratorMapper PrintableDecoratorMapper FileDecoratorMapper ConfigDecoratorMapper By default only content of type text/html will be decorated by Sitemesh. for more detail, please refer to http://www.opensymphony.com/sitemesh/dm.html junhong 2006-04-13 23:41 发表评论 Design Pattern with java (part three) junhong — Mon, 10 Apr 2006 15:51:00 GMT Specialized creation Prototype Objects are created by cloning a prototypical instance. Builder The goal of builder is to separate the construction from the “representation,�?to allow multiple different representations. The construction process stays the same, but the resulting object has different possible representations. GoF points out that the main difference with Abstract Factory is that a Builder creates the object step-by-step, so the fact that the creation process is spread out in time seems to be important. In addition, it seems that the “director�?gets a stream of pieces that it passes to the Builder, and each piece is used to perform one of the steps in the build process. One example given in GoF is that of a text format converter. The incoming format is RTF, and once it is parsed the directives are passed to the text converter, which may be implemented in different ways depending on whether the resulting format is ASCII, TeX, or a “GUI Text Widget.�?Although the resulting “object�?(the entire converted text file) is created over time, if you consider the conversion of each RTF directive to be an object, this feels to me a little more like Bridge, because the specific types of converters extend the interface of the base class. Also, the general solution to the problem would allow multiple readers on the “front end�?and multiple converters on the “back end,�?which is a primary characteristic of Bridge. To me, the fact that Builder has multiple steps in creating an object, and those steps are accessed externally to the Builder object, is the essence of what distinguishes it (structurally, anyway) from a regular factory. However, GoF emphasizes that you’re able to create different representations using the same process. They never define exactly what they mean by representation. (Does the “representation�?involve an object that is too large? Would the need for Builder vanish if the representation was broken into smaller objects?) The other example in GoF creates a maze object and adds rooms within the maze and doors within the rooms. Thus it is a multistep process, but alas, the different “representations�?are the “Standard�?and “Complex�?mazes �?not really different kinds of mazes, but instead different complexity. I think I would have tried to create one maze builder that could handle arbitrarily complex mazes. The final variation of the maze builder is something that doesn’t create mazes at all, but instead counts the rooms in an existing maze. Neither the RTF converter nor the Mazebuilder example makes an overwhelmingly compelling case for Builder. Readers have suggested that the output of the Sax XML parser, and standard compiler parsers, might naturally be fed into a Builder. Here’s an example that may be a little more compelling, or at least give more of an idea of what Builder is trying to do. Media may be constructed into different representations, in this case books, magazines and web sites. The example argues that the steps involved are the same, and so can be abstracted into the director class. //: builder:BuildMedia.java // Example of the Builder pattern package builder; import java.util.*; import junit.framework.*; // Different "representations" of media: class Media extends ArrayList {} class Book extends Media {} class Magazine extends Media {} class WebSite extends Media {} // ... contain different kinds of media items: class MediaItem { private String s; public MediaItem(String s) { this.s = s; } public String toString() { return s; } } class Chapter extends MediaItem { public Chapter(String s) { super(s); } } class Article extends MediaItem { public Article(String s) { super(s); } } class WebItem extends MediaItem { public WebItem(String s) { super(s); } } // ... but use the same basic construction steps: class MediaBuilder { public void buildBase() {} public void addMediaItem(MediaItem item) {} public Media getFinishedMedia() { return null; } } class BookBuilder extends MediaBuilder { private Book b; public void buildBase() { System.out.println("Building book framework"); b = new Book(); } public void addMediaItem(MediaItem chapter) { System.out.println("Adding chapter " + chapter); b.add(chapter); } public Media getFinishedMedia() { return b; } } class MagazineBuilder extends MediaBuilder { private Magazine m; public void buildBase() { System.out.println("Building magazine framework"); m = new Magazine(); } public void addMediaItem(MediaItem article) { System.out.println("Adding article " + article); m.add(article); } public Media getFinishedMedia() { return m; } } class WebSiteBuilder extends MediaBuilder { private WebSite w; public void buildBase() { System.out.println("Building web site framework"); w = new WebSite(); } public void addMediaItem(MediaItem webItem) { System.out.println("Adding web item " + webItem); w.add(webItem); } public Media getFinishedMedia() { return w; } } class MediaDirector { // a.k.a. "Context" private MediaBuilder mb; public MediaDirector(MediaBuilder mb) { this.mb = mb; // Strategy-ish } public Media produceMedia(List input) { mb.buildBase(); for(Iterator it = input.iterator(); it.hasNext();) mb.addMediaItem((MediaItem)it.next()); return mb.getFinishedMedia(); } }; public class BuildMedia extends TestCase { private List input = Arrays.asList(new MediaItem[] { new MediaItem("item1"), new MediaItem("item2"), new MediaItem("item3"), new MediaItem("item4"), }); public void testBook() { MediaDirector buildBook = new MediaDirector(new BookBuilder()); Media book = buildBook.produceMedia(input); String result = "book: " + book; System.out.println(result); assertEquals(result, "book: [item1, item2, item3, item4]"); } public void testMagazine() { MediaDirector buildMagazine = new MediaDirector(new MagazineBuilder()); Media magazine = buildMagazine.produceMedia(input); String result = "magazine: " + magazine; System.out.println(result); assertEquals(result, "magazine: [item1, item2, item3, item4]"); } public void testWebSite() { MediaDirector buildWebSite = new MediaDirector(new WebSiteBuilder()); Media webSite = buildWebSite.produceMedia(input); String result = "web site: " + webSite; System.out.println(result); assertEquals(result, "web site: [item1, item2, item3, item4]"); } public static void main(String[] args) { junit.textui.TestRunner.run(BuildMedia.class); } } ///:~ junhong 2006-04-10 23:51 发表评论 Design Pattern with java (part two) junhong — Mon, 10 Apr 2006 15:23:00 GMT Encapsulating creation Although only the Simple Factory Method is a true singleton, you’ll find that each specify factory class in the more general types of factories will only have a single instance. Simple Factory method One approach is to make the factory a static method of the base class: //: factory:shapefact1:ShapeFactory1.java // A simple static factory method. package factory.shapefact1; import java.util.*; import junit.framework.*; abstract class Shape { public abstract void draw(); public abstract void erase(); public static Shape factory(String type) { if(type.equals("Circle")) return new Circle(); if(type.equals("Square")) return new Square(); throw new RuntimeException( "Bad shape creation: " + type); } } class Circle extends Shape {Circle() {} // Package-access constructor public void draw() { System.out.println("Circle.draw"); } public void erase() { System.out.println("Circle.erase"); } } class Square extends Shape { Square() {} // Package-access constructor public void draw() { System.out.println("Square.draw"); } public void erase() { System.out.println("Square.erase"); } } public class ShapeFactory1 extends TestCase { String shlist[] = { "Circle", "Square", "Square", "Circle", "Circle", "Square" }; List shapes = new ArrayList(); public void test() { Iterator it = Arrays.asList(shlist).iterator(); while(it.hasNext()) shapes.add(Shape.factory((String)it.next())); it = shapes.iterator(); while(it.hasNext()) { Shape s = (Shape)it.next(); s.draw(); s.erase(); } } public static void main(String args[]) { junit.textui.TestRunner.run(ShapeFactory1.class); } } ///:~ To encourage creation to only happen in the factory( ), the constructors for the specific types of Shape are give package access, so factory( ) has access to the constructors but they are not available outside the package. Polymorphic factories different types of factories can be subclassed from the basic factory,for example interface Shape { void draw(); void erase(); } abstract class ShapeFactory { protected abstract Shape create(); private static Map factories = new HashMap(); public static void addFactory(String id, ShapeFactory f) { factories.put(id, f); } // A Template Method: public static final Shape createShape(String id) { if(!factories.containsKey(id)) { try { // Load dynamically Class.forName("factory.shapefact2." + id); } catch(ClassNotFoundException e) { throw new RuntimeException( "Bad shape creation: " + id); } // See if it was put in: if(!factories.containsKey(id)) throw new RuntimeException( "Bad shape creation: " + id); } return ((ShapeFactory)factories.get(id)).create(); } } class Circle implements Shape { private Circle() {} public void draw() { System.out.println("Circle.draw"); } public void erase() { System.out.println("Circle.erase"); } private static class Factory extends ShapeFactory { protected Shape create() { return new Circle(); } } static { ShapeFactory.addFactory( "Circle", new Factory()); } } ....... Abstract factories The Abstract Factory pattern looks like the factory objects we’ve seen previously, with not one but several factory methods. Each of the factory methods creates a different kind of object. The idea is that at the point of creation of the factory object, you decide how all the objects created by that factory will be used. As another example suppose you are creating a general-purpose gaming environment and you want to be able to support different types of games interface Obstacle { void action(); } interface Player { void interactWith(Obstacle o); } class Kitty implements Player { public void interactWith(Obstacle ob) { System.out.print("Kitty has encountered a "); ob.action(); } } class KungFuGuy implements Player { public void interactWith(Obstacle ob) { System.out.print("KungFuGuy now battles a "); ob.action(); } } class Puzzle implements Obstacle { public void action() { System.out.println("Puzzle"); } } class NastyWeapon implements Obstacle { public void action() { System.out.println("NastyWeapon"); } } // The Abstract Factory: interface GameElementFactory {Player makePlayer(); Obstacle makeObstacle(); } // Concrete factories: class KittiesAndPuzzles implements GameElementFactory { public Player makePlayer() { return new Kitty(); } public Obstacle makeObstacle() { return new Puzzle(); } } class KillAndDismember implements GameElementFactory { public Player makePlayer() { return new KungFuGuy(); } public Obstacle makeObstacle() { return new NastyWeapon(); } } class GameEnvironment { private GameElementFactory gef; private Player p; private Obstacle ob; public GameEnvironment( GameElementFactory factory) { gef = factory; p = factory.makePlayer(); ob = factory.makeObstacle(); } public void play() { p.interactWith(ob); } } public class Games extends TestCase { GameElementFactory kp = new KittiesAndPuzzles(), kd = new KillAndDismember(); GameEnvironment g1 = new GameEnvironment(kp), g2 = new GameEnvironment(kd); // These just ensure no exceptions are thrown: public void test1() { g1.play(); } public void test2() { g2.play(); } public static void main(String args[]) { junit.textui.TestRunner.run(Games.class); } } ///:~ In this environment, Player objects interact with Obstacle objects, but there are different types of players and obstacles depending on what kind of game you’re playing. You determine the kind of game by choosing a particular GameElementFactory, and then the GameEnvironment controls the setup and play of the game. In this example, the setup and play is very simple, but those activities (the initial conditions and the state change) can determine much of the game’s outcome. Here, GameEnvironment is not designed to be inherited, although it could very possibly make sense to do that. junhong 2006-04-10 23:23 发表评论 Design Pattern with java (part one) junhong — Sun, 09 Apr 2006 09:15:00 GMT Messager The most trivial of these is the messenger, which simply packages information into an object to be passed around, instead of passing all the pieces around separately. Note that without the messenger, the code for translate() would be much more confusing to read: Collecting Parameter Messenger’s big brother is the collecting parameter, whose job is to capture information from the method to which it is passed. Generally, this is used when the collecting parameter is passed to multiple methods, so it’s like a bee collecting pollen. A container makes an especially useful collecting parameter, since it is already set up to dynamically add objects. Object quantity:Singleton and object pool Singleton:The key to creating a singleton is to prevent the client programmer from having any way to create an object except the ways you provide. You must make all constructors private, and you must create at least one constructor to prevent the compiler from synthesizing a default constructor for you (which it will create using package access). Object pool:If this is an issue, you can create a solution involving a check-out and check-in of the shared objects. see the following example //: singleton:PoolManager.java package singleton; import java.util.*; public class PoolManager { private static class PoolItem { boolean inUse = false; Object item; PoolItem(Object item) { this.item = item; } } private ArrayList items = new ArrayList(); public void add(Object item) { items.add(new PoolItem(item)); } static class EmptyPoolException extends Exception {} public Object get() throws EmptyPoolException { for(int i = 0; i < items.size(); i++) { PoolItem pitem = (PoolItem)items.get(i); if(pitem.inUse == false) { pitem.inUse = true; return pitem.item; } } // Fail early: throw new EmptyPoolException(); // return null; // Delayed failure } public void release(Object item) { for(int i = 0; i < items.size(); i++) { PoolItem pitem = (PoolItem)items.get(i); if(item == pitem.item) { pitem.inUse = false; return; } } throw new RuntimeException(item + " not found"); } } ///:~ //: singleton:ConnectionPoolDemo.java package singleton; import junit.framework.*; interface Connection { Object get(); void set(Object x); } class ConnectionImplementation implements Connection { public Object get() { return null; } public void set(Object s) {} } class ConnectionPool { // A singleton private static PoolManager pool = new PoolManager(); public static void addConnections(int number) { 17 z 157 for(int i = 0; i < number; i++) pool.add(new ConnectionImplementation()); } public static Connection getConnection() throws PoolManager.EmptyPoolException { return (Connection)pool.get(); } public static void releaseConnection(Connection c) { pool.release(c); } } public class ConnectionPoolDemo extends TestCase { static { ConnectionPool.addConnections(5); } public void test() { Connection c = null; try { c = ConnectionPool.getConnection(); } catch (PoolManager.EmptyPoolException e) { throw new RuntimeException(e); } c.set(new Object()); c.get(); ConnectionPool.releaseConnection(c); } public void test2() { Connection c = null; try { c = ConnectionPool.getConnection(); } catch (PoolManager.EmptyPoolException e) { throw new RuntimeException(e); } c.set(new Object()); c.get(); ConnectionPool.releaseConnection(c); } public static void main(String args[]) { junit.textui.TestRunner.run(ConnectionPoolDemo.class); } } ///:~ Object decoupling:Both Proxy and State provide a surrogate class that you use in your code; the real class that does the work is hidden behind this surrogate class.When you call a method in the surrogate, it simply turns around and calls the method in the implementing class. These two patterns are so similar that the Proxy is simply a special case of State. The basic idea is simple: from a base class, the surrogate is derived along with the class or classes that provide the actual implementation: When a surrogate object is created, it is given an implementation to which to send all of the method calls. Structurally, the difference between Proxy and State is simple: a Proxy has only one implementation, while State has more than one. The application of the patterns is considered (in Design Patterns) to be distinct: Proxy is used to control access to its implementation, while State allows you to change the implementation dynamically. However, if you expand your notion of “controlling access to implementation�?then the two fit neatly together. State: changing object behavior The State pattern switches from one implementation to another during the lifetime of the surrogate, in order to produce different behavior from the same method call(s). It’s a way to improve the implementation of your code when you seem to be doing a lot of testing inside each of your methods before deciding what to do for that method. For example, the fairy tale of the frog-prince contains an object (the creature) that behaves differently depending on what state it’s in. You could implement this using a boolean that you test: Factoring commonality Applying the “once and only once�?principle produces the most basic pattern of putting code that changes into a method. Strategy: choosing the algorithm at run-time Strategy also adds a “Context�?which can be a surrogate class that controls the selection and use of the particular strategy object—just like State! Policy: generalized strategy Although GoF says that Policy is just another name for strategy, their use of Strategy implicitly assumes a single method in the strategy object �?that you’ve broken out your changing algorithm as a single piece of code. Others[6] use Policy to mean an object that has multiple methods that may vary independently from class to class. This gives more flexibility than being restricted to a single method. It also seems generally useful to distinguish Strategies with single methods from Policies with multiple methods Template method An important characteristic of the Template Method is that it is defined in the base class and cannot be changed. It's sometimes a private method but it’s virtually always final. It calls other base-class methods (the ones you override) in order to do its job, but it is usually called only as part of an initialization process (and thus the client programmer isn’t necessarily able to call it directly). E.g abstract class ApplicationFramework { public ApplicationFramework() { templateMethod(); // Dangerous! } abstract void customize1(); abstract void customize2(); final void templateMethod() { for(int i = 0; i < 5; i++) { customize1(); customize2(); } } } // Create a new "application": class MyApp extends ApplicationFramework { void customize1() { System.out.print("Hello "); } void customize2() { System.out.println("World!"); } } junhong 2006-04-09 17:15 发表评论 junhong — Tue, 07 Mar 2006 01:04:00 GMT 本�h写的分页的标�{�，�?net中的datagrid标签�怼��Q�只需要设�|�几个属性就可以实现分页功能了，��单方便，�q�且效率很高�?br />我写的有两种分页的标�{�，一�U�是全部select 出来�Q�然后再分页的，�q�个�pȝ��在第一�ơ访问的时候可能有�Ҏ��,但是在随后的讉K��可是很快的，因�ؓ数据已经都缓存以来的�Q��ƈ且是在pageContext中的�Q�所以不会占用很多的资源。第二种是部分select 出来的，效率很高。如果有需要的朋友�Q�请留下Email地址�?br />惌��源代码的朋友请和我联�p�R�?br />大家可以把用的情�늻�我说一下，以便我做��整�?br /> 本程序作了升�U�，请大家下载下边的�q�个�q�接�q�行下蝲�Q�以便��用最新的版本�?br />�q�次升��修复了几个bugs. 请下载Splitpage.rar junhong 2006-03-07 09:04 发表评论