java面試設計模式
① java面試被問到設計模式應該怎麼回答
java 一共有23 中設計模式，例如單例模式、工廠模式、代理模式、適配器模式等，面試被問到你就說出幾個對應的設計模式，不能只知道名字啊，得了解這些設計模式是原理。如果你記憶力好都記下來也可以
② java常用的設計模式一共有多少種
1、正如上一位答主所言，java中存在23種面向對象的設計模式，分別是：
1）創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
2）結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
3）行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
2、他們遵從如下原則：
1）單一職責原則
2）里式替換原則
3）依賴倒置原則
4）介面隔離原則
5）迪米特法則
6）開閉原則
3、如果非要用幾個簡單的字來概括這繁雜的23種設計模式那就是「高內聚，低耦合」。
4、網路--23種設計模式，邊研究原理，邊敲代碼，其義自見。
③ java中的設計模式都有哪些
Java中的23種設計模式：
Factory（工廠模式）， Builder（建造模式）， Factory Method（工廠方法模式），
Prototype（原始模型模式），Singleton（單例模式）， Facade（門面模式），
Adapter（適配器模式）， Bridge（橋梁模式）， Composite（合成模式），
Decorator（裝飾模式）， Flyweight（享元模式）， Proxy（代理模式），
Command（命令模式）， Interpreter（解釋器模式）， Visitor（訪問者模式），
Iterator（迭代子模式）， Mediator（調停者模式）， Memento（備忘錄模式），
Observer（觀察者模式）， State（狀態模式）， Strategy（策略模式），
Template Method（模板方法模式）， Chain Of Responsibleity（責任鏈模式）
④ java面試中主要掌握的設計模式有哪些
java面試
設計模式主要分三個類型:創建型、結構型和行為型。
其中創建型有：
一、Singleton，單例模式：保證一個類只有一個實例，並提供一個訪問它的全局訪問點
二、Abstract Factory，抽象工廠：提供一個創建一系列相關或相互依賴對象的介面，而無須指定它們的具體類。
三、Factory Method，工廠方法：定義一個用於創建對象的介面，讓子類決定實例化哪一個類，Factory Method使一個類的實例化延遲到了子類。
四、Builder，建造模式：將一個復雜對象的構建與他的表示相分離，使得同樣的構建過程可以創建不同的表示。
五、Prototype，原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型來創建新的對象。
行為型有：
六、Iterator，迭代器模式：提供一個方法順序訪問一個聚合對象的各個元素，而又不需要暴露該對象的內部表示。
七、Observer，觀察者模式：定義對象間一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知自動更新。
八、Template Method，模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，TemplateMethod使得子類可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。
九、Command，命令模式：將一個請求封裝為一個對象，從而使你可以用不同的請求對客戶進行參數化，對請求排隊和記錄請求日誌，以及支持可撤銷的操作。
十、State，狀態模式：允許對象在其內部狀態改變時改變他的行為。對象看起來似乎改變了他的類。
十一、Strategy，策略模式：定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。
十二、China of Responsibility，職責鏈模式：使多個對象都有機會處理請求，從而避免請求的送發者和接收者之間的
開發模式:
JAVA中的開發模式:
MVC是一個很常用的程序開發設計模式，M-Model（模型）
⑤ java編碼中用設計模式與不用設計模式有什麼區別為什麼那些面試官老是喜歡問設計模式
使用了設計模式之後代碼看起來更結構化，在很小的項目中看不出來，但是如果是一個大項目的話，凌亂的代碼會讓人頭痛
為什麼面試官老是喜歡問設計模式：
因為寫代碼久了基本功都會了之後就需要更進一步的技能：寫出更結構化的代碼
設計模式是面試時候的一個常問的問題，面試官也是人，自己也要想面試別人的問題啊，想了也頭痛，既然這個常問就拿來問了
說實在話，java面試問設計模式已經是一個好多年的老傳統了，但是現在再審視一下這本成書較早的書，其實裡面很多的模式已經過時，有些並不適用於java，我感覺總是問設計模式也沒啥意思
所以很大的原因也是面試官懶，不想創新的去想面試的問題，直接問這種傳統問題省事
⑥ java中常用的設計模式有哪些
1.單例模式（有的書上說叫單態模式其實都一樣）
該模式主要目的是使內存中保持1個對象
2.工廠模式
該模式主要功能是統一提供實例對象的引用。看下面的例子：
public class Factory{
public ClassesDao getClassesDao(){
ClassesDao cd = new ClassesDaoImpl();
return cd;
}
}
interface ClassesDao{
public String getClassesName();
}
class ClassesDaoImpl implements ClassesDao {
public String getClassesName(){
System.out.println("A班");
}
}
class test
{
public static void main(String[] args){
Factory f = new Factory();
f.getClassesDao().getClassesName();
}
}
這個是最簡單的例子了，就是通過工廠方法通過介面獲取對象的引用
3.建造模式
該模式其實就是說，一個對象的組成可能有很多其他的對象一起組成的，比如說，一個對象的實現非常復雜，有很多的屬性，而這些屬性又是其他對象的引用，可能這些對象的引用又包括很多的對象引用。封裝這些復雜性，就可以使用建造模式。
4.門面模式
這個模式個人感覺像是Service層的一個翻版。比如Dao我們定義了很多持久化方法，我們通過Service層將Dao的原子方法組成業務邏輯，再通過方法向上層提供服務。門面模式道理其實是一樣的。
5.策略模式
這個模式是將行為的抽象，即當有幾個類有相似的方法，將其中通用的部分都提取出來，從而使擴展更容易。
⑦ java程序員面試的時候一般會考哪些設計模式會要求能手寫哪些設計模式那麼多設計模式不可能都考吧
我告訴你哦，你不要告訴別人哦，一般考的最多的是觀察者模式和工廠模式，當然啦，你要將工廠模式熟練（最好能畫圖），觀察者模式理解，最好能寫出來，就可以了，一般就這樣，對，沒錯。
⑧ JAVA面試題---設計一個類，該類只能生成一個實例
單實例Singleton設計模式可能是被討論和使用的最廣泛的一個設計模式了，這可能也是面試中問得最多的一個設計模式了。這個設計模式主要目的是想在整個系統中只能出現一個類的實例。這樣做當然是有必然的，比如你的軟體的全局配置信息，或者是一個Factory，或是一個主控類，等等。你希望這個類在整個系統中只能出現一個實例。當然，作為一個技術負責人的你，你當然有權利通過使用非技術的手段來達到你的目的。比如：你在團隊內部明文規定，「XX類只能有一個全局實例，如果某人使用兩次以上，那麼該人將被處於2000元的罰款！」（呵呵），你當然有權這么做。但是如果你的設計的是東西是一個類庫，或是一個需要提供給用戶使用的API，恐怕你的這項規定將會失效。因為，你無權要求別人會那麼做。所以，這就是為什麼，我們希望通過使用技術的手段來達成這樣一個目的的原因。
本文會帶著你深入整個Singleton的世界，當然，我會放棄使用C++語言而改用Java語言，因為使用Java這個語言可能更容易讓我說明一些事情。
Singleton的教學版本
這里，我將直接給出一個Singleton的簡單實現，因為我相信你已經有這方面的一些基礎了。我們姑且把這具版本叫做1.0版
// version 1.0
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
singleton= new Singleton();
}
return singleton;
}
}
在上面的實例中，我想說明下面幾個Singleton的特點：（下面這些東西可能是盡人皆知的，沒有什麼新鮮的）
私有（private）的構造函數，表明這個類是不可能形成實例了。這主要是怕這個類會有多個實例。
即然這個類是不可能形成實例，那麼，我們需要一個靜態的方式讓其形成實例：getInstance（）。注意這個方法是在new自己，因為其可以訪問私有的構造函數，所以他是可以保證實例被創建出來的。
在getInstance（）中，先做判斷是否已形成實例，如果已形成則直接返回，否則創建實例。
所形成的實例保存在自己類中的私有成員中。
我們取實例時，只需要使用Singleton.getInstance（）就行了。
當然，如果你覺得知道了上面這些事情後就學成了，那我給你當頭棒喝一下了，事情遠遠沒有那麼簡單。
Singleton的實際版本
上面的這個程序存在比較嚴重的問題，因為是全局性的實例，所以，在多線程情況下，所有的全局共享的東西都會變得非常的危險，這個也一樣，在多線程情況下，如果多個線程同時調用getInstance（）的話，那麼，可能會有多個進程同時通過 （singleton== null）的條件檢查，於是，多個實例就創建出來，並且很可能造成內存泄露問題。嗯，熟悉多線程的你一定會說——「我們需要線程互斥或同步」，沒錯，我們需要這個事情，於是我們的Singleton升級成1.1版，如下所示：
// version 1.1
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
synchronized (Singleton.class) {
singleton= new Singleton();
}
}
return singleton;
}
}
嗯，使用了Java的synchronized方法，看起來不錯哦。應該沒有問題了吧？！錯！這還是有問題！為什麼呢？前面已經說過，如果有多個線程同時通過（singleton== null）的條件檢查（因為他們並行運行），雖然我們的synchronized方法會幫助我們同步所有的線程，讓我們並行線程變成串列的一個一個去 new，那不還是一樣的嗎？同樣會出現很多實例。嗯，確實如此！看來，還得把那個判斷（singleton== null）條件也同步起來。於是，我們的Singleton再次升級成1.2版本，如下所示： // version 1.2
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
synchronized (Singleton.class)
{
if (singleton== null)
{
singleton= new Singleton();
}
}
return singleton;
}
}
不錯不錯，看似很不錯了。在多線程下應該沒有什麼問題了，不是嗎？的確是這樣的，1.2版的Singleton在多線程下的確沒有問題了，因為我們同步了所有的線程。只不過嘛……，什麼？！還不行？！是的，還是有點小問題，我們本來只是想讓new這個操作並行就可以了，現在，只要是進入 getInstance（）的線程都得同步啊，注意，創建對象的動作只有一次，後面的動作全是讀取那個成員變數，這些讀取的動作不需要線程同步啊。這樣的作法感覺非常極端啊，為了一個初始化的創建動作，居然讓我們達上了所有的讀操作，嚴重影響後續的性能啊！
還得改！嗯，看來，在線程同步前還得加一個（singleton== null）的條件判斷，如果對象已經創建了，那麼就不需要線程的同步了。OK，下面是1.3版的Singleton.
// version 1.3
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
synchronized (Singleton.class)
{
if (singleton== null)
{
singleton= new Singleton();
}
}
}
return singleton;
}
}
感覺代碼開始變得有點羅嗦和復雜了，不過，這可能是最不錯的一個版本了，這個版本又叫「雙重檢查」Double-Check.下面是說明：
第一個條件是說，如果實例創建了，那就不需要同步了，直接返回就好了。
不然，我們就開始同步線程。
第二個條件是說，如果被同步的線程中，有一個線程創建了對象，那麼別的線程就不用再創建了。
相當不錯啊，幹得非常漂亮！請大家為我們的1.3版起立鼓掌！
Singleton的其它問題
怎麼？還有問題？！當然還有，請記住下面這條規則——「無論你的代碼寫得有多好，其只能在特定的范圍內工作，超出這個范圍就要出Bug了」，這是「陳式第一定理」，呵呵。你能想一想還有什麼情況會讓這個我們上面的代碼出問題嗎？
在C++下，我不是很好舉例，但是在Java的環境下，嘿嘿，還是讓我們來看看下面的一些反例和一些別的事情的討論（當然，有些反例可能屬於鑽牛角尖，可能有點學院派，不過也不排除其實際可能性，就算是提個醒吧）：
其一、Class Loader.不知道你對Java的Class Loader熟悉嗎？「類裝載器」？！C++可沒有這個東西啊。這是Java動態性的核心。顧名思義，類裝載器是用來把類（class）裝載進JVM的。 JVM規范定義了兩種類型的類裝載器：啟動內裝載器（bootstrap）和用戶自定義裝載器（user-defined class loader）。在一個JVM中可能存在多個ClassLoader，每個ClassLoader擁有自己的NameSpace.一個ClassLoader只能擁有一個 class對象類型的實例，但是不同的ClassLoader可能擁有相同的class對象實例，這時可能產生致命的問題。如ClassLoaderA，裝載了類A的類型實例A1，而ClassLoaderB，也裝載了類A的對象實例A2.邏輯上講A1=A2，但是由於A1和A2來自於不同的 ClassLoader，它們實際上是完全不同的，如果A中定義了一個靜態變數c，則c在不同的ClassLoader中的值是不同的。
於是，如果咱們的Singleton 1.3版本如果面對著多個Class Loader會怎麼樣？呵呵，多個實例同樣會被多個Class Loader創建出來，當然，這個有點牽強，不過他確實存在。難道我們還要整出個1.4版嗎？可是，我們怎麼可能在我的Singleton類中操作 Class Loader啊？是的，你根本不可能。在這種情況下，你能做的只有是——「保證多個Class Loader不會裝載同一個Singleton」。
其二、序例化。如果我們的這個Singleton類是一個關於我們程序配置信息的類。我們需要它有序列化的功能，那麼，當反序列化的時候，我們將無法控制別人不多次反序列化。不過，我們可以利用一下Serializable介面的readResolve（）方法，比如：
public class Singleton implements Serializable
{
......
......
protected Object readResolve()
{
return getInstance();
}
}
其三、多個Java虛擬機。如果我們的程序運行在多個Java的虛擬機中。什麼？多個虛擬機？這是一種什麼樣的情況啊。嗯，這種情況是有點極端，不過還是可能出現，比如EJB或RMI之流的東西。要在這種環境下避免多實例，看來只能通過良好的設計或非技術來解決了。
其四，volatile變數。關於volatile這個關鍵字所聲明的變數可以被看作是一種 「程度較輕的同步synchronized」；與 synchronized 塊相比，volatile 變數所需的編碼較少，並且運行時開銷也較少，但是它所能實現的功能也僅是synchronized的一部分。當然，如前面所述，我們需要的 Singleton只是在創建的時候線程同步，而後面的讀取則不需要同步。所以，volatile變數並不能幫助我們即能解決問題，又有好的性能。而且，這種變數只能在JDK 1.5+版後才能使用。
其五、關於繼承。是的，繼承於Singleton後的子類也有可能造成多實例的問題。不過，因為我們早把Singleton的構造函數聲明成了私有的，所以也就杜絕了繼承這種事情。
其六，關於代碼重用。也話我們的系統中有很多個類需要用到這個模式，如果我們在每一個類都中有這樣的代碼，那麼就顯得有點傻了。那麼，我們是否可以使用一種方法，把這具模式抽象出去？在C++下這是很容易的，因為有模板和友元，還支持棧上分配內存，所以比較容易一些（程序如下所示），Java下可能比較復雜一些，聰明的你知道怎麼做嗎？
template<CLASS T> class Singleton
{
public:
static T& Instance()
{
static T theSingleInstance; //假設T有一個protected默認構造函數
return theSingleInstance;
}
};
class OnlyOne : public Singleton<ONLYONE>
{
friend class Singleton<ONLYONE>;
int example_data;
public:
int GetExampleData() const {return example_data;}
protected:
OnlyOne(): example_data(42) {} // 默認構造函數
OnlyOne(OnlyOne&) {}
};
int main( )
{
cout << OnlyOne::Instance().GetExampleData()<< endl;
return 0;
⑨ 面試談談Java的設計模式
簡單啊。。。首先你要知道有三種設計模式，然後能隨便都能說出幾個設計模式啊，什麼單例模式，工廠模式，代理模式，觀察者模式，適配器模式等等，之後就是至少能說出一個設計模式是的定義，角色等就差不多了！
設計一般是公司裡面的大牛才要做的事情，小菜簡單了解就行了。
網頁鏈接
⑩ java中常用到得設計模式有哪幾種
Java中的23種設計模式：
Factory（工廠模式）,Builder（建造模式）,Factory
Method（工廠方法模式），Prototype（原始模型模式），Singleton（單例模式），Facade（門面模式），Adapter（適配器模式），Bridge（橋梁模式），
Composite（合成模式），Decorator（裝飾模式），
Flyweight（享元模式），
Proxy（代理模式），Command（命令模式），
Interpreter（解釋器模式），
Visitor（訪問者模式），Iterator（迭代子模式），
Mediator（調停者模式），
Memento（備忘錄模式），Observer（觀察者模式），
State（狀態模式），
Strategy（策略模式），Template
Method（模板方法模式），
Chain
Of
Responsibleity（責任鏈模式）
工廠模式：工廠模式是一種經常被使用到的模式，根據工廠模式實現的類可以根據提供的數據生成一組類中某一個類的實例，通常這一組類有一個公共的抽象父類並且實現了相同的方法，但是這些方法針對不同的數據進行了不同的操作。首先需要定義一個基類，該類的子類通過不同的方法實現了基類中的方法。然後需要定義一個工廠類，工廠類可以根據條件生成不同的子類實例。當得到子類的實例後，開發人員可以調用基類中的方法而不必考慮到底返回的是哪一個子類的實例。