如果人生也能存檔——C#中的備忘錄模式

大家好,老胡又和大家見面了。首先承認今天的博客有點標題黨了,人生是沒有存檔,也沒有後悔葯的。有存檔和後悔葯的,那是遊戲,不知道這是不是遊戲讓人格外放鬆的原因之一。

今天恰逢端午放假,就讓我們來試着做一個小遊戲吧,順帶看看備忘錄模式是如何在這種情況下面工作的。

遊戲背景

這是一個簡單的打怪遊戲,有玩家,有怪獸,玩家作為主角光環,有如下三個特殊能力

  • 攻擊怪獸有暴擊幾率
  • 有幾率迴避怪獸攻擊
  • 可以自己治療一定生命值

遊戲實現

角色類
角色基類

首先是角色類,角色類提供玩家和怪獸最基本的抽象,比如血量、攻擊力、攻擊和治療。(對於怪獸來說,治療是沒有提供實現的,壞人肯定不能再治療了)

class Character
{
    public int HealthPoint { get; set; }
    public int AttackPoint { get; set; }        

    public virtual void AttackChracter(Character opponent)
    {
        opponent.HealthPoint -= this.AttackPoint;
        if (opponent.HealthPoint < 0)
        {
            opponent.HealthPoint = 0;
        }
    }

    public virtual void Cure()
    {
		//故意留空給子類實現
    }
}
玩家類

玩家實現了治療功能並且有暴擊幾率。

class Player : Character
{
    private float playerCriticalPossible;
    public Player(float critical)
    {
        playerCriticalPossible = critical;
    }

    public override void AttackChracter(Character opponent)
    {
        base.AttackChracter(opponent);
        Console.WriteLine("Player Attacked Monster");

        Random r = new Random();
        bool critical = r.Next(0, 100) < playerCriticalPossible * 100;
        if (critical)
        {
            base.AttackChracter(opponent);
            Console.WriteLine("Player Attacked Monster again");
        }
    }

    public override void Cure()
    {
        Random r = new Random();
        HealthPoint += r.Next(5, 10);
        Console.WriteLine("Player cured himself");
    }
}
怪獸類

怪獸沒有治療能力但是有一定的幾率丟失攻擊目標。

class Monster : Character
{
    private float monsterMissingPossible;
    public Monster(float missing)
    {
        monsterMissingPossible = missing;
    }

    public override void AttackChracter(Character opponent)
    {
        Random r = new Random();
        bool missing = r.Next(0, 100) < monsterMissingPossible * 100;
        if (missing)
        {
            Console.WriteLine("Monster missed it");
        }
        else
        {
            base.AttackChracter(opponent);
            Console.WriteLine("Monster Attacked player");
        }
    }
}
遊戲類

遊戲類負責實例化玩家和怪獸、記錄回合數、判斷遊戲是否結束,暴露可調用的公共方法給遊戲操作類。

class Game
{
    private Character m_player;
    private Character m_monster;
    private int m_round;
    private float playerCriticalPossible = 0.6f;
    private float monsterMissingPossible = 0.2f;
    
    public Game()
    {
        m_player = new Player(playerCriticalPossible)
        {
            HealthPoint = 15,
            AttackPoint = 2
        };
        m_monster = new Monster(monsterMissingPossible)
        {
            HealthPoint = 20,
            AttackPoint = 6
        };
    }

    public bool IsGameOver => m_monster.HealthPoint == 0 || m_player.HealthPoint == 0;

    public void AttackMonster()
    {            
        m_player.AttackChracter(m_monster);
    }

    public void AttackPlayer()
    {
        m_monster.AttackChracter(m_player);
    }

    public void CurePlayer()
    {
        m_player.Cure();
    }

    public void BeginNewRound()
    {
        m_round++;
    }

    public void ShowGameState()
    {
        Console.WriteLine("".PadLeft(20, '-'));
        Console.WriteLine("Round:{0}", m_round);
        Console.WriteLine("player health:{0}", "".PadLeft(m_player.HealthPoint, '*'));
        Console.WriteLine("monster health:{0}", "".PadLeft(m_monster.HealthPoint, '*'));
    }
}
遊戲操作類

在我們這個簡易遊戲中,沒有UI代碼,遊戲操作類負責在用戶輸入和遊戲中搭建一個橋樑,解釋用戶的輸入。

