面向對象先導課感想

下來我將分點講述下收穫和感想以及相關意見和建議。

收穫和感想

做爲一個雖然沒有專門學過java可是早已經熟悉OOP程序設計方式，並使用 C# 有過大概幾千行開發經驗的學員，個人感想可能和大部分人有些不一樣。

java語言

說到java和C#，其實這是強類型語言裏面兩個最適合OOP設計的語言，並且二者以前有着至關高的語法類似度（畢竟都是滿滿的C系語言風格）。並且都是在整個項目中指定一個入口點類，而後從 static void main 函數入口，就像這樣（簡單的A+B問題的實現）：

C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace APlusB {
    class Program {
        static void Main(string[] args) {
            string[] numbers = Console.ReadLine().Split(new char[] { ' ' });
            int a = int.Parse(numbers[0]);
            int b = int.Parse(numbers[1]);
            Console.WriteLine(a + b);
        }
    }
}

Java

package aplusb;
import java.io.*;
import java.util.*;

public class Main {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int a = sc.nextInt();
        int b = sc.nextInt();
        System.out.println(a + b);
    }
}

有一個以前遇到過的坑，就是java的異常處理機制。在java中，若是一個函數（方法）須要拋出異常的話，是必須在當前函數（方法）處進行聲明的。同時外部調用這個函數（方法）的部分也必須使用異常處理語句包裝起來（即必須放進 try { } 中）。
這樣作的一個很大的好處是強迫開發者徹底將全部的異常保持在一個可控的狀態，即每一層對於內層的異常都會作好徹底的處理。不過缺點也很明顯——語法太煩了，尤爲是當異常狀態不少很雜時候，外部調用能夠變得很是繁瑣。
而C#中則徹底不須要這些，拋出異常無需聲明，也能夠隨意的使用可能有異常的函數（方法）（不過因爲亂拋異常致使的程序報錯結果也得本身處理。）

基於java的OOP

還記得在第一次正式講OOP時，java OOP很重要的一個原則就是不容許任何變量直接暴露給用戶。
這一點的確沒有錯，變量直接暴露給用戶會致使部分數據失去控制，從而致使整個對象模型內部紊亂。但是不少時候仍是須要這樣子的變量的，尤爲是頻繁訪問的數據，不停地 get, set總讓人感到很是的不舒服，語法也會變得很臃腫。
對於java而言，這的確是無解的，對於頻繁直接改動的值總仍是不得不get, set。
而在C#中，則有個叫作屬性的東西，能夠很好的解決這一問題，就像這樣

protected int p_val;
public int val {
    get { 
        return this.p_val;
    }
    set {
        this.p_val = value;
    }
}

程序調用時，就能夠像調用一個變量同樣的調用val了，無需括號，無需get, set，語法十分優雅。
不只如此，屬性還能夠完美支持不少更增強大的功能

• 只讀屬性

protected int p_val;
public int val {
    get { 
        return this.p_val;
    }
}

這樣一來val就只能夠讀出不能夠更改了

• 將複雜的數據維護動做簡單封裝起來
  其實，屬性也是基於get和set的模式的，只不過將其按照賦值和取值的兩種動做分別進行了封裝。get, set內部本質仍是一個函數，能夠執行復雜任務的函數。

同時，java和c#都做爲嚴格的強類型OOP語言，不少機制（例如：強類型的繼承、接口、反射、函數的重載等）也都是徹底具有的（相比之下，弱類型則不須要接口和函數重載之類的東西，像php這樣的語言連反射也都是徹底內置化的，並且弱類型語言廣泛有個叫作eval的函數，能夠基本上取代掉傳統的反射類）。就語法溫馨程度而言，我的仍是更支持c#一些。不過java有個至今無可替代的優點——完美的跨平臺支持（java的虛擬機遍及各個平臺，即涉及到各個平臺底層的東西java早已替編程者實現好了），且java的部分特性決定了java更適合做爲OOP初學者語言。

