面向对象先导课感想

下来我将分点讲述下收获和感想以及相关意见和建议。

收获和感想

做为一个虽然没有专门学过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课程更加科学合理。