class GameRunner
{
    private Game m_game;
    public GameRunner(Game game)
    {
        m_game = game;
    }

    public void Run()
    {
        while (!m_game.IsGameOver)
        {
            m_game.BeginNewRound();
            bool validSelection = false;
            while (!validSelection)
            {
            	m_game.ShowGameState();
                Console.WriteLine("Make your choice: 1. attack 2. Cure");
                var str = Console.ReadLine();
                if (str.Length != 1)
                {
                    continue;
                }
                switch (str[0])
                {
                    case '1':
                        {
                            validSelection = true;
                            m_game.AttackMonster();
                            break;
                        }
                    case '2':
                        {
                            validSelection = true;
                            m_game.CurePlayer();
                            break;
                        }
                    default:
                        break;
                }
            }
            if(!m_game.IsGameOver)
            {
                m_game.AttackPlayer();
            }
        }            
    }
}
客戶端

客戶端的代碼就非常簡單了,只需要實例化一個遊戲操作類,然後讓其運行就可以了。

class Program
{
    static void Main(string[] args)
    {
        Game game = new Game();
        GameRunner runner = new GameRunner(game);
        runner.Run();
    }
}

試着運行一下,

看起來一切都好。

 

加上存檔

雖然遊戲可以正常運行,但是總感覺還是少了點什麼。嗯,存檔功能,一個遊戲沒有存檔是不健全的,畢竟,人生雖然沒有存檔,但是遊戲可是有的!讓我們加上存檔功能吧,首先想想怎麼設計。
 

需要存檔的數據

首先我們要明確,有哪些數據是需要存檔的,在這個遊戲中,玩家的生命值、攻擊力、暴擊率;怪獸的生命值、攻擊力和丟失率,遊戲的回合數,都是需要存儲的對象。
 

存檔定義

這是一個需要仔細思考的地方,一般來說,需要考慮以下幾個地方:

  • 存檔需要訪問一些遊戲中的私有字段,比如暴擊率,需要在不破壞遊戲封裝的情況下實現這個功能
  • 存檔自身需要實現信息隱藏,即除了遊戲,其他類不應該訪問存檔的詳細信息
  • 存檔不應該和遊戲存放在一起,以防不經意間遊戲破壞了存檔數據,應該有專門的類存放存檔

 

備忘錄模式出場

這個時候應該是主角出場的時候了。看看備忘錄模式的定義

在不破壞封閉的前提下,捕獲一個對象的內部狀態,並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到原先保存的狀態

再看看UML,

看起來完全符合我們的需求啊,Originator就是遊戲類,知道如何創造存檔和從存檔中恢復狀態,Memento類就是存檔類,Caretaker是一個新類,負責保存存檔。

經過思考,我們決定採取備忘錄模式,同時加入以下措施:

  • 將存檔定義為遊戲中的私有嵌套類,這樣存檔可以毫無壓力的訪問遊戲中的私有字段,同時外界永遠沒有辦法去實例化或者嘗試通過轉型來獲得這個類,完美的保護了存檔類
  • 存檔類是一個簡單的數據集合,不包含任何其他邏輯
  • 添加一個存檔管理器,可以放在遊戲操作類中,可以通過它看到我們當前有沒有存檔
  • 存檔放在存檔管理器中
  • 存檔實現一個空接口,在存檔管理器中以空接口形式出現,這樣外部類在訪問存檔的時候,僅能看到這個空接口。而在遊戲類內部,我們在使用存檔之前先通過向下轉型實現類型轉換(是的,向下轉型不怎麼好,但是偶爾可以用一下)
代碼實現
空接口
interface IGameSave
{

}
私有嵌套存檔類

該類存放在game裏面,無壓力地在不破壞封裝的情況下訪問game私有字段

private class GameSave : IGameSave
{
    public int PlayerHealth { get; set; }
    public int PlayerAttack { get; set; }
    public float PlayerCritialAttackPossible { get; set; }
    public int MonsterHealth { get; set; }
    public int MonsterAttack { get; set; }
    public float MonsterMissingPossible { get; set; }
    public int GameRound { get; set; }
}
創建存檔和從存檔恢復