總之這兩個語言，各有各的好處，還有不少的東西值得我去進一步研究和學習。以及，做爲一個合格的 IT learner，而不是廉價的勞動力碼農，眼光也絕對不能夠侷限於語言自己，而應該是語言之上更深層次的東西。

對於課程設計的建議

相比於以前的數據結構與程序設計課程，面向對象課程存在一個比較明顯的問題——因爲不少時候只有大體的需求而沒有很明確的輸入輸出或交互要求，因此很難作成相似OJ那樣的自動化評測，因此不少時候仍是只能依賴於人手工評測，這樣很是的費時費力。
其實我的感受，作出來OJ模式的測評自己並非難事。可是帶來的問題是，若是徹底採用黑盒測試，則沒有辦法保證學生採用了所需的面向對象設計模式。
我我的的建議是：將人工查看代碼和黑盒測試相結合
人工查看能夠必定程度上保證設計模式按照要求。同時黑盒測試也能夠真正更加方便和可感地衡量一個程序的真實性能和不足，同時大大提升測試效率。

關於課程自己，我想說的就是如何平衡一下Java語言的教學和真正面向對象知識的教學，讓無java基礎的人不至於徹底掉隊，也讓有必定基礎的人不被太多拖慢進度。

關於互測

因爲有些東西可能真的仍是難以全面採用黑盒測試，因此不得已只能採用互測的方式。就目前來看，當前的互測方式有明顯不公平不合理之處。

• 因爲採用的是每一個人隨機分配一名被hack者的緣由，因此這直接致使每一個人能hack的空間很是有限。說的更直接點，若是你很幸運抽到了一個代碼盡是bug的程序，那你的分數能夠很是高；若是你hack的人程序結構至關嚴密，設計優化程度至關能夠，那這一點上你基本無法期望。
• 同時也是因爲上面一點，從被hack者的角度而言，也存在極大的漏網空間，很大程度上也取決於運氣。同一份程序，若是你的hacker是個技術了得，你大概會很慘；若是他敷衍了事或者水平欠佳，那你得分也同樣不會低，甚至徹底不低於那些真正把程序寫的很棒的人。

這樣的模式，有不少的弊病：

• 因爲存在如此巨大的不公平空間，因此很難真正激發同窗之間互相糾正錯誤的慾望，根本沒法達到相似 Codeforces 那樣的互相糾正的做用。相反，這樣的措施一旦限制稍有失誤，即可能致使嚴重的惡性競爭（甚至是一些不正當線下交易）。
• 從學生的將來發展來看，這樣的措施會致使不少該糾正的bug和系統設計錯誤沒法被及時糾正。一旦少數當時做爲漏網之魚的學生帶着這種錯誤的設計方式進入了其餘單位，那麼對學生本人和那個單位而言都是極爲不利的。

個人建議：

• 在 Codeforces （Codeforces 網站連接） 中，一旦有人成功hack了別人的一份程序，那麼終測的時候，全部以前得到 Accepted 狀態的程序都會被全部這些成功hack別人的數據從新測試一下。也就是說實際上即使你直接hack的人只有一個或者幾個，但實際上做用到的人是全部人（不少時候，不少錯誤，都是很是具備共性的，一個hack點經常能夠卡掉很是多份的程序）。建議這樣的普遍測試機制能夠歸入考覈，有助於大幅度提升公平性和教學的質量。
• 在 Codeforces 中， 每一份程序都是被掛出來讓你們一塊兒來hack的。這樣當看得人多了，缺陷天然會很快所有曝光出來。建議更多的程序讓你們開放hack，也可讓真正有足夠能力hack的人能發揮應有的做用。（不過這樣一來就必須作好嚴密的反做弊反抄襲系統，爲了杜絕因爲代碼公開而致使的抄襲現象。不過也有一種辦法就是等到ddl以後，全部人中止提交，這時候再開放hack。）

總之，我的以爲，互測機制自己是個初衷很好的機制。可是裏面的相關制度和模式仍是應該有進一步完善的空間。最後期待半年後咱們的OO課程更加科學合理。