现代软件开发抽象的含义

时间:2010-04-07 15:34:54

标签: language-agnostic abstraction

我目前正在撰写一篇关于当今软件开发实践或教学可能对编程的长期影响产生影响或危险的论文。

只是说清楚:我没有攻击编程中的使用抽象。每个程序员都知道抽象是模块化的基础。

本文要研究的是抽象在软件开发中可能产生的正面和负面影响。至于积极的,我相信我可以找到许多可以证实这一点的来源。但是抽象的负面影响又如何呢?你有什么故事要分享那些谈论某些抽象失败的时候吗?

主要关注的是,今天的许多程序员都在编写反抽象的编程,而不是对抽象在封面下做什么的最微弱的想法。这很可能导致错误和糟糕的设计。那么,在你看来,程序员实际上知道抽象之下的内容有多重要?

Joel's Back to Basics得到一个简单的例子,C的strcat:

void strcat( char* dest, char* src )
{
     while (*dest) dest++;
     while (*dest++ = *src++);
}

上面的函数存在一个问题,即如果你正在进行字符串连接,那么函数总是从dest指针的开头开始找到空终止符,而如果你按如下方式编写函数,你将返回一个指针到串联字符串的位置,这反过来允许您将此新指针作为* dest参数传递给串联函数:

char* mystrcat( char* dest, char* src )
{
     while (*dest) dest++;
     while (*dest++ = *src++);
     return --dest;
}

现在这对于抽象来说显然是非常简单的,但它与我将要研究的概念相同。

最后,您如何看待学校更倾向于教Java而不是C和Lisp?

关于这个问题,你能否提出你的意见和你的意见?

感谢您的时间,感谢您的每一条评论。

4 个答案:

答案 0 :(得分:1)

首先,抽象是不可避免的,因为它们可以帮助我们处理令人兴奋的事情。

抽象也是不可避免的,因为个人越来越需要承担更多任务甚至完成项目。为了解决这个问题,我们使用包含较低级别概念并暴露更复杂行为的库。

当然,开发人员越来越少地了解事物的内在函数。我在SO页面上听到的最新问题是开始用jQuery库学习JavaScript,完全忽略了原始的JavaScript。

问题在于:

之间的平衡
  • 了解某些技术的细节,并掌握它,但同时又无法使用其他任何技术。

  • 对各种各样的技术和工具的肤浅知识,然而这些技术和工具证明对于日常工作来说已足够,这使得个人可以在多个领域执行,可能涵盖某些(中等规模)项目的所有方面。

    < / LI>

选择。

有些工作要求另一个,另一个要求另一个。

  

那么,在你看来,程序员实际上知道抽象之下的内容有多重要?

如果人们知道幕后发生的事情会很好。这种知识来自时间和实践,在一定程度上。取决于你有什么样的任务。你当然不应该因为不了解一切而责怪别人。如果你希望一个人能够在各个领域表演,那么他将不可能有时间覆盖每一个领域。

重要的是基本构建模块的知识。数据结构,算法,复杂性。这应该为其他一切提供基础。

了解某些特定技术的最微小细节是好的,但不是必需的。无论如何,你无法全部学习它们。他们太多了,他们不断前来。

  

最后,您如何看待学校更倾向于教Java而不是C和Lisp?

学校根本不应该教授编程语言。他们将教授理论和实践CS,社交技巧,沟通,团队合作的基础知识。涵盖各种各样的主题和问题,为毕业生提供广角视角。这将有助于他们找到自己的方式。无论他们需要详细了解什么,他们都会自己做。

答案 1 :(得分:1)

抽象失败的例子:

在这种情况下,需要一个软件来与许多不同的第三方数据处理器进行通信。通信是通过各种消息传递协议完成的;在这种情况下,传输方法/协议并不重要。假设每个人都通过消息传递进行沟通。

这个想法是将每个第三方的功能抽象为一个统一的消息格式。这似乎相对简单,因为每个第三方都执行了类似的服务。问题是,一些第三方使用不同的术语来解释类似的功能。还发现一些第三方具有其他第三方没有的附加功能。

抽象的设计者没有看到第三方术语的差异,也没有认为将统一特征的范围限制为仅支持第三方的共同特征是合理的。相反,开发了一个单一的整体消息模式来支持当时考虑的第三方的任何和所有功能。在可能被认为是面向未来的行动中,他们添加了一种方法,即在单片消息无法处理的未来数据元素的情况下,还传递无限数量的名称/值对以及单片消息。

早期,很明显,由于很多人在关键任务系统中使用它,因此改变整体消息将变得困难。名称/值对的使用增加了。可以使用的每个名称都记录在一个大型电子表格中,开发人员需要查阅电子表格以避免重复名称值功能。然而,该列表变得如此之大,以至于发现在名称值的目的中经常发生冲突。

大多数单片消息的字段现在没有任何用途,主要是为了向后兼容。有一些名称值可用于替换单片消息中的字段。大多数接口现在通过名称/值对完成。如果客户打算与多个第三方通信,则每个客户端需要协调每个第三方可用的名称值。直接与第三方接口将更加简单。

我相信这说明,从整体消息的角度来看,消费者代码的开发者知道幕后发生了什么是很重要的。如果设计人员认为整体消息的消费者不应该必须非常详细地理解抽象,那么整体消息及其相关的名称/值对可能永远不会发生。使用关于输入和预期输出的断言来记录抽象将使生活变得更加简单。

对于没有教授C和Lisp的大学......他们在欺骗学生。您可以更好地了解机器和操作系统与C一起发生的事情。您在处理数据和解决Lisp问题时会有一些不同的观点。我使用了在C,C ++,。Net和Java编写的程序中使用Lisp学到的一些想法。知道即使只是C后学习Java也不是很困难。 OO部分实际上不是特定于编程语言的,所以也许使用Java是可以接受的。

答案 2 :(得分:0)

理解算法的基本原理(例如时间复杂度)和一些关于金属的知识对于设计/编写气味良好的代码至关重要。

但是,我建议,同样重要的是现代抽象和剖析中的教育。我觉得现代抽象让我如此比没有他们更有效率,他们至少和良好的基本面一样重要,如果不是更重要的话。

我教育中缺少的一个重要因素是使用剖析器。当常规和正确使用时,分析器可以帮助缓解基础不良的问题。

答案 3 :(得分:0)

既然你引用Joel Spolsky的话,我就知道他的“漏洞抽象法则”吗?我将为未来的读者提及它。 http://www.joelonsoftware.com/articles/LeakyAbstractions.html

绿色&amp;布莱克威尔的抽象的讽刺谈论了学习抽象的努力。 http://homepage.ntlworld.com/greenery/workStuff/Papers/index.html

术语“宇航员架构”是对过度抽象的反应。

我知道当我在一段时间没有触及Java或C#并且我想写一个文件时,我当然会诅咒抽象,但是必须实例化一个Stream ... Writer ... Adapter .... Handler。 ...

此外,模式,如四人帮。当我在90年代中期首次阅读它们时看起来很棒,但是永远不会记得工厂,外观,界面,帮手,工人,轻量级....