game中添加創建存檔和從存檔恢復的代碼,在從存檔恢復的時候,使用了向下轉型,因為從存檔管理器讀出來的只是空接口而已

public IGameSave CreateSave()
{
    var save = new GameSave()
    {
        PlayerHealth = m_player.HealthPoint,
        PlayerAttack = m_player.AttackPoint,
        PlayerCritialAttackPossible = playerCriticalPossible,
        MonsterAttack = m_monster.AttackPoint,
        MonsterHealth = m_monster.HealthPoint,
        MonsterMissingPossible = monsterMissingPossible,
        GameRound = m_round
    };
    Console.WriteLine("game saved");
    return save;
}

public void RestoreFromGameSave(IGameSave gamesave)
{
    GameSave save = gamesave as GameSave;
    if(save != null)
    {
        m_player = new Player(save.PlayerCritialAttackPossible) { HealthPoint = save.PlayerHealth, AttackPoint = save.PlayerAttack };
        m_monster = new Player(save.MonsterMissingPossible) { HealthPoint = save.MonsterHealth, AttackPoint = save.MonsterAttack };
        m_round = save.GameRound;
    }
    Console.WriteLine("game restored");
}	
存檔管理器類

添加一個類專門管理存檔,此類非常簡單,只有一個存檔,要支持多存檔可以考慮使用List

    class GameSaveStore
    {
        public IGameSave GameSave { get; set; }
    }
在遊戲操作類添加玩家選項

首先在遊戲操作類中添加一個存檔管理器

private GameSaveStore m_gameSaveStore = new GameSaveStore();

接着修改Run方法添加用戶操作

public void Run()
{
    while (!m_game.IsGameOver)
    {
        m_game.BeginNewRound();
        bool validSelection = false;
        while (!validSelection)
        {
            m_game.ShowGameState();
            Console.WriteLine("Make your choice: 1. attack 2. Cure 3. Save 4. Load");
            var str = Console.ReadLine();
            if (str.Length != 1)
            {
                continue;
            }
            switch (str[0])
            {
                case '1':
                    {
                        validSelection = true;
                        m_game.AttackMonster();
                        break;
                    }
                case '2':
                    {
                        validSelection = true;
                        m_game.CurePlayer();
                        break;
                    }
                case '3':
                    {
                        validSelection = false;
                        m_gameSaveStore.GameSave = m_game.CreateSave();
                        break;
                    }
                case '4':
                    {
                        validSelection = false;
                        if(m_gameSaveStore.GameSave == null)
                        {
                            Console.WriteLine("no save to load");
                        }
                        else
                        {
                            m_game.RestoreFromGameSave(m_gameSaveStore.GameSave);
                        }
                        break;
                    }
                default:
                    break;
            }
        }
        if(!m_game.IsGameOver)
        {
            m_game.AttackPlayer();
        }
    }            
}

注意,上面的3和4是新添加的存檔相關的操作。試着運行一下。

看起來一切正常,這樣我們就使用備忘錄模式,完成了存檔讀檔的功能。

 

結語

這就是備忘錄模式的使用,如果大家以後遇到這種場景

  • 想要保存狀態,又不想破壞封裝
  • 需要把狀態保存到其他地方

那麼就可以考慮使用這個模式。

遊戲有存檔,人生沒存檔,願我們把握當下,天天努力。
祝大家端午安康,下次見。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

JAVA設計模式 3【創建型】理解工廠模式與抽象工廠模式

上一節我們已經學習了原型模式,稍微複習一下:通過重寫Object 類的clone() 方法實現淺克隆,淺克隆也要實現Cloneable 標記接口。而深克隆則是將對象通過序列化和反序列化 的方式進行創建和還原。

本小結將學習的是工廠模式,這個模式在平時是特別常用的,還需好好理解。我也將舉一些例子給大家

從生活出發

假設我們今天不想做飯,想出去吃飯、肯定選定一家好吃的川菜館,然後我們找好位置坐下,給廚師說,我想吃糖醋排骨。 稍微等待幾分鐘、菜就可以做好,然後給你呈上來。

這是一個很經典的例子,我們平時也經常有這樣的實際問題,你發現了么?

  • 我只需要告訴廚師菜名,我要吃啥就行了
  • 我不關注這個菜是怎麼生產的 new()

