apt-get update
apt-get upgrade
apt-get install build-essential
curl -sSL https://rvm.io/mpapis.asc | gpg --import -
curl -sSL https://get.rvm.io | bash -s stable
rvm install 2.2.2
rvm use 2.2.2 --default
apt-get install apache2
passenger-install-apache2-module
Ok, let’s go. First, we’ll have to deal with dependencies : we need some basic stuff to display messages in the console :
// Include standard headers
#include <stdio.h>
#include <stdlib.h>
uiFaces
Dùng trong trường hợp muốn tạo ra một loạt avatar dùng cho demo vân vân.
Có tích hợp cả API, rất đáng để dùng thử.
mazwai
Toàn là video nhìn rất cool.
jQuery video background plugin
https://github.com/VodkaBears/Vide
iconfinder
html5up
startbootstrap
blacktie
Squarespace (Recommend)
http://www.squarespace.com/logo#
LOGASTER
Animate.css (Recommend)
http://daneden.github.io/animate.css/
coveloping (Recommend)
Tập hợp rất nhiều công cụ dùng để sinh ra các phần trong trang HTML như price page vân vân.
TeamPage.io
Tạo team member page một cách rất đơn giản.
FRAME
Sinh ra 1 top page na ná như trang đó.
UICloud
Trang chuyên dùng cho việc search tham khảo những thành phần của UI.
$ sudo apt-get install freeglut3-dev libglew1.5-dev
$ sudo apt-get install libxmu-dev libxi-dev
$ sudo apt-get install binutils-gold
$ cc -I/usr/X11R6/include program.c -L/usr/X11R6/lib -lglut -lGLU -lGL -lXmu -lXi -lXext -lX11 -lm -lpthread
$ function ccgl() { cc -I/usr/X11R6/include "$@" -L/usr/X11R6/lib -lglut -lGLU -lGL -lXmu -lXi -lXext -lX11 -lm -lpthread; }
$ ccgl program.c
Định nghĩa một interface cho việc tạo ra một đối tượng, nhưng để cho các lớp con quyết định lớp nào sẽ tạo đối tượng. Factory Method cho phép một lớp hoãn việc tạo đối tượng sang các lớp con.
Interviewer Chà chà, chào hai anh, đây là lần đầu tiên blog của iem phỏng vấn hai anh, hai anh cảm thấy thế nào.
Factory Method Tôi ko biết sao hay bị gộp chúng với cha Abstract Factory. Đều là factory pattern không có nghĩa chúng tôi không được có những buổi phỏng vấn riêng.
Interviewer Ấy ấy, đừng tự ái, em muốn phỏng vấn cả hai anh cùng nhau để giúp đọc giả phân biệt được ai là ai. Hai anh có nhiều điểm giống nhau, và em có nghe vài phàn nàn rằng người ta thỉnh thoảng bị rối và không thể phân biệt được 2 người.
Abstract Factory Ừ đúng đấy, đã có lúc tôi bị nhầm lẫn là cha Factory Method, và tôi biết ổng cũng bị giống như tôi. Hai tụi tôi đều giỏi trong việc giảm sự phụ thuộc giữa chương trình với những cài đặt cụ thể; nhưng mỗi người chúng tôi lại có những cách làm riêng nên thỉnh thoảng dân lập trình lại cảm thấy rối và không thể xác định được phải dùng cách nào.
Factory Method Ấy, người ta vẫn phân biệt được tôi mà. Nói chung, tôi dùng các lớp để tạo ra products, còn cha dùng những đối tượng; hai cách đó hoàn toàn khác nhau nhé.
Interviewer Ừ em có tìm hiểu về hai anh rồi mà vẫn còn rối đây này, anh có thể nói thêm về khoản này không, anh Factory Method?
Factory Method Ok, Cả cha Abstract Factory và tôi đều tạo ra các products, các objects, đó là việc chúng tôi phải làm. Nhưng tôi làm nhờ vào sự kế thừa (inheritance) …
Abstract Factory … còn tôi làm nhờ vào sự kết hợp các đối tượng.
Factory Method Đúng thía, nghĩa là nếu muốn tạo ra các đối tượng bằng cách Factory Method, người ta cần phải extend một lớp và override lại hàm tạo Factory Method.
Interviewer …rồi Factory Method sẽ làm cái gì?
Factory Method Tất nhiên là tạo ra 1 object roài, anh đã từng viết bài về tôi mà giờ còn hỏi hả. Ý tưởng của tôi, Factory Method Pattern, là sẽ sử dụng các lớp con để sinh ra 1 đối tượng mong muốn. Bằng cách đó, người dùng sẽ chỉ cần biết đến lớp trừu tượng như gia cầm, và các lớp con cụ thể sẽ lo về các kiểu gà, kiểu vịt, kiểu ngan. Vì vậy, nói theo cách khác, tôi giúp chương trình độc lập với các kiểu (type) cụ thể đó.
Abstract Factory Ý tưởng của tôi cũng giống giống vậy đó, nhưng chỉ là làm theo một cách khác…
Interviewer Tiếp đi anh Abstract Factory … vừa rồi anh có đề cập đến cách kết hợp các đối tượng?
Abstract Factory Ờ,cách của tôi thế này: Tôi tạo ra một kiểu trừu tượng (abstract type) để dùng vào việc tạo ra một nhóm những products khác. Khi đó, những lớp con của kiểu trừu tượng sẽ xác định cách tạo ra các products này. Để áp dụng được ý tưởng của tôi, bạn phải tạo ra một instance của một trong các lớp con trên (instance này là 1 factory) và đưa nó vào chỗ cần thiết trong code. Vì thế, giống như Factory Method, những nơi sử dụng factory của tôi sẽ hoàn toàn độc lập với những produtcts cụ thể.
Interviewer Oh yè, tôi biết rồi, một lợi ích nữa của cách này là anh đã nhóm các products tương tự nhau lại, có đúng không?
Abstract Factory Đúng roài cưng à.
Interviewer Bây giờ người ta cần bổ sung thêm một product nữa vô nhóm các products mà anh có thể tạo ra. Vậy không cần phải thay đổi gì hết huh?
Abstract Factory Hèm, trường hợp này thì tôi phải thay đổi chút ít, nhiều người không thích lắm ở điểm này.
Factory Method hĩ hĩ
Abstract Factory Cười gì cha nội?
Factory Method Cười chứ sao ko cười, làm vậy quá mất công chứ gì nữa. Cha thay đổi có nghĩa là người dùng phải đi mà đổi tất cả các lớp con roài? (các lớp con ở đây là các factories)
Abstract Factory Đúng, nhưng cần phải làm như vậy vì tôi có khả năng tạo ra nhiều kiểu product khác nhau, trong khi người ta xài cách của anh khi họ cần tạo ra một kiểu product nào đó thôi, vì thế anh không có cồng kềnh như tôi, anh chỉ cần một method duy nhất.
Interviewer Anh Abstract Factory bớt nóng, tôi nghe đồn rằng anh thường sử dụng nhiều hàm Factory Method theo cách của anh Factory Method để tạo các đổi tượng bên trong những factories của anh, điều đó có đúng ko?
Abstract Factory Đúng đó em, anh thừa nhận điêu này. Những lớp factory con thường dùng các Factory Method để tạo các products tương ứng. Trong trường hợp này, các Factory Method được dùng thuần túy để tạo ra các products.
Factory Method … còn tôi dùng hàm Factory Method để tạo ra product cụ thể mà người ta muốn, người dùng sẽ không biết cái gì được tạo ra, họ chỉ cần gọi hàm.
Interviewer Dường như hai anh làm rất tốt công việc của mình. Tôi chắc rằng đọc giả đã có được lựa chọn của mình. Sau cùng, những factories của 2 anh quả thật rất hữu ích, đọc giả của tôi sẽ sử dụng chúng trong các tình huống thích hợp nhất. Các anh đều đóng gói (encapsulate) quá trình tạo ra đối tượng để giúp chương trình độc lập và giảm phụ thuộc với những kiểu cụ thể, việc làm này thật đáng tuyên dương. Cám ơn hai anh, hai anh có lời gì trước khi chào tạm biệt đọc giả không ạ?
Abstract Factory Cám ơn. Hãy nhớ đến tôi, Abstract Factory, và sử dụng tôi bất cứ khi nào bạn cần cùng một lúc tạo ra nhiều loại products, và khi bạn muốn chắc chắn những nơi sử dụng sẽ không cần biết đến những lớp cụ thể khi cần làm việc này.
Factory Method Còn tôi là Factory Method, hãy sử dụng tôi để làm cho chương trình của bạn độc lập với những lớp cụ thể mà bạn cần tạo 1 đối tượng, hoặc khi bạn không biết sau này sẽ cần đến những lớp con nào nữa. Khi cần sử dụng tôi, hãy tạo tạo ra subclass (1 factory implement 1 kiểu abstract) và implement Factory Method cho chính bạn.
(Page 158-162 of Head First – Design Pattern)
The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn’t know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products.This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a number of products (e.g. createLetter() and createResume()). The system would have any number of derived concrete versions of the DocumentCreator class like FancyDocumentCreator or ModernDocumentCreator, each with a different implementation of createLetter() and createResume() that would create a corresponding object like FancyLetter or ModernResume. Each of these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the resulting objects would be created from the same DocumentCreator implementation and would share a common theme (they would all be fancy or modern objects). The client would only need to know how to handle the abstract Letter or Resume class, not the specific version that it got from the concrete factory.
A factory is the location of a concrete class in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage and to create families of related objects without having to depend on their concrete classes.This allows for new derived types to be introduced with no change to the code that uses the base class.
Use of this pattern makes it possible to interchange concrete implementations without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code. Additionally, higher levels of separation and abstraction can result in systems which are more difficult to debug and maintain.
Factory design pattern phải đảm bảo được những yếu tố sau:
Việc triển khai này thực sự rất đơn giản, nó bao gồm những bước sau:
Ví dụ về một ứng dụng có chức năng tạo giao diện GUI. Ứng dụng của bạn sẽ có một client, GUIs là những product. Tất cả những GUI này đều có nguồn gốc từ một abstract class(hoặc một interface). GUI class này định nghĩa ra Button hay Label theo mỗi loại máy tính cụ thể. Giả sử có lệnh từ client là tạo Button và Label cho máy Windows, trong source code bạn phải nhận diện được kiểu máy tính như là một tham số, sau đó sẽ gọi đến Factory để thực hiện tạo ra giao diện tương ứng, ở đây là cho máy Windows. Như vậy, phía client hoàn toàn không cần quan tâm đến việc thực hiện tạo ra giao diện là như thế nào. Đó chính là mục đích của Factory Design Pattern.
Lợi ích ở đây chính là việc một hay nhiều loại máy tính mới có thể được thêm vào mà không cần phải sửa lại source code của ứng dụng quá nhiều. Việc thay đổi source code hoàn toàn không ảnh hưởng đến factory class.
GuiFactory example
interface Button {
void paint();
}
interface Label {
void paint();
}
interface GUIFactory {
Button createButton();
Label createLabel();
}
class WinFactory implements GUIFactory {
public Button createButton() {
return new WinButton();
}
public Label createLabel() {
return new WinLabel();
}
}
class OSXFactory implements GUIFactory {
public Button createButton() {
return new OSXButton();
}
public Label createLabel() {
return new OSXLabel();
}
}
class OSXButton implements Button {
public void paint() {
System.out.println("I'm an OSXButton");
}
}
class WinButton implements Button {
public void paint() {
System.out.println("I'm a WinButton");
}
}
class OSXLabel implements Label {
public void paint() {
System.out.println("I'm an OSXLabel");
}
}
class WinLabel implements Label {
public void paint() {
System.out.println("I'm a WinLabel");
}
}
Client application không quan tâm làm thế nào mà sản phẩm được tạo ra. Nó chỉ chịu trách nhiệm nhận về tên của Concrete Factory
class Application {
public Application(GUIFactory factory) {
Button button = factory.createButton();
Label label = factory.createLabel();
button.paint();
label.paint();
}
}
public class ApplicationRunner {
public static void main(String[] args) {
new Application(createOsSpecificFactory());
}
public static GUIFactory createOsSpecificFactory() {
String osname = System.getProperty("os.name").toLowerCase();
if(osname != null && osname.contains("windows"))
return new WinFactory();
else
return new OSXFactory();
}
}
public class App {
public static void main(String[] args) {
createKingdom(new ElfKingdomFactory());
createKingdom(new OrcKingdomFactory());
}
public static void createKingdom(KingdomFactory factory) {
King king = factory.createKing();
Castle castle = factory.createCastle();
Army army = factory.createArmy();
System.out.println("The kingdom was created.");
System.out.println(king);
System.out.println(castle);
System.out.println(army);
}
}
Quan hệ giữa các class trong UML, gồm có các 4 quan hệ chính sau:
Là quan hệ giữa một classifier đóng vai trò là hợp đồng và một classifier đóng vai trò thực hiện. Hay nói cách khác:
Mối quan hệ giữa 1 class implement 1 interface được gọi là quan hệ realization, được biểu diễn bởi đường đứt nét có hình mũi tên tam giác chỉ vào interface.
Còn có tên khác là:
Đối tượng cụ thể (concrete) sẽ kế thừa các thuộc tính và phương thức của đối tượng tổng quát (general)
Ký hiệu: A is-a B
Đọc là :
Là quan hệ giữa 2 phần tử trong mô hình mà thay đổi ở phần tử này (phần tử độc lập) có thể gây ra thay đổi ở phần tử kia (phần tử phục thuộc).
Là loại quan hệ giữa 2 object
ClassA và ClassB không có quan hệ Association
Trong ClassA có sử dụng biến toàn cục (kiểu B), hoặc sử dụng phương thức/thuộc tính static của ClassB
Ký hiệu : A use-a B , bằng mũi tên 1 chiều nét đứt , từ bên phụ thuộc sang bên độc lập ;
ClassA “phụ thuộc” vào ClassB ;
Client –> Supplier (phần tử phục thuộc –> phần tử độc lập)
Dependency còn có một số biểu hiện khác , thường dùng các stereotype sau :
<<use>> : chỉ rằng ngữ nghĩa của lớp gốc (mũi tên) phụ thuộc vào lớp ngọn (mũi tên) . Đặc biệt trong trường hợp lớp gốc dùng lớp ngọn làm tham số trong 1 số method của nó
<<permit>> : chỉ rằng lớp gốc được quyền truy cập 1 cách đặc biệt vào lớp ngọn (chẳng hạn truy cập các thao tác riêng tư). Tương ứng với khái niệm friend trong C++
<<refine>> : chỉ rằng lớp gốc ở 1 mức độ tinh chế cao hơn từ lớp ngọn . Chẳng hạn 1 lớp lập ở giai đoạn thiết kế nhằn tinh chế cùng lớp đó lập ở giai đoạn phân tích
Lưu ý : Phân biệt giữa Dependency và Association
Giữa 2 object của 2 lớp có sự ghép cặp (vợ – chồng , thầy – trò , khách hàng – hóa đơn …) . Tập hợp các kết nối cùng loại (cùng ý nghĩa) giữa các object của 2 lớp tạo thành mối liên kết association , quan hệ giữa 2 tập hợp (2 lớp)
Là mỗi liên hệ giữa 2 lớp có role, role là tên vai trò của mối liên kết : vd như : của , cho , có , liên kết tới , trao đối với , …. (thường tên role có kèm theo 1 mũi tên để chỉ hướng quan hệ áp dụng từ lớp nào sang lớp nào)
Ký hiệu : A has-a B
Ý nghĩa : (trường hợp mũi tên không có chiều) - Hoặc : Trong ClassA có thuộc tính có kiểu là ClassB - Hoặc : Trong ClassB có thuộc tính có kiểu là ClassA
Nhận xét :
Multiplicity là bản số , lượng số , số object bên này tham gia vào mối kết hợp so với 1 object bên kia.Đã xác định được ClassA và ClassB có quan hệ Association với nhau
Xác định rõ hơn:
Trong object của ClassA có chứa (trong phần thuộc tính) object của ClassB
ObjectX của ClassA bị hủy thì ObjectY của ClassB (bên trong ObjectX) vẫn có thể còn tồn tại
Còn gọi là shared-aggregation.Một dạng của nối kết, trong đó một phần tử này chứa các phần tử khác.
Ký hiệu :
Ý nghĩa : còn gọi là : Whole A – Part B . Nghĩa là A được tạo từ nhiều B kết hợp lại , và B có thể tạo ra độc lập , không cần phải tạo ra A , B có thể cùng thuộc 1 whole khác A.
Chú ý : Từ share ở đây có nghĩa là , B có thể là bộ phận của whole khác, do đó A bị hủy thì chưa chắc B bị hủy .
Là loại aggregation chặt chẽ hơn , còn gọi là non-shared aggregation.
Ký hiệu :
Ý nghĩa : còn gọi là Whole A – Part B . Nghĩa là A được tạo từ nhiều B kết hợp lại , nhưng B không thể đứng 1 mình được , B chỉ là thuộc A mà thôi không thể cùng thuộc Whole khác được.
Đã xác định được ClassA và ClassB có quan hệ Association với nhau
Xác định rõ hơn:
Chú ý :
$ git clone git://github.com/imathis/octopress.git octopress
$ cd octopress
$ bundle install --path vendor/bundle
$ git clone git://github.com/lucaslew/whitespace.git .themes/whitespace
$ rake install['whitespace'] # for zsh, use: rake install\['whitespace'\]
$ rake generate
$ rake new_post['Hello world']
$ rake preview
$ rake setup_github_pages
$ rake generate
$ rake deploy