天下第一总是忽悠人,这次轮到我来......似乎也成功了.哈哈.

c++根本不能算是oo语言。这个观点没有得到一致公认，但是凡是熟悉java和c#的程序员，都会同意这种说法。
c++不能算是oo语言的原因，是缺少一个语言内置的内存管理机制，delphi也是如此。而d语言，就可以算是oo语言了。
oo的标志，应该就是设计模式的运用。设计模式，实际上就是面向抽象，面向接口的具体表现。
面向接口，就必须屏蔽对象的细节，对象是如何实现的，外部不应当知道。同样，对象的创建过程，外部也不应当知道。所以，对象的构造函数，应该是不公开的，仅仅由创建对象的工厂使用。
这就引出创建型模式。类库的使用者只知道从工厂取出对象，只知道这个对象实现了那种接口，对其他的事情一无所知。
所以，一个类库，应该只向外部公开工厂和接口的定义。基于这个基础，其他的设计模式才有意义。
那么先看看简单工厂。
public class Factory{
        public static IProduct CreateProduct(){//这个地方不应该在参数中包含产品名称，凡是包含名称的教材都是错误的，这里面包含
//了著名的专家阎某。实现类不该被客户所知，包括它的名称，否则客户的代码就依赖于这个名称了。这就依赖了实现细节。这么一
//来，接口就失去了意义。
return new ProductImplV1();
       }
}
很显然，c++是不能这么干的。这样的话，可能内存泄漏就很难控制了。那么，代码中会到处充斥着管理内存泄漏的代码。设计就违反了简单化的本意。
为了解决这个问题，某些人发明了boost和loki之类的管理框架。但是没有一个好用的，循环引用的问题无法解决，这是问题之一。其二是，大量的c++代码库，无法与boost和loki兼容，而且很多遗留的系统，也无法改造。

看一个语言是否适合做某种系统，并不是看访问数据的组件好不好用。对于进销存（我习惯把它叫erp,这样看起来似乎更值钱，其实是一样的东西，it业的人通过不断制造新名词来牟利）这种程序来说，数据访问，其实只占很小的工作量。越是复杂的，维护时间越长的系统越是如此。
举个例子，每个系统都有权限问题。现在某用户的要求是，上级可以查看但不可以修改下级的订单，同级可以通过设置权限来决定是否可以让他看到订单。这样的问题，肯定不是什么控件能解决的。做erp，实际上最花时间的是这类问题，而非数据访问。数据访问是死东西，就算没有工具，自己都能做出来。好的设计，可以轻易解决这类问题。有时候，只是增加一个对象而已，就使整个问题迎刃而解。
所以，需要一个好的oo语言来解决这类问题。一个不能随便new的语言，肯定是不行的。不能new ,就不灵活，不灵活，就费力，费力就增加成本，增加成本就赚不到钱，赚不到钱就。。。。我说不出来了

引用:

原帖由 yongweisun 于 2007-12-3 18:30 发表
你的代码风格，很有问题。代码的规模无法控制。业务逻辑和数据操作混在一起。结构极其丑陋。
我想你的程序肯定经常出问题的时候，找不到问题出在哪里。然后你会大发脾气，埋怨微软的系统不稳定，到处都是bug。。。。 ...

我的程序很少有问题，就算有也只是在调试阶段，我通过短点很容易就找到！
的确规模不好控制，结构乱！

似乎跑题了

写数据库的程序，我都是无错的。一般都是一次成功。不用调试。不成功一般都是用户名密码输错了。。。。
哈哈，开玩笑的，好久没写了。
想代码少出错，先把方法变短，把自己当笨人，不能自恃智商高，挑战复杂的写法。要知道，诸葛一生唯谨慎啊。

天下第一你就死心吧，人家的进存销收完钱开小票，在各个超市都有。你能做到这个水平吗？

引用:

原帖由 Quan 于 2007-12-13 00:21 发表
天下第一你就死心吧，人家的进存销收完钱开小票，在各个超市都有。你能做到这个水平吗？

钱开小票很容易呀，调用几个API就成了！我决不死心！

引用:

原帖由 w1984721 于 2007-12-13 23:23 发表

钱开小票很容易呀，调用几个API就成了！我决不死心！

不能死心,都写了这么久了不能放弃,拿着你的进销存去超越BILLGATES!GO GO GO!