開始擼代碼

/**
 * 抽象產品 菜
 */
public interface FoodProduct {
    void show();
}
------------
/**
 * 具體產品
 */
public class HongShao implements FoodProduct {
    @Override
    public void show() {
        System.out.println("紅燒排骨");
    }
}
------------
public class TangCu implements FoodProduct {
    @Override
    public void show() {
        System.out.println("糖醋魚");
    }
}

創建廚房工廠

創建一個廚房類,廚房可以用來生產食物產品,我們只需要告訴廚房,這裡是通過id 編號的形式告訴廚房的。我們只需要告訴廚房所需要的食物 而不關心這個食物產品是如何創建出來的。

public class KitchenFactory {
    /**
     * id=1 上菜紅燒肉 id=2 糖醋魚
     * @param id
     */
    public FoodProduct cooking(int id) {
        if (1 == id) {
            return new HongShao();
        } else {
            return new TangCu();
        }
    }
}
KitchenFactory kitchen = new KitchenFactory();
FoodProduct food = kitchen.cooking(1);
food.show();
--------
紅燒排骨

理解工廠模式

通過這個簡單的例子,我們可以學習到:

  • 無需關注對象是如何創建的。只需通過指定的關鍵字 就能拿到我需要的產品,這就是簡單工廠模式。

抽象工廠

http://c.biancheng.net/view/1351.html

抽象工廠,就是簡單工廠的抽象版、如何理解呢?我們上面的工廠(廚房)它已經是一個確定的對象 了。而抽象工廠,則是在廚房 的基礎上,再次衍生出一個接口,我們的廚房 則是這個抽象類的一個具體實例化。

代碼源於生活

我又要開始舉栗子了。請細細品

我們都知道小米 小米既可以生產手機 也可以生產電器用品 那麼這就是一個很好的例子。

小米抽象工廠 是一個巨大的工廠,它裏面有小米手機工廠 以及小米電器工廠 而不同的工廠,則生產不同的產品

代碼教學開始

首先,我們得需要一個抽象工廠,這個工廠可以包含手機工廠和電器工廠。

public interface AbstractFactory {
    /**
     * 創建手機工廠
     * @return
     */
    PhoneFactory phoneFactory();
    /**
     * 創建電器工廠
     * @return
     */
    ElectricalFactory electricalFactory();
}

當然,手機工廠不知道是具體哪個工廠,反正它可以做一些事情,比如創建手機。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    void show();
}
-----------
public interface ElectricalFactory {
    /**
     * 電器工廠可以生產電器
     */
    void show();
}

上手實際創建一個小米工廠


public class XiaoMiFactory implements AbstractFactory {
    
    @Override
    public PhoneFactory phoneFactory() {
        return new XiaoMiPhoneFactory();
    }
    @Override
    public ElectricalFactory electricalFactory() {
        return new XiaoMiElectricalFactory();
    }
}
-------------
public class XiaoMiElectricalFactory implements ElectricalFactory {
    @Override
    public void show() {
        System.out.println("小米電器工廠可以生產電器。。比如小米掃地機器人");
    }
}
-------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public void show() {
        System.out.println("小米手機工廠可以生產小米手機。。。");
    }
}

當然,小米工廠實現抽象工廠,那小米工廠就必須要包含兩個子工廠,手機工廠和電器工廠了。我們也可以創建一個華為工廠,其實是一樣的道理。

AbstractFactory factory = new XiaoMiFactory();

PhoneFactory phoneFactory = factory.phoneFactory();
phoneFactory.show();
--------
小米手機工廠可以生產小米手機。。。

我們從創建的小米工廠中拿出小米手機工廠 然後再執行手機工廠可以做事情,抽象工廠,就是在上面的簡單工廠的層次上進行了再次的抽象,將具體的工廠進行抽象。

假設我們按照上面的邏輯。對於一個工廠,我想要一部手機 我給工廠說一聲就行了。我不關心這個手機 是如何生產出來的。我該怎麼操作?

我稍微將之前的幾個接口作為稍微的改造。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    PhoneProduct show();
}
---------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public PhoneProduct show() {
        return new PhoneProduct(1, "小米10 Pro");
    }
}
----------
//手機對象
public class PhoneProduct {

    private int id;

