原创 使用git克隆git中子目錄項目

前言:         最近在git上clone一個關於qmlvlc的項目,發現克隆下來後有一個目錄是空,於是上網搜了下,找到如下命令: git submodule update 然後我的操作如下: lsyai@LSY-SELF-PC

原创 設計模式之 《適配器模式》

介紹 適配器模式就是把一個接口或類轉換成其他的接口或類。該模式隸屬於 {結構型模式} Target目標角色 該角色定義把其他類轉換爲何種接口,也就是我們的期望接口。   Adaptee源角色 它是已經存在的、 運行良好的類或對象。  

原创 設計模式之 《命令模式》

介紹 Receive接收者角色 該角色就是幹活的角色, 命令傳遞到這裏是應該被執行的。作爲抽象類,定義一個可接受消息的抽象類,從而保證多個不同的具體角色均可接受命令 Command命令角色 需要執行的所有命令都在這裏聲明。定義抽象類一

原创 設計模式之 《享元模式》

介紹 享元模式(Flyweight), 運用共享技術有效地支持大量細粒度的對象。[DP]享元式中, 有如下3個角色: Flyweight抽象享元角色:。 所有具體享元類的父類,規定- -些需要實現的公共接口。 ConcreteFlywe

原创 設計模式之《迭代器模式》

介紹 迭代器模式(Iterator),提供-種方法順序訪問一個聚合對象中各個元素,而又不暴露該對象的內部表示。[DP]屬於行爲型模式之一。 Aggregate: 抽象類集合 Iterator(迭代器接口): 該接口必須定義實現迭代功能的最

原创 設計模式之《組合模式》

介紹 組合模式(Composite),將對象組合成樹形結構以表示‘部分-整體’的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。[DP]屬於結構型模式之一。 Component抽象構件角色 定義參加組合對象的共有方法和屬

原创 設計模式之《中介者模式》

介紹 Mediator 抽象中介者角色 抽象中介者角色定義統一的接口, 用於各同事角色之間的通信。 Concrete Mediator 具體中介者角色 具體中介者角色通過協調各同事角色實現協作行爲, 因此它必須依賴於各個同事角色。 C

原创 設計模式之“職責鏈模式”

介紹 抽象處理者 Handler 定義一個請求的處理方法handleMessage,唯一對外開放的方法;定義一個鏈的編排方法setNext,設置下一個處理者;定義了具體的請求者必須實現的兩個方法:定義自己能夠處理的級別getHandle

原创 設計模式之《簡單的工廠模式和工廠模式》

工廠模式和簡單工廠模式比較: UML圖: 簡單的工廠模式 圖示: 此時,如果我想增加一種水果,石榴,那麼我的水果種植基地就需要擴展一塊石榴園的種植土地。那麼就不符合設計原則中的開閉原則,因此它不屬於23種設計模式。 擴展圖示:  

原创 QML PathView之 PathQuad

qml中PathView元素自帶一個很有意思的例子,效果如圖: 其中Path段代碼如下: path: Path { startX: 120; st

原创 設計模式之狀態模式學習

介紹 結構: State——抽象狀態角色 接口或抽象類,負責對象狀態定義,並且封裝環境角色以實現狀態切換。 ConcreteState——具體狀態角色 每一個具體狀態必須完成兩個職責:本狀態的行爲管理以及趨向狀態處理,通俗地說,就是本

原创 設計模式之 觀察者模式(Publish/Subscribe)模式

介紹 觀察者模式定義了一種一對多的依賴關係,讓多個觀察者對象同時監聽某一個主題對象。 這個主題對象在狀態發生變化時,會通知所有觀察者對象,使它們能夠自動更新自己。[DP] Subject被觀察者 定義被觀察者必須實現的職責,它必須能夠動

原创 外觀模式學習

介紹 Facade外觀模式(有的也叫門面) 定義:Facade模式爲一組具有類似功能的類羣,比如類庫,子系統等等,提供一個一致的簡單的界面。這個一致的 簡單的界面被稱作facade。 客戶端可以調用這個角色的方法。 此角色知曉子系統的所

原创 C++設計模式之《代理模式》

簡介: 通過代理模式可以在原有業務邏輯外增加一定的約束,比如排序、範圍限制等等,無論具體主體還是代理主體都實現抽象主題 Subject抽象主題角色 抽象主題類可以是抽象類也可以是接口, 是一個最普通的業務類型定義, 無特殊要求。 Rea

原创 設計模式之《裝飾模式》

問: 現有類  A,如果想對類A進行功能增強,有幾種方法? 答:在C++種,常用的3種,分別是: 直接修改類A的代碼。但是不符合開閉原則 使用繼承,讓派生類B來擴充類A的功能 使用關聯/組合的方式,讓類C包含類A,然後對A進行增強(裝飾模