Dedian  
          -- 關注搜索引擎的開發
          日歷
          <2025年6月>
          25262728293031
          1234567
          891011121314
          15161718192021
          22232425262728
          293012345
          統計
          • 隨筆 - 82
          • 文章 - 2
          • 評論 - 228
          • 引用 - 0

          導航

          常用鏈接

          留言簿(8)

          隨筆分類(45)

          隨筆檔案(82)

          文章檔案(2)

          Java Spaces

          搜索

          •  

          積分與排名

          • 積分 - 65915
          • 排名 - 816

          最新評論

          閱讀排行榜

          評論排行榜

           

          Though Eclipse Monkey is a tool under project Dash, which seems to used by those committers of Eclipse community, it?sounds good?for?the automation of routine programming tasks. Anyway, I need check it out for my benefits.
          posted @ 2006-04-21 09:28 Dedian 閱讀(249) | 評論 (0)編輯 收藏
           
          Purpose:
          Defines a higher-level interface to hide subsystem's complexities and provides an easy interface for client to use.

          Case study:
          Compiler subsystem

          Structure:
          -- The facade and backend classes(subsystem classes) are in a separate package from the client.
          -- The backend API is package-private
          -- The facade API is public.

          Implementation:
          consider following two issues when implementing a facade:
          -- Reducing client-subsystem coupling.
          -- Public versus private subsystem classes.

          reference:
          http://www.allapplabs.com/java_design_patterns/facade_pattern.htm
          posted @ 2006-04-20 10:04 Dedian 閱讀(208) | 評論 (0)編輯 收藏
           
          Purpose:
          Attach additional responsiblities to an object dynamically, which thus provide a flexible alternative to subclassing for extending functionality.

          Structure:
          Typically, there will be a parameter to pass original object to decorator object in its constructor, then decorator can implement additional functions within its own interface and apply to original object.

          when to use:

          -- when subclassing is not avaible
          -- when the responsibilities (for different functions) are required flexiable and dynamical
          -- can not predict combination of extending functionality. (We can not design subclasses for all combination of potential additional functionalities at compile time)

          reference:
          Book: Design Pattern (GoF)
          http://en.wikipedia.org/wiki/Decorator_pattern
          posted @ 2006-04-20 08:53 Dedian 閱讀(235) | 評論 (0)編輯 收藏
           
          Purpose:
          Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compostions of objects uniformly.

          Structure:
          The composite object contains other primitive objects(or say Components), and has the same operation as in those primitive objects. Thus we can operater the composite object with the same operations as a whole. Or in other word, composite object is a container of primitive ojects and itself is derived from same base (abstract) class as primitives, so that it can have same operations as primitives. Actually, we can say that the abstract class represents both primitives and their containers

          Implementation:
          -- Extend a base class that represents primitive objects. And the same operation(override function) will be implemented by iterating over that collection and invoking the appropriate method for each component in the collection.
          -- Add & Remove function (for component collection) will be defined in base class, though it is meaninglessful for leaf classes.

          reference:
          http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns.html
          http://www.codeproject.com/useritems/Composite.asp

          example:
          http://java.sun.com/blueprints/patterns/CompositeView.html
          posted @ 2006-04-20 08:52 Dedian 閱讀(235) | 評論 (0)編輯 收藏
           
          Purpose:
          Decouple an abstraction from its implementation so that the two can vary independently.

          To think about this situation that an abstract class has two categories of inheritance. Each category can be a seperate hierarchical inheritance?tree, if we?derive all the subclasses from the abstract class, it will make complex?when we need to get some sub-classes that contains facades from two categories. So we need seperate those subclasses into differenct categories, typically one into implementation hierarchy while another into abstraction hierarchy which can?employ subclasses of implementation hierarchy. No matter how, the relationship between different hierarchies is a bridge. From this point, the bridge pattern design lets different hierarchies can evolve seperately.

          The structure of the Adapter Pattern (object adapter) may look similar to the Bridge Pattern. However, the adapter is meant to change the interface of an existing object and is mainly intended to make unrelated classes work together.

          reference:
          book:"Design Patterns” Gamma et al.
          http://en.wikipedia.org/wiki/Bridge_pattern
          http://www.c-sharpcorner.com/Language/BridgePatternsinCSRVS.asp
          http://www.codeproject.com/gen/design/bridge.asp
          posted @ 2006-04-19 20:52 Dedian 閱讀(235) | 評論 (0)編輯 收藏
           
          Purpose: Adapters are used to enable objects with different interfaces to communicate with each other which convert the interface of a class into another interface clients expect thus let classes work together without imcompatible interfaces problem.

          Object Adapter:

          -- use compositional technique
          -- by composing interface B's instance within interface A (target interface, adapter) and implement interface A in terms of B's interface(adaptee). Interface A is Object Adapter which enables the client (the class or object to use Interface A) and the adaptee(Interface B) to be completely decoupled from each other.

          Class Adapter:

          -- use multiple inheritance
          -- Notice that Java is not supporting true multiple inheritance, there must be one inheritance is from Java Interface(implementation) not Java class. So take above Object Adapter as example, if client want to access Interface B, the adpater Interface A will inherit from class(Class Adapter) which Client can access, and inherit the implementation of Interface B(Adaptee). So Interface A can have a funtion to call functions in Interface B, and so that Interface will not have an object of Interface B, that is the difference from Object Adapter method.

          reference:
          http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/adapter.htm

          posted @ 2006-04-19 20:37 Dedian 閱讀(300) | 評論 (0)編輯 收藏
           
          The main purpose of Factory method is to create objects. There will be one product instant creation function (Factory Method) in the abstract class(Creator), which can be overrided by its subclasses(Concrete Creator) and thus products can be specified in subclasses.

          reference:

          http://gsraj.tripod.com/design/creational/factory/factory.html
          http://en.wikipedia.org/wiki/Factory_method_pattern
          http://www.developer.com/java/other/article.php/626001
          http://www.javacamp.org/designPattern/factory.html
          posted @ 2006-04-19 20:33 Dedian 閱讀(265) | 評論 (0)編輯 收藏
           
          在軟件工程里,兩者并不矛盾。只是側重點會不一樣,根據每個人的職位。如果我是一個構架師,我會偏重在前者,如果我是一個模塊程序員,我會偏重后者。

          最近,在看兩本書:
          《Code Complete》
          《Design Pattern》

          兩本都是很經典的書。尤其是后者,由著名的“四人幫”(GoF:Gang of Four)所著。是在軟件總體設計和詳細設計時應該好好參照的一本書。而前者,這是注重實效編程(Pragmatic Programming)的一本啟發性的書。

          在不斷追求最新技術的今天,靜下心來讀這兩本書,尤其前者啟發性的書,往往獲益匪淺。溫故而知新。
          posted @ 2006-04-19 20:15 Dedian 閱讀(130) | 評論 (0)編輯 收藏
           
          I feel interested in Rail, which is web-application and persistence framework that includes everything needed to create database-backed web-applications according to the Model-View-Control pattern of separation.

          here is good article for getting start with Rails on my Linux machine.
          posted @ 2006-04-19 02:32 Dedian 閱讀(119) | 評論 (0)編輯 收藏
           
          Here are some hints for difference between abstract classes and interfaces

          1. Use Interface if something will change frequently in design
          2. If the methods can be determined and implemented, use abstract classes to encapsulate them as methods of base classes and therefore can be inherited by subclasses.
          3. If you just want to declare some methods in your design which allows to be devoloped from scratch later into different classes, the interface is best choice.
          4. if need provide more common data structure, use abstract classes as base class.
          5. if want to add your code to other existing third party class for later potential requirement, interface is good to choose.
          6. Interfaces are often used to describe certain functionality of classes, thus one class can get multi-funcationlity from multiple interfaces (multiple inheritance), while an abstract class, try to describe a class's general attributes and functionalities which can be reused or re-implemented by its subclasses.
          7. in other word, Abstract class want to say is-a proposition, while Interface want to say -able or can-do proposition.

          reference:
          http://mindprod.com/jgloss/interfacevsabstract.html
          http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html
          posted @ 2006-04-19 02:15 Dedian 閱讀(265) | 評論 (0)編輯 收藏
           

          Follow is some guy's complaint for Java programming...
          somehow, it is true, but only true. I'd like to say that no language is perfect...

          Quote:

          Java is a poor programming language.

          There, I said it. I've been using Java since it first became generally available and my opinion of it has, if anything, lessened over the years. Just off the top of my head, the major problems include:

          Enforcing a Single Paradigm
          Object oriented techniques provide some powerful mechanisms for managing dependencies between components of a software system, but they are not the only useful techniques. Languages that support multiple paradigms, including functional approaches, are much more powerful.
          Limited Object Model
          Actually, the term "single paradigm" above is overstating the case. Java is a partial paradigm language, supporting only a subset of OO. Single inheritance of implementation (prohibiting mix-ins) and no support for multiple dispatch are significant restrictions.
          Not only is Java's object model limited, it is inconsistent. Consider int vs. Integer for just one example.
          Bondage & Discipline
          Some programmers will argue in favor of restrictions like single inheritance as enforcing the "right" way to develop software. Those programmers are welcome to tie themselves up and hand Duke a riding crop, but I want a language that empowers developers, not one that constrains them.
          Generics
          The implementation of generics in 1.5 is what one would expect from a partial-paradigm language: a large increase in complexity in exchange for minimal benefit.
          No Destructors
          Resource Acquisition Is Initialization (RAII) is a very useful pattern that can only be implemented clumsily in Java.
          Verbosity
          Java is verbose. Java is painfully verbose. Java is incredibly, unnecessarily, excrutiatingly painfully verbose. Part of this verbosity is due to its type system. A significant additional influence is the requirement to declare exceptions and the proliferation of try/catch blocks.
          Lack of Expressiveness
          Java's verbosity and limited object model make it an inexpressive language. These problems could be ameliorated if it were possible to manipulate the language somehow, but Java doesn't provide support for Lisp-like macros. Or C-like macros. Heck, it doesn't even have typedef.
          Given the ever increasing complexity in each release, Java is well on its way to becoming the COBOL of the noughties.
          Nothing New
          The most damning criticism of Java is that it doesn't progress the state of the art. When Alexander Stepanov was asked about his use of Java, his response was "For the first time in my life, programming in a new language did not bring me new insights." Juxtapose that with Alan Perlis' famous quote: "A language that doesn't affect the way you think about programming, is not worth knowing."

          Despite these issues and many others, Java does have one saving grace: support for mobile code. Jini is a truly innovative technology for developing large, distributed, mission-critical systems. Retrieving proxies or entire services at runtime is only possible because Java classes can be serialized and dynamically loaded.

          The ability to build scalable, resilient, performant, and extensible service oriented architectures without the need for SOAP, UDDI, and WSDL makes up for a multitude of sins.

          posted @ 2006-04-19 02:13 Dedian 閱讀(185) | 評論 (0)編輯 收藏
           

          Default Key Bindings provided by Eclipse
          1. Ctrl?& Shift?&? T: Open type.
          2. Ctrl &??Shift?- ?R:Open resource
          3. F3 :Open declaration
          4. Ctrl?& Shift?&??G: Open references
          5. Alt??&??Up/Down Arrow : Moves the line up/down
          6. Alt?&? Left/Right Arrow : Moves sequentially to the last edited location


          Customized Key Bindings:
          1. F4 : Close Project
          2. Shift?& F4 : Open Project
          3. Ctrl??& + : Generate Getter Setters
          4. Ctrl?& Alt?& k : Surround with try-catch
          posted @ 2006-04-19 02:12 Dedian 閱讀(169) | 評論 (0)編輯 收藏
           
          Longer I use Java, more curiously I wanna compare J2EE to .Net.
          here is a good article (though a little bit old)?to speak out my thinking.
          posted @ 2006-04-19 02:11 Dedian 閱讀(149) | 評論 (0)編輯 收藏
           
          1. Program Organization
          2. Major classes
          3. Data Design
          4. Business Rules
          5. User Interface Design
          6. Resource Management
          7. Security
          8. Performance
          9. Scalability
          10. Interoperability
          11. Internationalization/Localization
          12. Input/Output
          13. Error Processing
          14. Fault Tolerance
          15. Architectural Feasiblility
          16. Overengineering
          17. Buy- vs. -Build Decisions
          18. Reuse Decisions
          19. Change Strategies
          ?
          -- quote from <Code Complete>
          posted @ 2006-04-19 02:07 Dedian 閱讀(142) | 評論 (0)編輯 收藏
           
          If you have been using another computer language, you will always think about similar mechanism when using a new language, well, here is question when I want to use enum type in Java just like in C...
          ?
          and here is good article to talk about that issue.
          posted @ 2006-04-19 02:06 Dedian 閱讀(101) | 評論 (0)編輯 收藏
          僅列出標題
          共6頁: 上一頁 1 2 3 4 5 6 下一頁 
           
          Copyright © Dedian Powered by: 博客園 模板提供:滬江博客
          主站蜘蛛池模板: 台湾省| 抚宁县| 浦北县| 鲁山县| 威海市| 东宁县| 炉霍县| 海淀区| 青川县| 同德县| 宜兰县| 信丰县| 宁津县| 昭苏县| 霸州市| 宁远县| 苍山县| 衡阳市| 海阳市| 浦东新区| 砚山县| 德阳市| 抚州市| 中阳县| 湖州市| 淮北市| 望江县| 灵武市| 双桥区| 漳平市| 察隅县| 简阳市| 化隆| 奉节县| 开鲁县| 德化县| 天全县| 恭城| 壶关县| 平和县| 隆回县|