    private String name;
}

我們可以創建這樣一個訪問器,通過訪問器對象,將我們需要的對象名稱傳入就好比下單 它能自動匹配工廠,並且調用工廠創建產品 的方法,將我們需要的產品進行創建。

public class AbstractFactoryClient {

    public PhoneProduct createPhone(String name) {

        AbstractFactory factory = null;

        if ("xiaomi" == name) {
            factory = new XiaoMiFactory();
        } else {
            factory = new HuaweiFactory();
        }
        PhoneFactory phoneFactory = factory.phoneFactory();
        
        return phoneFactory.show();
    }
}

測試一下

AbstractFactoryClient factoryClient = new AbstractFactoryClient();
PhoneProduct product = factoryClient.createPhone("xiaomi");
System.out.println(product);
-----------
手機銘牌 編號:1,型號:小米10 Pro

小結

學習完本節,是否對於工廠模式和抽象工廠有了一個深入的了解呢?工廠模式其實在平時的代碼中,還是比較常用的。所以還是需要更加努力學習和使用!

代碼示例

https://gitee.com/mrc1999/Dev-Examples

參考

http://c.biancheng.net/view/1351.html

歡迎關注

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

kubernetes資源均衡器Descheduler

背景

Kubernetes中的調度是將待處理的pod綁定到節點的過程,由Kubernetes的一個名為kube-scheduler的組件執行。調度程序的決定,無論是否可以或不能調度容器,都由其可配置策略指導,該策略包括一組規則,稱為謂詞和優先級。調度程序的決定受到其在第一次調度時出現新pod時的Kubernetes集群視圖的影響。由於Kubernetes集群非常動態且狀態隨時間而變化,因此可能需要將已經運行的pod移動到其他節點,原因如下:

  • 一些節點不足或過度使用。
  • 原始調度決策不再適用,因為在節點中添加或刪除了污點或標籤,不再滿足pod / node親和性要求。
  • 某些節點發生故障,其pod已移至其他節點。
  • 新節點將添加到群集中。

因此,可能會在群集中不太理想的節點上安排多個pod。Descheduler根據其政策,發現可以移動並移除它們的pod。請注意,在當前的實現中,descheduler不會安排更換被驅逐的pod,而是依賴於默認的調度程序。

Descheduler二次調度

GitHub地址:https://github.com/kubernetes-sigs/descheduler

下面是重要的配置

  • configmap.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy-configmap
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    strategies:
      "RemoveDuplicates":
         enabled: true
      "RemovePodsViolatingInterPodAntiAffinity":
         enabled: true
      "LowNodeUtilization":
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               "cpu" : 30
               "memory": 40
               "pods": 50
             targetThresholds:
               "cpu" : 20
               "memory": 25
               "pods": 15

RemoveDuplicates策略

該策略發現未充分利用的節點,並且如果可能的話,從其他節點驅逐pod,希望在這些未充分利用的節點上安排被驅逐的pod的重新創建。此策略的參數配置在nodeResourceUtilizationThresholds

節點的利用率低是由可配置的閾值決定的thresholdsthresholds可以按百分比為cpu,內存和pod數量配置閾值 。如果節點的使用率低於所有(cpu,內存和pod數)的閾值,則該節點被視為未充分利用。目前,pods的請求資源需求被考慮用於計算節點資源利用率。

還有另一個可配置的閾值,targetThresholds用於計算可以驅逐pod的潛在節點。任何節點,所述閾值之間,thresholds並且targetThresholds被視為適當地利用,並且不考慮驅逐。閾值targetThresholds也可以按百分比配置為cpu,內存和pod數量。

簡單的說:thresholds是沒有達到資源使用的node視為資源使用率低可以分配做為預選節點, targetThresholds是已經滿足這個條件的node資源緊張要把上面的pod遷移。

  • cronjob.yaml
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler-cronjob
  namespace: kube-system
spec:
  #定時任務時間可調 schedule:
