Dedian |
|
|||
-- 關注搜索引擎的開發 |
日歷
統計
導航常用鏈接留言簿(8)隨筆分類(45)
隨筆檔案(82)
文章檔案(2)Java Spaces搜索積分與排名
最新評論
閱讀排行榜評論排行榜 |
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.
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 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 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 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 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 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 最近,在看兩本書: 《Code Complete》 《Design Pattern》 兩本都是很經典的書。尤其是后者,由著名的“四人幫”(GoF:Gang of Four)所著。是在軟件總體設計和詳細設計時應該好好參照的一本書。而前者,這是注重實效編程(Pragmatic Programming)的一本啟發性的書。 在不斷追求最新技術的今天,靜下心來讀這兩本書,尤其前者啟發性的書,往往獲益匪淺。溫故而知新。 here is good article for getting start with Rails on my Linux machine. 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 Follow is some guy's complaint for Java programming... 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:
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. Default Key Bindings provided by Eclipse 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 here is a good article (though a little bit old)?to speak out my thinking.
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>
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.
|
![]() |
|
Copyright © Dedian | Powered by: 博客園 模板提供:滬江博客 |