面向對象第三階段學習總結

關於規格化的發展

　　其實在第一次佈置關於規格的做業時,我就嘗試以規格,面向對象方法規格,java編程規格等多個關鍵詞在中文互聯網上搜索過,試圖對規格和規格的發展得到更多的瞭解,但獲得的有用信息寥寥無幾.因此直到如今我還一直好奇,若是說注重編程註釋的質量已是共識的話,爲何規格卻沒有得到更多的注意呢?(規格指狹義的布爾表達式等,這是個人猜想,我沒有參加過真正的工程開發,因此對業界認知不足.可是確實公開的資料寥寥).若是說沒有獲得你們的承認的話,說明多是存在某些不足,咱們爲何要堅持以一種反人類的布爾表達式的JSF來代替天然語言的註釋呢?這只是我一家之言,可能老師有更多別的方面的考慮,好比可以經過工具檢測,更加規範等等,這些都是我考慮不到的.

規格化編程的發展歷史

　　按照個人理解,規格化設計實際上是和麪對對象的編程思想,以及軟件工程這門科學一塊兒發展起來的,三者是相輔相成的.

　　在計算機發展的最初,從彙編語言一直到面向過程語言,像BASIC和C語言的流行,是沒有規格這個說法的.人們經過辛苦地編程和debug完成工做,每每程序中充滿了goto這種天馬行空的作法,編程變得magic.通過科技的發展,程序變得愈來愈多樣化和功能愈來愈強大,代碼的數量也愈來愈長.爲了讓代碼正常工做,程序員只好放棄goto這種很差的特性,經過結構化設計讓程序更加規範和容易維護.

　　可是很快代碼超過了一個小團隊可以完成的上限,須要幾十幾百我的協同完成.這個時候,人們發現讓程序運行起來變得愈來愈困難,de掉100個bug會出現200個新的bug.無可奈何之下,人們只好尋求另外的編程思想,那就是面向對象的思想.將大的工程分工,分紅一個個小的模塊,模塊再細分,直到變成重複使用的數據結構和針對數據結構的操做方法,就是對象和方法.爲了更好的描述對象的範圍和特性,爲了明示方法的操做方法,要求,和對數據形成的結果,產生了不一樣的規格化語言.咱們接觸的JSF算是其中一種.

三次做業的規格化bug

　　除了第二次有幾個類由於完成的比較晚,沒有來得及寫repOK方法以外,互測者並無報告更多的關於我規格方面的bug,固然,這是由於測試者的善良,個人規格化仍是有不少不足和改進空間的.

/**
     * 
     *@REQUIRES: none
     *@MODIFIES: System.in and System.out;this.requestItems;
     *@EFFECTS: while System.in has a line ,a line will be consumed;
     *some information will be written in System.out;
     *if the line can construct a Request,a new RequestItem will be added to the list;
     *if the line is a command line, call the command function 
     */
    public void run()
    {
        Scanner scanner = new Scanner(System.in);
        while (scanner.hasNextLine()) {
            String inputString = scanner.nextLine();
            if(InputHandler.isLoadRequest(inputString))
            {
                String[] strings = inputString.split(" ",-1);
                SysMain.load(strings[1]);
            }
            else if(inputHandler.isRoadChange(inputString))
            {
                SysMain.setRoad(inputString);
            }
            else if(inputHandler.isLegal(inputString))
            {
                Request request = new Request(inputString);
                synchronized (requestList)
                {
                    requestList.add(new RequestItem(request));
                    requestList.notifyAll();
                }
            }
            else
            {
                System.out.println("##illegal request");
            }
        }
        scanner.close();
    }

第一是類的功能不明確致使的方法的複雜,以致於只能用天然語言描述,這個問題出如今InputThread的run方法中,咱們能夠改正這個方法

public void run()
{
        Scanner scanner = new Scanner(System.in);
        while (scanner.hasNextLine()) 
        {
            String inputString = scanner.nextLine();
            inputHandler.handle(inputString);
        
        }
　　　　　scanner.close();

} 

這樣就能夠保證關於輸入的操做由InputHandler負責,而Thread只負責運行.

第二是方法的複雜程度過高,不得不使用天然語言.此處其實例子不少,就不贅述了.

第三則是對布爾語言的掌握程度不高致使的錯誤,這些雖然可能測試者看在寫的頗有誠意的份上放過了,可是實際上是可以改正的.

結言

　　其實這三次做業仍是特別鍛鍊能力的,由於三次是創建在統一基礎上的,涉及到多線程,繼承,GUI等問題,數次重構也讓我對有關知識瞭解的更深入.