"*/10 * * * *" concurrencyPolicy: "Forbid" jobTemplate: spec: template: metadata: name: descheduler-pod spec: priorityClassName: system-cluster-critical containers: - name: descheduler image: aveshagarwal/descheduler #image: us.gcr.io/k8s-artifacts-prod/descheduler:v0.10.0 volumeMounts: - mountPath: /policy-dir name: policy-volume command: - "/bin/descheduler" args: - "--policy-config-file" - "/policy-dir/policy.yaml" - "--v" - "3" restartPolicy: "Never" serviceAccountName: descheduler-sa volumes: - name: policy-volume configMap: name: descheduler-policy-configmap
  • rbac.yaml
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: descheduler-cluster-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs: ["create"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: descheduler-sa
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: descheduler-cluster-role-binding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: descheduler-cluster-role
subjects:
  - name: descheduler-sa
    kind: ServiceAccount
    namespace: kube-system

kubectl apply -f 執行上面三個文件,查看日誌如有滿足再次調度條件的 會重新發起二次調度均衡node資源。

 

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

台塑美國德州廠污染案 台塑同意15.33億和解

摘錄自2019年10月16日自由時報報導

台塑集團德州廠遭居民指控排放塑膠顆粒、污染水資源,聯邦地區法院法官在今年6月裁定,台塑違反廢棄物排放許可證和聯邦淨水法,恐面臨鉅額罰款;台塑當時否認非法傾倒,聲稱排放的塑膠顆粒並未超過許可證允許數量。

《美聯社》15日報導,非營利組織Texas RioGrande Legal Aid(TRLA)週二宣布與台塑達成和解協議,並表示基於雙方同意的判決,台塑同意實行「零排放」並清理既有的汙染;協議還需要經過法官批准,通過後,5000萬美元將在5年內用於改善當地河川的水質。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

植樹遏止氣候變遷 科學家說成效被高估

摘錄自2019年10月23日中央通訊社馬來西亞報導

科學家警告說,全球大規模植樹遏止氣候變遷風險的可能成效被高估。今年7月,蘇黎世聯邦理工學院(ETH Zurich)柯勞瑟實驗室(Crowther Lab)的研究人員發布研究報告,提出控制氣候變化的最好方法,就是在面積與美國相當的被毀森林重新植樹。

但德國波昂大學(University of Bonn)和位於奈洛比的世界農林複合研究中心「世界混農林業中心」(World Agroforestry Center)的科學家,18日在期刊「科學」(Science)發表回應文指出,在原先研究中可以在土地上種植的樹木數量有限。

波昂大學作物科學與資源保育研究所(Institute of Crop Sciences and Resource Conservation)教授魯德林(Eike Luedeling)表示,植樹造林不應被視為減少使用化石燃料排放的替代方案。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

防空污 印度排燈節只准燃放綠色環保鞭炮

摘錄自2019年10月22日中央通訊社印度報導

印度國家首都區這幾天空氣污染持續在「不佳」(poor)狀態,為避免排燈節燃放鞭炮惡化空氣品質,印度最高法院今天(22日)宣布,只有兩種綠色環保、被稱為anar和phuljhari的無聲鞭炮,可以在27日排燈節(Diwali)燃放,其他吵雜的鞭炮和煙火都被禁止。

被允許在印度宗教節日排燈節燃放的鞭炮將有印度政府認證標章和快速響應矩陣圖碼(QR code),警方呼籲消費者在購買鞭炮時要認明標章和QR code。新德里電視台(NDTV)引述德里警察局發言人藍大瓦(MS Randhawa)說,警方已組成檢查小組,如果有商家販售其他類型的鞭炮和煙火,警方將會採取法律行動。

主管環保的印度中央政府部長瓦德漢(Harsh Vardhan)表示,綠色環保鞭炮的懸浮粒子含量減少25%到30%,二氧化碳排放減少50%,有助降低鞭炮燃放對空氣品質的影響。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

「人造葉」設備啟蒙自光合作用 可生產乾淨燃料「合成氣」

摘錄自2019年10月22日科技新報報導

科學家開發出太陽能燃料領域一種新設備,可以利用陽光將水、二氧化碳轉化成用來發電的燃料「合成氣」,因轉化過程有如植物光合作用,而被暱稱為「人造葉」。

合成氣是一種利用氣化技術(gasification technology)將煤炭、石油、生質物等含碳原料轉化成一氧化碳與氫氣、然後混合而成的產物,本身可充當燃料氣體,主要用途為發電,也可用來生產藥品、塑膠、肥料等。

而英國劍橋大學團隊花費多年時間設計出人造葉,包含二種先進的鈣鈦礦光吸收劑和一種由鈷製成的分子催化劑,前者作用類似植物中吸收陽光的分子,鈣鈦礦可提供更高的電壓與電流驅動化學反應;後者則是代替鉑或銀,不僅成本較低,催生一氧化碳的表現也比其他催化劑好。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

瑞典智庫:氣候變遷加劇衝突 阻礙和平建設

摘錄自2019年10月23日中央社報導

瑞典智庫斯德哥爾摩國際和平研究所(SIPRI)23日公布報告指出,氣候變遷對當前及未來的和平建設構成嚴峻挑戰,並且可能加劇衝突。該研究所氣候變遷計畫高級研究員科蘭普(Florian Krampe)指出,報告顯示安全形勢正隨著氣候變遷改變,這次許多發現也適用於其他衝突。

索馬利亞被形容為「世界氣候變遷脆弱度最高的國家之一」。報告顯示,索國數十年來的衝突,因為一系列嚴重乾旱而加劇,加深國家建設進展的壓力,在多個層面對聯合國駐索馬利亞援助團的工作構成更多挑戰。科蘭普並未斷言氣候變遷本身可能造成衝突,但他認為證據明確顯示「氣候變化增加衝突及暴力的可能性」。

根據聯合國難民事務高級專員公署(UNHCR),由於武裝衝突及重複不斷的乾旱,索馬利亞境內現今約有260萬人流離失所,逾80萬人仍離鄉背井滯留鄰國。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

設計模式系列之外觀模式(Facade Pattern)——提供統一的入口

說明:設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟件開發人員內功修鍊之道)》一書的閱讀筆記。個人感覺這本書講的不錯,有興趣推薦讀一讀。詳細內容也可以看看此書作者的博客https://blog.csdn.net/LoveLion/article/details/17517213

