- 浏览: 367154 次
- 性别:
- 来自: 北京
最新评论
-
litongke:
类比的方式总是能帮助我们快速的理解一个晦涩的理念。楼主的很厉害 ...
从面向对象到面向切面 -
snowflate_summer:
这是从数学上来论证面向对象和面向切面吗?很深奥
从面向对象到面向切面 -
奥义之舞:
我好像更迷茫了。、、、
从面向对象到面向切面 -
canonical:
很遗憾,从现在已知的物理学来看,所谓能量也只是一种偏移量而已。 ...
逆元:不存在的真实存在 -
suifeng:
关于最后一段:我也有类似的思考信息是能量的动态呈现, 也就相当 ...
逆元:不存在的真实存在
判断和循环是程序中最基本的语句结构。而在vonNeumann体系架构下,循环是对集合进行操作所需的基本步骤。一个有趣的事实是,函数式语言所宣称的 生产力的来源很大程度上在于集合操作的便捷性。在数学中我们通过张量分析,泛函分析等可以清楚地意识到集合之间的相互作用是可抽象的,是可以独立理解的, 即我们可以在不涉及具体基元结构的层面上独立的定义并执行集合运算。如何将这种概念独立性在框架层面展开是一个非常深刻的命题。
在基元结构上应用基础操作p(d)这一微观场景一般情况下是容易理解并实现的, 但通常程序中所定义的大量边界是基于集合变量的, 因此很多代码都是封包和解包操作, 在层层嵌套的循环结构深处我们才能发现真正具有业务价值的基元结构. 将集合操作提升到系统层,减少或简化在应用层需要显式编制的循环结构是框架设计层面需要考虑的问题.
一个最基本的方法是尽量定义通用的同构操作, 避免构造中间集合. 例如前后台之间通过json等通用协议交换复杂结构的对象, 避免定义特殊的中间处理过程. 一个与之相配合的重要技术手段是通过类查询语句(描述方式)直接构造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)这样的处理方式显然要比在循环过程中基于特定条件过滤要方便的多. 而在AOP操作中切点的集合定义方式也是其提供的核心价值之一. 与集合操作相适应的一种代码风格是流式设计(stream), 这正是jQuery试图鼓吹的主要价值(虽然我个人认为它有些走极端). 流式设计的核心结构实际上是 x += dx, 它不需要集合是一次性构造的, 便于支持一种逐步部分修正的概念模型.
为了支持集合的隐式构造, 我们需要以通用的方式定义元素到集合的组装规则. 在Witrix平台的前台js框架中我们定义了由独立的html组件到复合查询条件的拼接规则, 定义了由每个html组件的数据校验函数到整个form的数据校验函数之间的组装规则, 定义了由单个html组件提交参数到整个form提交参数之间的组装规则. 在Witrix平台的标准界面上, 框架本身的编制基于js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作进行, 在不同的应用场景下, 我们只需要关心每一个字段如何显示, 提交哪些属性, 而由系统负责将它们自动组装并在后台进行分派. 面向不同的应用, 框架代码不需要做出任何修改, 确保了系统结构的可重用性.
Witrix平台的后台处理模型中定义了实体化过程, DaoWebAction基于CRUD等原子操作定义了批量提交, 数据导入导出等复合的甚至是嵌套的集合操作. 在不同的应用中, 我们通过修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等针对单实体的业务规则即可适应不同的业务场景, 而不需要为特定的应用重复编制集合处理过程.
面向集合+通用组装规则是Witrix平台设计中采用的基本设计手法之一, 它使得我们在一般应用中只需要考虑单实体,单字段等基元结构上发生的特定业务, 大大简化了系统构造过程. 但是也需要认识到从个体到集合的扩张(p(d) -> P(D) )是非平凡的, 集合比个体的简单加和要更多, 为此架构中需要保留对集合边界的识别能力, 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针对每一数据行执行业务规则.
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
嘿,我虽然对科学史没有什么研究,也不会你这么说了我就这么相信哩。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
好歹人家还是要离开神学才能从事研究不是?
一根筋对于研究学问很重要,这点我承认,但这是研究领域,只对一个理论体系内部负责,而不是对现实世界负责
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
建议读pascal同学著的思想录
不专门研究神学就等于不相信上帝么?
赫赫,在第二次数学危机之前,即便是微积分的开山鼻祖牛顿也不知道怎么用他手上那个粗糙的流数法去求他书中的那些行星的椭圆轨道.高斯着重考虑无穷级数收敛性的时候,Jacobi居然嘲笑他说"向高斯那么严密我们没有那么多时间"。但是这种轻率迟早要付出代价.拉普拉斯听完柯西发表的关于无穷级数收敛性的论文后,回家的第一件事情就是检查自己的5大卷<天体力学>,经过几天艰苦的努力最终还是庆幸自己所用的无穷级数都是收敛的.
我们现代人或许已经无法去体验拉普拉斯当时的那种诚惶诚恐的心情.因为现代的数学知识绝大部分只是和扳手起子差不多的工具而已.我们之所以不需要去研究那些严密的理论体系而只关心数学工具的实际应用,只是因为这些数学知识的基础已经被无数的天才们严格的探讨过,而不是因为现实世界的领域本身无需严密的理论体系,也不意味着我们可以随意地使用一些轻佻的臆想去描述我们所未知的东西.站在巨人肩膀上的人,可能只是一个侏儒.
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
嘿,我虽然对科学史没有什么研究,也不会你这么说了我就这么相信哩。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
好歹人家还是要离开神学才能从事研究不是?
一根筋对于研究学问很重要,这点我承认,但这是研究领域,只对一个理论体系内部负责,而不是对现实世界负责
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
数学分为抽象数学与具体数学,计算机技术涉及的是具体数学,数学是理论的,只是提供理论的指导,告诉你怎么做,无法具体到实现,数学是更高层次的抽象,用数学可以很好的推导
这个区分只怕很少有人会认同。
我的原话不是这一句。谁在后台改了这个帖子?
在基元结构上应用基础操作p(d)这一微观场景一般情况下是容易理解并实现的, 但通常程序中所定义的大量边界是基于集合变量的, 因此很多代码都是封包和解包操作, 在层层嵌套的循环结构深处我们才能发现真正具有业务价值的基元结构. 将集合操作提升到系统层,减少或简化在应用层需要显式编制的循环结构是框架设计层面需要考虑的问题.
一个最基本的方法是尽量定义通用的同构操作, 避免构造中间集合. 例如前后台之间通过json等通用协议交换复杂结构的对象, 避免定义特殊的中间处理过程. 一个与之相配合的重要技术手段是通过类查询语句(描述方式)直接构造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)这样的处理方式显然要比在循环过程中基于特定条件过滤要方便的多. 而在AOP操作中切点的集合定义方式也是其提供的核心价值之一. 与集合操作相适应的一种代码风格是流式设计(stream), 这正是jQuery试图鼓吹的主要价值(虽然我个人认为它有些走极端). 流式设计的核心结构实际上是 x += dx, 它不需要集合是一次性构造的, 便于支持一种逐步部分修正的概念模型.
为了支持集合的隐式构造, 我们需要以通用的方式定义元素到集合的组装规则. 在Witrix平台的前台js框架中我们定义了由独立的html组件到复合查询条件的拼接规则, 定义了由每个html组件的数据校验函数到整个form的数据校验函数之间的组装规则, 定义了由单个html组件提交参数到整个form提交参数之间的组装规则. 在Witrix平台的标准界面上, 框架本身的编制基于js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作进行, 在不同的应用场景下, 我们只需要关心每一个字段如何显示, 提交哪些属性, 而由系统负责将它们自动组装并在后台进行分派. 面向不同的应用, 框架代码不需要做出任何修改, 确保了系统结构的可重用性.
Witrix平台的后台处理模型中定义了实体化过程, DaoWebAction基于CRUD等原子操作定义了批量提交, 数据导入导出等复合的甚至是嵌套的集合操作. 在不同的应用中, 我们通过修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等针对单实体的业务规则即可适应不同的业务场景, 而不需要为特定的应用重复编制集合处理过程.
面向集合+通用组装规则是Witrix平台设计中采用的基本设计手法之一, 它使得我们在一般应用中只需要考虑单实体,单字段等基元结构上发生的特定业务, 大大简化了系统构造过程. 但是也需要认识到从个体到集合的扩张(p(d) -> P(D) )是非平凡的, 集合比个体的简单加和要更多, 为此架构中需要保留对集合边界的识别能力, 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针对每一数据行执行业务规则.
评论
49 楼
Julien
2008-11-25
现实世界领域的问题不是不需要工具,而是需要选对工具用好工具。
随意地使用一些轻佻的臆想去描述我们所未知的东西固然很轻浮,随意地使用一些轻佻的臆想去描述我们已经在面对的现实也未必就是怎样高明的姿态了。
似乎变成口水了,我逃……
随意地使用一些轻佻的臆想去描述我们所未知的东西固然很轻浮,随意地使用一些轻佻的臆想去描述我们已经在面对的现实也未必就是怎样高明的姿态了。
似乎变成口水了,我逃……
48 楼
hurricane1026
2008-11-25
Julien 写道
Trustno1 写道
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
嘿,我虽然对科学史没有什么研究,也不会你这么说了我就这么相信哩。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
好歹人家还是要离开神学才能从事研究不是?
一根筋对于研究学问很重要,这点我承认,但这是研究领域,只对一个理论体系内部负责,而不是对现实世界负责
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
建议读pascal同学著的思想录
47 楼
Trustno1
2008-11-25
引用
嘿,我虽然对科学史没有什么研究,也不会你这么说了我就这么相信哩。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
不专门研究神学就等于不相信上帝么?
引用
一根筋对于研究学问很重要,这点我承认,但这是研究领域,只对一个理论体系内部负责,而不是对现实世界负责
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
赫赫,在第二次数学危机之前,即便是微积分的开山鼻祖牛顿也不知道怎么用他手上那个粗糙的流数法去求他书中的那些行星的椭圆轨道.高斯着重考虑无穷级数收敛性的时候,Jacobi居然嘲笑他说"向高斯那么严密我们没有那么多时间"。但是这种轻率迟早要付出代价.拉普拉斯听完柯西发表的关于无穷级数收敛性的论文后,回家的第一件事情就是检查自己的5大卷<天体力学>,经过几天艰苦的努力最终还是庆幸自己所用的无穷级数都是收敛的.
我们现代人或许已经无法去体验拉普拉斯当时的那种诚惶诚恐的心情.因为现代的数学知识绝大部分只是和扳手起子差不多的工具而已.我们之所以不需要去研究那些严密的理论体系而只关心数学工具的实际应用,只是因为这些数学知识的基础已经被无数的天才们严格的探讨过,而不是因为现实世界的领域本身无需严密的理论体系,也不意味着我们可以随意地使用一些轻佻的臆想去描述我们所未知的东西.站在巨人肩膀上的人,可能只是一个侏儒.
46 楼
Julien
2008-11-24
Trustno1 写道
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
嘿,我虽然对科学史没有什么研究,也不会你这么说了我就这么相信哩。
帕斯卡能打,一辈子离开神学的日子没有几年,光那几年的成果就打绝人寰。
好歹人家还是要离开神学才能从事研究不是?
一根筋对于研究学问很重要,这点我承认,但这是研究领域,只对一个理论体系内部负责,而不是对现实世界负责
但到了应用领域,面对一堆只对其内部负责的理论体系,和一个现实世界领域的复杂问题的时候,就没有神了
45 楼
Trustno1
2008-11-24
Julien 写道
我看过拿哲学来解说现实世界的心理学问题的书,结果是不管怎样的大师和神仙,不管怎样的精确严密自我圆满的逻辑体系,只要拿到现实问题上,就只有在极端限定后的场景里才能生效,对于大部分现象和问题是无法解释,南辕北辙的,这个时候墨守一个空中楼阁的理论工具来强行分析和制定对策出来的效果,绝对不可能比一个街道大妈靠生活经验作出来的分析和对策要好。
当然心理学的场景比抽象结构要复杂艰深的多,但是就一般而言,任何理论框架都只是工具而不是最高纲领,根据实际需要选择各种工具组合解决问题,而不是支持一个最高真理经受试炼展示想神迹,这才是一般解决某个实际问题的正确思路。任何抽象过后构建而成的理论体系【一定】都已经失真了(对于这个世界失真,当然对于这个理论自身而言还可以是继续完美无缺的),都用不着当作神来膜拜,混沌无规则的现实世界才是高于一切的。
当然心理学的场景比抽象结构要复杂艰深的多,但是就一般而言,任何理论框架都只是工具而不是最高纲领,根据实际需要选择各种工具组合解决问题,而不是支持一个最高真理经受试炼展示想神迹,这才是一般解决某个实际问题的正确思路。任何抽象过后构建而成的理论体系【一定】都已经失真了(对于这个世界失真,当然对于这个理论自身而言还可以是继续完美无缺的),都用不着当作神来膜拜,混沌无规则的现实世界才是高于一切的。
一个有趣的事实是,古代中国的大多数数学家的任务只是为了解决现实世界中的测算问题,而从毕格达拉斯以降到牛顿解决数学问题的主要目的就是为了展示神迹或者荣耀上帝.然而他们之间的成就高低却不能以道里记.
44 楼
Julien
2008-11-24
我看过拿哲学来解说现实世界的心理学问题的书,结果是不管怎样的大师和神仙,不管怎样的精确严密自我圆满的逻辑体系,只要拿到现实问题上,就只有在极端限定后的场景里才能生效,对于大部分现象和问题是无法解释,南辕北辙的,这个时候墨守一个空中楼阁的理论工具来强行分析和制定对策出来的效果,绝对不可能比一个街道大妈靠生活经验作出来的分析和对策要好。
当然心理学的场景比抽象结构要复杂艰深的多,但是就一般而言,任何理论框架都只是工具而不是最高纲领,根据实际需要选择各种工具组合解决问题,而不是支持一个最高真理经受试炼展示想神迹,这才是一般解决某个实际问题的正确思路。任何抽象过后构建而成的理论体系【一定】都已经失真了(对于这个世界失真,当然对于这个理论自身而言还可以是继续完美无缺的),都用不着当作神来膜拜,混沌无规则的现实世界才是高于一切的。
当然心理学的场景比抽象结构要复杂艰深的多,但是就一般而言,任何理论框架都只是工具而不是最高纲领,根据实际需要选择各种工具组合解决问题,而不是支持一个最高真理经受试炼展示想神迹,这才是一般解决某个实际问题的正确思路。任何抽象过后构建而成的理论体系【一定】都已经失真了(对于这个世界失真,当然对于这个理论自身而言还可以是继续完美无缺的),都用不着当作神来膜拜,混沌无规则的现实世界才是高于一切的。
43 楼
canonical
2008-11-23
chyy001 写道
数学分为抽象数学与具体数学,计算机技术涉及的是具体数学,数学是理论的,只是提供理论的指导,告诉你怎么做,无法具体到实现,数学是更高层次的抽象,用数学可以很好的推导
这个区分只怕很少有人会认同。
42 楼
chyy001
2008-11-20
数学分为抽象数学与具体数学,计算机技术涉及的是具体数学,数学是理论的,只是提供理论的指导,告诉你怎么做,无法具体到实现,数学是更高层次的抽象,用数学可以很好的推导
41 楼
hotman_x
2008-03-06
嘿嘿,说句不合时宜的话,一个事物“完美”是因为它已经没有价值,没有改进的必要。费力看到0点以后,发现是一帮观点差不太多的家伙在喷口水。
站在没有观点的立场(或者不表明观点的立场)总是最安全的,永远立于不败之地。
这里有人说“XX语言绝对能有效解决所有其它语言能解决的问题”吗?没有。因为连汇编(如果不考虑微指令的话)也不能这么说。
站在没有观点的立场(或者不表明观点的立场)总是最安全的,永远立于不败之地。
这里有人说“XX语言绝对能有效解决所有其它语言能解决的问题”吗?没有。因为连汇编(如果不考虑微指令的话)也不能这么说。
40 楼
element8325
2008-02-09
留个名先,过几年再看!
39 楼
bei-jin-520
2008-01-17
没意思。整个一哲学家在讨论。
38 楼
rubynroll
2007-12-30
耳目一新啊,这样的讨论有时候看起来很爽!口水部分可以掠过,仔细品位实际上每个人想表达的思想都很有深度,只是有时候太挖细节了,导致最重要的信息表达不够那么有效。
Lich_Ray的关于“要先在理论上得到证明...”的说法很有意思,我记得电子科大有个“道系统”嵌入式实时操作系统,可以用数学推演证明(实时性?完备性?),印象深刻。回头看Lich_Ray同学说的话,真希望此系统能够辉煌。不过,我也并不认为没有完备理论证明的系统就没有必要搞,毕竟大部分我们做的东西是没有机会先得到数学证明的,完美的东西固然好,不完美的东西也很有价值。
Lich_Ray的关于“要先在理论上得到证明...”的说法很有意思,我记得电子科大有个“道系统”嵌入式实时操作系统,可以用数学推演证明(实时性?完备性?),印象深刻。回头看Lich_Ray同学说的话,真希望此系统能够辉煌。不过,我也并不认为没有完备理论证明的系统就没有必要搞,毕竟大部分我们做的东西是没有机会先得到数学证明的,完美的东西固然好,不完美的东西也很有价值。
37 楼
crazyox
2007-12-27
......
感觉自己来自另一个世界, 好功力呀! 先收藏了, 等以后能看懂的时候再说!
感觉自己来自另一个世界, 好功力呀! 先收藏了, 等以后能看懂的时候再说!
36 楼
SilenceCliff
2007-12-12
T1的陈述更能 使我心悦诚服。或许个人阅读结构和解读视角的问题。
Anyway,本质这种东西,耳熟能详之时,扑朔迷离之始。
Anyway,本质这种东西,耳熟能详之时,扑朔迷离之始。
35 楼
hampster
2007-12-12
有点发晕,优雅又易懂的设计不好吗?
34 楼
javavsnet
2007-12-11
good!
33 楼
canonical
2007-12-11
引用
good!
我的原话不是这一句。谁在后台改了这个帖子?
32 楼
jelly
2007-12-11
确实看不懂,为什么大家都喜欢说一些别人看不懂的东西呢?
将简单的逻辑非要套上学究的术语,那不是好像孔乙己一样。
我认为将复杂的道理用通俗的语言能够表达出来才是大师的境界,才是我们追求的境界把,不然岂不是曲高和寡,身在高处不胜寒?
将简单的逻辑非要套上学究的术语,那不是好像孔乙己一样。
我认为将复杂的道理用通俗的语言能够表达出来才是大师的境界,才是我们追求的境界把,不然岂不是曲高和寡,身在高处不胜寒?
31 楼
canonical
2007-12-10
我所阐述的只是一种视角的转换,它不是说必然给你提供某种超越当下的能力,而是说以一种不同的眼光看待所有的一切。视角变换后,我们发现了一些新的命题,而在原先的视角下在我们的话语体系中原本是无法表达这些命题的。串行程序假设了只有1颗CPU, 而函数式语言假设了可以有无限多个CPU, 你不觉得1至无穷之间缺点什么吗。你感觉不到现在的软件领域有什么不平凡的例子,是吗?这说明你创造的时机来临了。你可以创造一些东西把1至无穷之间的空白补齐,概念空间是连续的。
整个Witrix就是针对视角转换之后一次不平凡的技术尝试,当然限于商业机密,我不可能阐述很多。我所能够表达的都已经写在了我以前的blog中,有兴趣自己去看吧。
整个Witrix就是针对视角转换之后一次不平凡的技术尝试,当然限于商业机密,我不可能阐述很多。我所能够表达的都已经写在了我以前的blog中,有兴趣自己去看吧。
30 楼
javavsnet
2007-12-10
我想我刚刚明白了canonical同学/前辈的意思。canonical同学是说某种通用语言,对于某个领域问题的描述能力是不够的。在有了两个“某”以后,这句话是无懈可击的真理。但是这句话对于我来说太泛泛了,基本上是没有用的。canonical同学的10个线程的例子忒通俗易懂了,也忒不够深入了,没有讨论的余地。我很想看到更复杂更深入的例子,说明通用语言的结构在描述某些问题的时候是不够了,例如T1说的轻量级线程通讯的例子(也许我没有集中起足够的注意力,没有精确的描述出来),这里T1说的问题只是一个例子,我指的不是这个例子,是类似这个例子的,复杂的,需要深入思考才能得出结论的例子。这个要求可能有点过分,我的本意就是想通过讨论长学问。
canonical同学的另一个观点,结构是独立于语言的,可以抽象出通用的结构来描述领域问题,这个观点实在一些,不过我还是很贪婪的希望能看到更多的例子说明。用你们的增强了的extends算子在描述领域问题的时候究竟有什么直观的好处,这样俺更容易理解。
canonical同学的另一个观点,结构是独立于语言的,可以抽象出通用的结构来描述领域问题,这个观点实在一些,不过我还是很贪婪的希望能看到更多的例子说明。用你们的增强了的extends算子在描述领域问题的时候究竟有什么直观的好处,这样俺更容易理解。
发表评论
-
从面向对象到面向切面
2011-05-08 12:01 18121. C语言抽象出了软件所在的领域(domain): 由变量v ... -
业务架构平台的自举问题
2011-02-11 14:00 1512业务架构平台的设 ... -
模型驱动的数学原理
2011-02-07 02:45 1902一种技术思想如果 ... -
结构的稳定性
2009-12-06 12:17 2652结构的稳定性,直 ... -
结构的自足性
2009-10-07 16:59 2417说到软件建模,一 ... -
行为聚集
2009-07-11 21:34 1274软件开发技术的技术本质在于对代码结构的有效控制. 我们 ... -
信道构建
2009-03-22 21:05 1418分层是最常见的软 ... -
同构与同态:认识同一性
2009-02-28 16:52 3214现代数学是建立在等价类这一概念的基础之上的。同构是对等 ... -
类型化:形而上学的信仰
2009-02-21 19:38 1589有一个心理 ... -
从编写代码到制造代码
2009-02-15 18:15 3126软件开发作为一种 ... -
逆元:不存在的真实存在
2009-02-07 22:12 4289负数没有直接 ... -
文本化
2009-01-04 00:51 2041软件技术的发展是 ... -
关于代码生成和DSL
2008-11-23 11:52 5736代码生成(Code Ge ... -
软件不同于建筑
2008-09-01 23:26 1356软件系统的构建之所以与建筑工程不同,无法达到建筑工程的精 ... -
AOP on XML Tag
2008-07-07 00:09 1679AOP(Apsect Oriented Programm ... -
主从分解而不是正交分解
2008-05-26 00:36 2427说到分解,很多人心中的意象大概只有正交分解。正交分解无疑是 ... -
不完全的计算
2008-03-16 15:20 1635在与一些年岁较大的C程序员接触的过程中,可以比较明显的感 ... -
WebMVC之前世.今生
2008-02-18 22:23 1880所谓WebMVC即Model2模型是目前Web开发领域的主 ... -
关系模型与ORM
2008-01-06 19:20 2012关系数据库模型在理论上主要解决的是消除数据冗余的问题。 ... -
代码之外的结构
2007-12-15 19:49 1770我在各种场合一直都在强调结构问题是独立的,在程序语言之 ...
相关推荐
在Java编程语言中,面向对象程序设计是核心概念之一,它涉及类、对象、封装、继承和多态等原则。集合框架是Java中处理对象集合的重要工具,它为开发者提供了存储和操作对象的统一标准。本讲座将深入探讨Java集合框架...
本文旨在为读者提供关于Java集合框架的概览性介绍,帮助理解其整体架构与设计理念。对于希望深入掌握特定接口或类使用方法的学习者,建议查阅官方提供的Java API文档。 #### 一、概述 数据结构在软件开发中扮演着...
集合框架的核心在于它的一系列接口和实现类,这些接口和类允许程序员以面向对象的方式来处理数据,极大地提高了代码的可读性和可维护性。在集合框架中,泛型机制的引入则进一步提升了类型安全性和代码的简洁性。 ...
面向对象程序设计中的集合框架与泛型是Java编程中至关重要的概念,主要用于高效地存储、管理和操作对象。在这个实验报告中,我们将深入探讨这两个主题。 首先,Java集合框架是一个统一的架构,它提供了多种接口和类...
在处理复杂数据存储时,集合框架是必不可少的工具,而Map接口则是集合框架中的一个重要组成部分。Map接口定义了键值对(key-value pairs)的数据结构,使得我们可以根据键来高效地查找对应的值。 在农业信息系统...
Java集合框架是一种通用数据结构和算法框架,位于java.util包中,由于其灵活的面向对象设计技术受到广大Java程序员的一致青睐,并为Java平台的成熟奠定了坚实的基础。Java集合框架由四部分组成:接口、抽象类、实现...
Java面向对象程序设计中的集合框架是Java编程中不可或缺的一部分,特别是在农业信息系统的开发中,有效管理和操作数据至关重要。集合框架提供了各种数据结构,如List接口,用于存储有序且可能重复的元素序列。List...
【Java初级教程】Java语言程序设计的第8章聚焦于集合框架,这是一个核心概念,用于组织和管理数据。集合框架是一套接口和类的体系,提供了处理数据集合的方法。本章的目标是掌握ArrayList、HashSet和HashMap的使用,...
Java集合框架的核心在于它的接口设计,主要包括以下几种: 1. **`Collection`接口**: - 这是集合框架中最基础的接口之一,用于表示可以容纳多个对象的容器。`Collection`接口提供了一组通用的操作方法,如增加、...
SSH集合框架环境jar包是Java开发中非常关键的一部分,它由Spring、Struts、Hibernate这三个主要的开源框架组成,常用于构建企业级的Web应用程序。这些框架的集成为开发者提供了强大的功能,使得业务逻辑处理、视图...
C#是一种广泛应用于Windows平台、Web服务以及游戏开发的面向对象的编程语言,而框架设计则是关于构建可复用、高效且易于维护的软件架构的重要概念。 根据压缩包内的文件名,我们可以推测这些文件可能对应于不同章节...
综上所述,《Java面向对象程序设计(第二版)》所涉及的知识点大致涵盖了面向对象编程的核心概念、类与对象、接口与抽象类、包的使用、异常处理机制、集合框架,以及I/O操作等。这些知识点构成了Java编程语言的基础...
在Java编程领域,电话本应用是一个经典的案例,用于展示如何使用集合框架来管理数据,比如存储和检索联系人的电话号码。在这个"java电话本集合框架版"中,我们重点探讨的是如何利用Java的List接口及其实现类来构建一...
10. **集合框架**:Java集合框架包括List、Set、Queue和Map等接口及其实现类,如ArrayList、HashSet、LinkedList等,提供了一种高效管理对象数组的方式。 11. **内部类**:Java支持类的嵌套,包括成员内部类、局部...
SHH框架集合Webservice是一个专为Java开发人员设计的整合性解决方案,旨在简化Web服务的开发、部署和消费。这个框架结合了Spring、Hibernate和Struts(SHH)这三个流行的开源技术,为构建高效、可扩展的企业级应用...
在本项目"基于JAVA集合框架及实用类实现的超市会员管理系统"中,开发者利用了Java的强大功能来构建一个高效、易用的系统,为用户提供了一系列关键功能,如开卡、积分累计、积分兑换、查询剩余积分以及修改密码等。...
10. 集合框架:Java集合框架包括List、Set、Queue等接口,以及ArrayList、LinkedList、HashSet、HashMap等实现类,提供了存储和操作对象的容器。 课后习题答案部分提供了针对这些概念的实践练习,帮助学习者巩固...
Java集合框架包括List、Set、Queue等接口及其实现类,如ArrayList、HashSet、LinkedList等,它们提供了存储和操作对象的高效工具。 六、设计模式 面向对象设计模式是解决常见问题的最佳实践,如单例模式、工厂模式...
8. **集合框架**:Java集合框架包括List、Set和Map等接口,以及ArrayList、LinkedList、HashSet、HashMap等实现类。理解这些集合类的特性和使用场景,能有效提升数据管理能力。 9. **泛型**:泛型引入了类型参数,...