或者我们也可以换一个更加敏捷、更加实际的角度来看这个问题(可惜这需要丰富的经验)。其实软件设计是每隔一两个小时就可能变化的。你的真正技术不仅仅是体现在会用几个OOP术语,而是会重构你的(可编程)的需求设计。当你想到灯的时候,那么就写上4、5行代码来测试灯的特性。例如public void test1() { var t1 = new 灯(); var t2 = new 灯(); t1.开(); Debug.Assert(t1.isOpened != t2.isOpened); var t3 = new 灯(); t3.关(); 也就是说就是临时变量就够了。你没有更多的需求,就不要扯上更多的概念似地。反之,如果需要体现更多的需求,那么就先把大白话说清楚,从而也可以这样几行代码把usecase写出来,体现从领域出发什么叫做“存在哪里,我想”这两个概念,这两个概念能不能用代码来表达?如果这两个概念根本就不是领域出发的,而是编程出发的,那么就根本没有必要考虑。赶紧进一步想点真正的需求就可以把纠缠在技术上的无用概念(暂时)忘记了。
{
var t1 = new 灯();
var t2 = new 灯();
t1.开();
Debug.Assert(t1.isOpened != t2.isOpened);
var t3 = new 灯();
t3.关();
也就是说就是临时变量就够了。你没有更多的需求,就不要扯上更多的概念似地。反之,如果需要体现更多的需求,那么就先把大白话说清楚,从而也可以这样几行代码把usecase写出来,体现从领域出发什么叫做“存在哪里,我想”这两个概念,这两个概念能不能用代码来表达?如果这两个概念根本就不是领域出发的,而是编程出发的,那么就根本没有必要考虑。赶紧进一步想点真正的需求就可以把纠缠在技术上的无用概念(暂时)忘记了。
灯 灯1=new 灯();
灯1.open();
//这里处理业务逻辑
//用观察者模式看否达到关闭的条件
灯1.close();
创建对象事后不管不顾,到想起来用时很难的到的。就算找的到,现在对象已经达到什么状态了?是很难管控的