模式概述

絕大多數B/S系統都有一個首頁或者導航頁面,大部分C/S系統都提供了菜單或者工具欄,在這裏,首頁和導航頁面就充當了B/S系統的外觀角色,而菜單和工具欄充當了C/S系統的外觀角色,通過它們用戶可以快速訪問子系統,增強了軟件的易用性。

在軟件開發中,有時候為了完成一項較為複雜的功能,一個客戶類需要和多個業務類交互,而這些需要交互的業務類經常會作為一個整體出現,由於涉及到的類比較多,導致使用時代碼較為複雜,此時,特別需要一個類似服務員一樣的角色,由它來負責和多個業務類進行交互,而客戶類只需與該類交互。外觀模式通過引入一個外觀角色(Facade)來簡化客戶端與子系統(Subsystem)之間的交互,為複雜的子系統調用提供一個統一的入口,降低子系統與客戶端的耦合度,使得客戶端調用非常方便。

模式定義

外觀模式中,一個子系統的外部與其內部的通信通過一個統一的外觀類進行,外觀類將客戶類與子系統的內部複雜性分隔開,使得客戶類只需要與外觀角色打交道,而不需要與子系統內部的很多對象打交道。

外觀模式(Facade Pattern):為子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用

外觀模式又稱為門面模式,它是一種對象結構型模式。外觀模式是迪米特法則的一種具體實現,通過引入一個新的外觀角色可以降低原有系統的複雜度,同時降低客戶類與子系統的耦合度。

模式結構圖

外觀模式沒有一個一般化的類圖描述,下圖所示的類圖也可以作為描述外觀模式的結構圖:

外觀模式包含如下兩個角色:

  • Facade(外觀角色):在客戶端可以調用它的方法,在外觀角色中可以知道相關的(一個或者多個)子系統的功能和責任;在正常情況下,它將所有從客戶端發來的請求委派到相應的子系統去,傳遞給相應的子系統對象處理。

  • SubSystem(子系統角色):在軟件系統中可以有一個或者多個子系統角色,每一個子系統可以不是一個單獨的類,而是一個類的集合,它實現子系統的功能;每一個子系統都可以被客戶端直接調用,或者被外觀角色調用,它處理由外觀類傳過來的請求;子系統並不知道外觀的存在,對於子系統而言,外觀角色僅僅是另外一個客戶端而已。

模式偽代碼

