问题标签 [abstraction]

封装和抽象之间的确切区别是什么？

我的问题是如何从应用程序的模型层抽象数据库连接？主要关注的是能够轻松地从不同类型的数据库中进行更改。也许您从一个平面文件、逗号分隔的数据库开始。然后你想移动到一个 SQL 数据库。然后稍后您决定 LDAP 实现会更好。一个人怎么能轻易地计划这样的事情呢？

举个简单的例子，假设您有一个用户，他有名字、姓氏和电子邮件。一个非常简单的 PHP 类表示它可能看起来像这样（请忽略公共实例变量的问题）：

我经常看到人们有一个 DAO 类，其中嵌入了 SQL：

我对此类策略的问题是，当您想要更改数据库时，您必须更改每个 DAO 类的创建、更新、加载、删除函数来处理您的新型数据库。即使您有一个程序可以为您自动生成它们（我不是特别喜欢），您也必须编辑该程序以使其现在可以工作。

你对如何处理这个问题有什么建议？

我目前的想法是为 DAO 对象创建一个超类，具有自己的创建、删除、更新、加载功能。但是，这些函数将采用 DAO 的属性数组并生成查询本身。这样，唯一的 SQL 就在 SuperDAO 类中，而不是分散在几个类中。然后，如果你想改变你的数据库层，你只需要改变 SuperDAO 类生成查询的方式。好处？缺点？可预见的问题？黄金三镖客？

例如：脚本对象（如字符串、数组）或脚本引擎（eval()、readFile() 等）之间的兼容性层。

因此，如果一种语言提供更高阶的过程，那么我可以拥有返回过程的过程。就像是：

要创建新程序，我只需执行以下操作：

类似的任务可以在不支持高阶过程的语言中完成，方法是定义Proc接受 4 个而不是 3 个参数并调用此过程来定义ProcA，例如：

那么为什么有这么多关于高阶程序的模糊呢？我错过了什么吗？

我有一个代理，它接受状态并返回动作，同时保持状态/动作对的效用的内部表示。我还有一个环境，可以采取行动并返回状态/奖励对。

我需要能够将代理设置为开始状态，然后不断地从代理 -(action)-> environment -(state, reward)-> agent -(action)->... 但是，内部状态（每次迭代都需要更新）需要保持私有（即在代理或环境中）。这意味着我不能简单地将环境调用为代理中的一个函数，使用状态和动作作为参数。

我有点像 Haskell noobie，所以我什至不确定这是否可能。

基本上我想要一些字典，它是对遗留#define指令的抽象。

我有一个包含 6000 多个定义的旧头文件，这些定义用作标志参数组函数，这些定义表示一种类型的 entity parameter。

在 C 我有

在Java中我想打电话

并且 Parameter 将封装与从库中获取参数相关的所有逻辑。

参数实例会自动从标头中提取并转换为 java 代码，但问题是 Parameter 类变得太大 - 即我得到code too large编译错误（让我下划线：有超过 6000 个参数）。

而且我会很高兴以一种使 IDE 能够使用自动完成的方式进行这种抽象，并且非常不喜欢将 Parameter 对象存储在 say 中的想法HashMap。

编辑：参数类以下列方式定义：

所以我正在编写一个应用程序，其中一个对象有一堆将消息转发到的委托对象。这个想法是我可以说

并且 aMessage 将被发送给 someObject 的所有代表（对于 aMessage 的任何值）。我能够做到这一点的唯一方法是：

它有效，但必须有更好的方法。该解决方案将参数限制为字符串，并且非常难看。有谁知道转发消息的更清洁、更好的方法？

顺便说一句，我正在使用 squeak，但最好使用独立于实现的解决方案；）

编辑：我应该补充一点，代表与对象属于同一类，所以我不能只覆盖 DoesNotUnderstand:。

IRepository<T>通过拥有一个接口、一个NewsRepository类和一个News实体，我几乎已经完成了我的存储库模式的实现。我遇到的问题是试图将常用方法抽象为基础 Repository 类。

我找不到一种方法来抽象 Get 方法，NewsRepository因为它包含特定的 Linq 表达式。

我的问题是：

1）请问如何将public T Get(int id)方法抽象为基类？到目前为止，我完成它的唯一方法是传入Expression<Func<T,bool>>而不是 int，但是这并没有真正抽象出常见的行为，因为每个子类仍然需要传入一个在每种情况下几乎相同的表达式，即n => n.id == id.

2)如何将子类 GetViolations 和 map 方法传递到 Update 方法的基类中？我想解决方案可能是使用委托，但我无法获得编译的语法

这是一组简化的代码——实际上我有一个 Save 方法，它执行 Update 和 Insert 而不仅仅是这里显示的 Update。

在用 Java 编程时，我几乎总是出于习惯，写这样的东西：

大多数时候甚至没有考虑它。现在，问题是：我是否应该始终将接口指定为返回类型？还是建议使用接口的实际实现，如果可以，在什么情况下？

很明显，使用接口有很多优点（这就是它存在的原因）。在大多数情况下，库函数使用什么具体实现并不重要。但也许在某些情况下它确实很重要。例如，如果我知道我将主要随机访问列表中的数据，aLinkedList会很糟糕。但是如果我的库函数只返回接口，我根本不知道。为了安全起见，我什至可能需要将列表显式复制到ArrayList：

但这看起来很可怕，我的同事可能会在自助餐厅私刑处死我。理所当然地。

你们有什么感想？你的指导方针是什么，你什么时候倾向于抽象解决方案，你什么时候透露你的实现细节以获得潜在的性能提升？

我只是想知道这是否会涉及多层间接？

替代文字 http://img244.imageshack.us/img244/7371/classdiagram1.jpg

我试着做一点解释。这个想法是我在一个只公开 Do 和 Eval 方法的 COM 对象之上构建一个 API。

以前我刚刚将一个 IComObject 传递给 Table 类并直接针对它工作，但这意味着当我尝试测试 Table 类时，我已经模拟了 IComObject 并担心命令会发送到我的表类中的 COM 对象。

基本思想是我有命令运行器，负责在 COM 对象中调用正确的命令，而表（和其他）对象只与命令运行器对话，而不必担心正在执行的命令。然后在我的测试中我可以这样做：

是否有太多的间接层，或者这样可以吗？

注意：我将有更多的类，而不仅仅是表，诸如地图、窗口、对象等之类的东西都会与命令运行程序对话。