Protected Attribute

一直以为Protected属性的方法就是不能被类实例直接调用而可以被类内的方法或子类的方法

以不指明实例的方式(或者说其实是省略了this指针)来调用的方法。有这个印象是受了private属性的影响,觉得

调用者总是本身才行,protected和private比只不过是增加了继承性,比如调用者还是必须是基类或子类的实例本身,不能新创建一个实例去调用。。。

 

今天在看ruby的介绍时才发现:

Protected methods can be called both in the same instance and by other instances of the same class and its subclasses.

这里有个重要的差别:other instances…

举个例子:

public class ClassC
    {              
        protected void MethodTwo()
        {
        }
        public void MethodOne()
        {          
            ClassC temp = new ClassC();
            temp.MethodTwo();

        }
    }

main函数里调用ClassC的实例和MethodOne(),省略。

按第一种理解就不可以运行MethodOne方法。而实际上是可以的。无论是c++还是c#。

上述英文定义是从实例的角度出发,用类和scope的角度来说,就是在基类或者子类的scope里都可以调用protected方法,无论调用的主体是基类或子类的实例,是本身的实例还是新构造的实例,这些都无所谓。

其实我觉得作者的定义不准确,instance都是class的应用,instance没有body,啥叫in the same instance? 定义都在class里嘛。

延伸一下,ruby有没有static的类成员我还没学到,但对于c++,protected的定义必须跳出instance的范畴。

因为,对于static的方法来说,根本没有instance的存在。比如:

C++代码:

 class ClassC
    { 
 
 protected  :
    static void MethodTwo()
        {
   printf(“hi”);
        }
        public  :
   static  void MethodOne()
        {          
   ClassC::MethodTwo();

        }
    };

int _tmain(int argc, _TCHAR* argv[])
{
 ClassC::MethodOne(); 
 return 0;
}

所以用class scope的方法来说明protected的用法是最好的。其实想想自己对这种基本概念仍然有不清楚的地方,直接导致了实际应用中基本不用protected方法。真正了解一个东西,才能更好的使用它啊。

不知道我的下一份工作,能否更多地走回到技术的道路上来。

 

敏捷为什么这么流行?

好久没有打开csdn的网页。

现在终于又回到了自由的程序员的心态,重新去上一些技术网站。

结果发现敏捷,SOA等概念充斥着首页,比以前更甚。

看到一个词BDUF,不知为何物,便觉自己落伍了。google之,找到下面的链接:

http://www.agilemodeling.com/essays/bmuf.htm

原来BDUF者,Big design up front 也。或称Big Modeling Up Front (BMUF),Big requirements up front (BRUF)。

简言之,就是做项目前设计,建模等工作要求比较高的指导思想,即过度设计。

为什么会过度设计,作者指出了人们普遍犯的几个挺有意思的错误观点:把软件开发当作建筑工程,忽视了软件项目的可被改变的特性(malleable)。结果就是只重视文档和需求的过度设计。这样最好的结果是做完项目,但代价过高;更坏的结果是做出了符合文档和需求的产品,但却不是现在用户需要的,并且不好修改。人们以为这是唯一的出路,是因为不知道敏捷开发的方法,组建团队时过于专业分工,不相信程序员可以建模和设计,或者被传统数据库设计必须先建模的理念羁绊太多。对程序员来说,这剥夺了程序员编程的快乐。因为告诉程序员他们只能按事先设计好的不能变的方案做,而需求却会经常改变。一方面会增加他们的难度,另一方面他们只是执行者。这无异于在说他们是低级的或者不重要的。结果是程序员经常有意或无意地不遵循设计写软件,最后的最后,不管是程序员的选择还是公司的选择,离开这样的团队就是结局。

显然这篇文章里有合理的分析:过度设计有弊端,业界有需求去改进它。但它是不是已经被找到了呢?

网上还有人说中国程序员技能比较低,而敏捷更需要程序员的才能。但敏捷需要的是更高的编程技术吗?是沉迷于技术的geek吗?中国程序员不是欧美程序员,浮躁是我们的特点,因为我们没有物质保障,不能专心搞技术;因为我们的IT业在高速扩展,人员走动很频繁。就这样,难道我们要走印度的路?要成为软件工厂的蓝领?成为CMM体系下的螺丝钉?也许工业化是一条道路,但条条道路通罗马。我相信除了工业化外,软件还有别的发展方式。就如同分工是社会的进步,但通才教育仍然存在。太多的问题往往是因人而异的,并没有一个固定的答案。

敏捷开发是什么?也许没有固定的答案。我暂时没有资格去发表评论。

参考和学习中:http://www.agilemodeling.com/essays/agileRequirements.htm