外觀模式中所指的子系統是一個廣義的概念,它可以是一個類、一個功能模塊、系統的一個組成部分或者一個完整的系統。子系統類通常是一些業務類,實現了一些具體的、獨立的業務功能,其典型代碼如下:

public class SubSystemA {

    public void methodA() {
        //業務實現代碼
    }
}

public class SubSystemB {

    public void methodB() {
        //業務實現代碼
    }
}

public class SubSystemC {

    public void methodC() {
        //業務實現代碼
    }
}

引入外觀類,與子系統業務類之間的交互統一由外觀類來完成

public class Facade {
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void method() {
        obj1.methodA();
        obj2.methodB();
        obj3.methodC();
    }
}

由於在外觀類中維持了對子系統對象的引用,客戶端可以通過外觀類來間接調用子系統對象的業務方法,而無須與子系統對象直接交互。引入外觀類后,客戶端代碼變得非常簡單,典型代碼如下:

public static void main(String[] args) {
    Facade facade = new Facade();
    facade.method();
}

模式改進

在標準的外觀模式中,如果需要增加、刪除或更換與外觀類交互的子系統類,必須修改外觀類或客戶端的源代碼,這將違背開閉原則,因此可以通過引入抽象外觀類來對系統進行改進,在一定程度上可以解決該問題。在引入抽象外觀類之後,客戶端可以針對抽象外觀類進行編程,對於新的業務需求,不需要修改原有外觀類,而對應增加一個新的具體外觀類,由新的具體外觀類來關聯新的子系統對象。

定義抽象外觀類

public abstract class AbstractFacade {
    public abstract void method();
}

根據具體的場景,實現具體的外觀類

public class Facade1 extends AbstractFacade {

    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();

    @Override
    public void method() {
        obj1.methodA();
        obj2.methodB();
    }
}

public class Facade2 extends AbstractFacade {

    private SubSystemB obj1 = new SubSystemB();
    private SubSystemC obj2 = new SubSystemC();

    @Override
    public void method() {
        obj1.methodB();
        obj2.methodC();
    }
}

客戶端針對抽象外觀類進行編程,代碼片段如下:

public static void main(String[] args) {
    AbstractFacade facade = new Facade1();
    // facade = new Facade2();
    facade.method();
}

模式應用

個人認為外觀模式某些情況下可以看成是對既有系統的再次封裝,所以各種類庫、工具庫(比如hutool)、框架基本都有外觀模式的影子。外觀模式讓調用方更加簡潔,不用關心內部的實現,與此同時,也讓越來越多的程序猿多了個調包俠的昵稱(當然了這其中也包括筆者●´ω`●行無際)。

所以,你可能在很多開源代碼中看到類似XxxBootstrapXxxContextXxxMain等類似的Class,再追進去看一眼,你可能發現裏面關聯了一大堆的複雜的對象,這些對象對於外層調用者來說幾乎是透明的。

例子太多,以致於不知道舉啥例子(實際是偷懶的借口O(∩_∩)O哈哈~)。

模式總結

外觀模式並不給系統增加任何新功能,它僅僅是簡化調用接口。在幾乎所有的軟件中都能夠找到外觀模式的應用。所有涉及到與多個業務對象交互的場景都可以考慮使用外觀模式進行重構。

主要優點

(1) 它對客戶端屏蔽了子系統組件,減少了客戶端所需處理的對象數目,並使得子系統使用起來更加容易。通過引入外觀模式,客戶端代碼將變得很簡單,與之關聯的對象也很少。

(2) 它實現了子系統與客戶端之間的松耦合關係,這使得子系統的變化不會影響到調用它的客戶端,只需要調整外觀類即可。

(3) 一個子系統的修改對其他子系統沒有任何影響,而且子系統內部變化也不會影響到外觀對象。

適用場景

(1) 當要為訪問一系列複雜的子系統提供一個簡單入口時可以使用外觀模式。

(2) 客戶端程序與多個子系統之間存在很大的依賴性。引入外觀類可以將子系統與客戶端解耦,從而提高子系統的獨立性和可移植性。

(3) 在層次化結構中,可以使用外觀模式定義系統中每一層的入口,層與層之間不直接產生聯繫,而通過外觀類建立聯繫,降低層之間的耦合度。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!