原创 Nutz 設計模式應用 --- 工廠方法

工廠方法把類的初始化工作封裝到了一個單獨的類中, 這個類被稱爲工廠類. 首先需要一個工廠接口和產品接口: public interface IFactory { IProduct create(); } public i

原创 Nutz 設計模式應用 --- 單例模式

在IOC容器中, 所有的對象默認都是單例, 我們只需要把對象加載到IOC容器中即可. nutz demo: @IocBean public class SingletonDemo { } public class Single

原创 Nutz 設計模式應用 --- 前言

這個系列的主題是什麼? 設計模式的一些學習筆記以及應用, 主要依託於Nutz這個框架. 爲什麼不用Spring? 首先公司的框架就是基於Nutz的, 用起來熟悉一點. 其次, 設計模式是一種較高層次的抽象, 不依託於任何

原创 Nutz 設計模式應用 --- 靜態工廠方法

靜態工廠方法比較簡單, 與其說是設計模式, 倒不如認爲是一個工具類(utils). 靜態工廠方法的實現是使用靜態方法, 目的也是爲了避免構造函數過多而引起的可讀性下降, 以Java8中的LocalDate爲例: public c

原创 組合與繼承

組合優於繼承 這裏說一下繼承的缺點: 1. 繼承導致類爆炸, 使用繼承的方式添加功能會導致一個功能一個類, 累積起來就會導致類的數量爆炸. 2. 繼承導致代碼重複: 實現類似的功能必然會導致相似的代碼, 而這些相似的代碼位於不同的

原创 適配器模式

適配器模式的主要作用是代碼重用. 當代碼庫中已有的代碼基本滿足需求, 但是接口與需求不匹配, 這時可以用適配器模式來進行接口轉換. 實現過程也很簡單, 就是把已有的對象作爲成員變量, 然後把請求都委託給它. 這裏不再對代碼和UML進行說明

原创 關於語言的一些想法

各種編程語言的首要作用是溝通, 其次是運行. 就目前而言, 我們所需要的基本溝通要素:結構定義,算術表達式,邏輯表達式,條件語句等在目前流行的各個語言中都有相似的實現, 相同的概念, 所以當不同語言的程序員在溝通時任然不會有太多的障礙.

原创 數據結構 --- 二叉查找樹

樹 實現 // 擴展版的鏈表 public class Node<T> { public T data; public Node<T> left; // small public Node<T> right; /

原创 關於單元測試的一些思考

整潔代碼 代碼邏輯直接了當 儘量少的依賴 乾淨利落的抽象以及直截了當的控制語句 沒有改進的餘地 以上內容都提取自<代碼整潔之道> 總結下來就是: 簡單

原创 Java Collection --- 綜述

Collection 框架是用於表示”容器”的對象, 最高層次的抽象是Collection接口. 分類 可變容器: 初始化之後可以修改, 如add(), remove() 不可變容器: 初始化之後只可以查詢, 如size(), con

原创 數據結構 --- 散列表

Why 散列表是數組的升級版, 在數組中, 我們可以使用整數索引作爲key, 而在散列表中, 我們可以使用任意的類型作爲key. 當然這其中需要一個轉化: AnyType –> Int, 而這個轉化函數就是散列函數. 散列衝突 AnyTy

原创 事情其實很簡單

當然這篇文章也是關於編程的, 在討論之前我們先看看什麼是複雜. 舉例來說: 複雜就是現階段市面上的設計模式圖書, 看了很多本還是看不懂. 我們先來分析一下上述的案例, 爲什麼會變複雜? 大部分設計模式圖書都會在前兩章講UML, 其實

原创 併發 --- 常見術語區分

同步(Synchronous) && 異步(Asynchronous) 同步: 調用方法並等待方法返回或者結束. 異步: 調用方法 同步和異步的區別在於調用方是否需要等待方法返回. 異步通常在一些耗時的操作上使用, 比如發送郵件: 用

原创 數據結構 -- 表

聲明: 本文章只是作爲本人的個人筆記使用, 不保證可讀性以及正確性. 有界表(ArrayList) 內部數據結構 一般使用數組實現, 如 Object[] data = new Object[capacity]; 插入到尾部 數組插入da

原创 代理模式

代理模式是在委託請求給被代理類時做一些處理: 緩存: 在進行耗時操作前查詢緩存, 在進行耗時操作後更新緩存, 確保耗時操作只進行一次. 訪問控制: 在委託請求前進行權限校驗. 代理模式使用組合的方式給被代理類添加一些新的功能和優化,