我已经读过编程中的一项艰巨工作是如何“在适当的抽象层次上”编写代码。虽然抽象通常隐藏在一个层后面的细节，但是在正确的抽象层次上写一些东西基本上让方法实现决策正确吗？例如，如果我打算写一个代表汽车的类，我将为车轮等提供属性，但如果我要求为没有轮子的汽车写一个类，我将不提供轮子，因此没有“开车”的方法。这是抽象正确的意思吗？
由于
答案 0 :(得分：10)
不太好，
提供正确的抽象级别是知道来自较低级别的多少信息会通过您的级别传递。
假设您正在编写高级HTTP库。也许你会提供一个Get（）方法，一个Head（）方法，一个Post（）方法等，但是你不需要提供对底层套接字的访问，因为你要从用户那里抽象出那些细节。
在你正在使用的Socket之下，有一些你不需要处理的抽象层。 （你只能在你下面的一层获取一个抽象，除此之外，它是该层的工作来处理它下面的层，依此类推）。
例如，您不关心滑动窗口流控制协议，因为TCP正在抽象掉这些细节。
-
如果为了达到目的而在高抽象层编码，则会遇到多个实现细节。当你与图书馆争夺控制权时，这表明你可能工作的水平太高了。
相反，如果您的编码抽象级别太低，您将在实现细节中迷失方向。回到我的HTTP示例，如果您只想对服务器运行Get请求并且在代码中实现TCP握手，那么您可能要么尝试使用库或将TCP代码抽象到库中并通过它与它接口。
-
在我参加的一个课程中，老师有一种解释抽象的有趣方法。他让我们将它们简单地视为对象或场景的“观点”或“观点”。
从一个角度来看，重要的细节从另一个角度来看并不重要。
他把一本书放在桌子上，并为学生分配了角色，如“读者”，“书籍卖家”，“作者”，“图书管理员”或“书籍托运人”，并问我们有关这本书的详细信息我们认为是这个角色对我们很重要。根据分配给一个人的滚动，他们的答案变化很大。
这代表了一种抽象。只需要那些对您很重要的细节，并让所有其他细节在其他地方处理（或者只是落到路边）。
答案 1 :(得分：3)
我认为不是这样。
对我来说，抽象是泛化的同义词。越抽象的东西越多，作者试图以这样的方式思考问题就越容易扩展并应用于新问题。
一般而言，更大的抽象需要更多的努力来发展和理解。如果您是一名开发人员，并且您获得了一个高度抽象的框架，那么您将被迫从框架的角度思考，而不是使用您的常识可能暗示的概念。
因此，在您的示例中，Car将是一个非常低级别的抽象。 RollingVehicle可能更高，而Transport可能是最抽象的。
正确的选择取决于您希望如何广泛地应用您的课程以及您希望它们的理解程度。
答案 2 :(得分：1)
我认为抽象的一个危险方面是它能够擦除或隐藏现实或它所代表的设计。你应该始终保持你所代表的和表示之间的合理距离。 “合理的”我的意思是外部开发人员很容易理解如何编写这个特定的项目。
Joel Spolsky表示，谈论"architecture astronauts"的危险是非常正确的：
当伟大的思想家思考问题时，他们会开始看到模式。他们看看人们互相发送文字处理器文件的问题，然后他们看看人们互相发送电子表格的问题，他们意识到有一个普遍的模式：发送文件。这已经是一个抽象层次了。然后他们再提高一级：人们发送文件，但网络浏览器也“发送”网页请求。当你考虑它时，在对象上调用方法就像向对象发送消息一样！再次是同样的事情！这些都是发送操作，所以我们聪明的思想家发明了一种新的，更高，更广泛的抽象，称为消息，但现在它变得非常模糊，没有人真正知道他们正在谈论什么。嗒嗒