这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。
观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。
绝大多数软件不是关于数据的,而是关于我们试图为客户解决的业务问题。它是关于一个问题域的,涉及对象、规则、流程、案例和关系。
当我们从数据开始设计,并根据数据和数据之间的关系(表、外键和x-to-x关系)对系统的其余部分建模时,我们将整个应用程序限制为如何在数据库中存储数据和如何从数据库中检索数据。此外,我们将数据库体系结构公开给软件。
数据库模式是一个实现细节。我们应该可以自由地改变它,而不需要对我们的软件设计进行任何显著的改变。业务层不应该知道表是如何设置的,或者是从视图中提取还是从表中提取,或者是从动态SQL或存储过程中获取表。这种类型的代码永远不应该出现在表示层中。
软件是用来解决业务问题的。我们要处理用户、汽车、帐户、余额、平均值、摘要、转账、动物、消息、包裹、购物车、订单和其他各种真实的有形对象,以及我们可以对它们执行的操作。我们需要根据需要保存、加载、更新、查找和删除这些项。有时候,我们必须以特殊的方式来做这些事情。
But there's no real compelling reason that we should take the work that should be done in the database and move it away from the data and put it in the source code, potentially on a separate machine (introducing network traffic and degrading performance). Doing so means turning our backs on the decades of work that has already been done to improve the performance of stored procedures and functions built into databases. The argument that stored procedures introduce "yet another API" to be manged is specious: of course it does; that API is a facade that shields you from the database schema, including the intricate details of primary and foreign keys, transactions, cursors, and so on, and it prevents you from having to splice SQL together in your source code.
把马放回马车前面。思考问题领域,并围绕它设计解决方案。然后,从问题域导出数据。
我讨厌大学和研究所向新人提供短期编程课程。这完全是对编程艺术和科学的耻辱和蔑视。
他们开始教C, Java, VB(恶心)给那些没有很好地掌握硬件和计算机基本原理的人。
首先应该通过Morris Mano的《计算机系统体系结构》等书籍来教授机器,然后教授指令机器解决问题的概念,而不是蚀写一种编程语言的语义和语法。
我也不理解政府学校和大学教孩子使用商业操作系统和软件的计算机基础知识。至少在我的国家(印度),没有多少学生买得起操作系统,甚至打折的办公套装,更不用说开发软件的巨头(编译器,ide等)。这就引发了盗窃和盗版,并使这种从他们机构的图书馆复制和窃取软件的行为成为一种正当的行为。
他们再次被教导使用一些产品,而不是基本的理念。
试想一下,如果你只被教导2x2 = 4,而没有被教导乘法的概念?
或者,如果你现在被教去测量倾斜在学校复合墙上的杆子的长度,而不是毕达哥拉斯定理