我应该如何组织通用编程库的目录结构？

Question

我已经编写了我自己的通用PHP库一段时间了,我正在考虑如何组织目录结构,但我想在我正式化库的目录结构之前得到人们的想法.

这是我到目前为止:https: //github.com/homer6/altumo/tree/master/source/php

我以为我可以"按主题"或"按类别"进行.到目前为止,我只能想到一个我喜欢"按类别"的例子:Boost http://www.boost.org/doc/libs/1_46_1/?view=categorized

此外,Qt是按模块组织的,但我认为它有点乱,因为所有内容都有点填入QtCore http://qt-project.org/doc/qt-5/qtmodules.html

有任何想法吗？

提前致谢.

更新:我发现了一本非常好的书,它向我展示了许多伟大的图书馆设计惯例:http://www.apibook.com/blog/

更新:我发现了一篇有趣的文章提到了代码组织(http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html).在底部,它说:"你的代码树会是什么样子？他希望用这些词来形容它:简单,实用,优雅,正交,可组合.这是理想的,现实有点不同."

Answer 1

首先,选择的结构是一个妥协的决定,这意味着你必须根据你的目的处理和优先考虑某些方面.您可以遵循一些分组标准,例如:

• 功能凝聚力,我认为应该是你设计中最强大的.具有相同或类似功能的类/文件/资源​​应该在一起
• 组件层次结构,根据您选择的粒度级别,这意味着如果您更喜欢细粒度组件与粗粒度组件,则在一个文件夹中将拥有更多或更少的文件/资源​​.这可以使用文件夹层次结构和嵌套来控制.
• 更改,某些文件比其他文件更可能更改,您必须牢记这一点,以便根据要修改的概率提供文件夹层次结构.
• 可扩展性,对于一个有用且适用于几乎任何场景的框架,您必须提供扩展组件和功能的可能性.添加扩展文件夹(也就是插件)是个好主意.

你应该使用很多标准,但始终牢记KISS原则.您可以在统一软件开发过程(Ivar Jacobson等人)等书籍中搜索包管理,我希望这可能会有所帮助.

Answer 2

由于它是专用于解决通用问题或提供通用功能接口的多用途库,因此最好具有subject可以是DataType/Technology/Language/Protocol等的结构,如下所示:

+ Http
  - request
  - response
  + util
    - status_codes
+ Html
  - Validator
  + Form
    - UploadFile
  + Tag
+ JavaScript
  - JSON
+ Ajax
+ XML
  - Reader
  - Writer
  - Parser
+ DataType
  - Array
  - Integer
  - String
  - Double
  - Float
  + util
    - datatypes_cast_lib

最重要的是我们有:

• Http这是一个协议,所以你Http.request将成为执行Http请求的接口
• Html是标记语言,因此Html.Form.UploadFile将为开发人员提供创建上传文件表单的功能
• JavaScript是编程语言,因此您的Javascript.JSON可以解决从JSON到Arrays的转换问题
• Ajax是技术
• XML是标记语言
• DataType是......好吧,数据类型.

请注意,这status_codes仍在util在Http.每个子库都可以有自己的util功能,比如DataTypelib可能需要datatype_cast_lib才能知道如何处理数据类型.

这种图书馆组织方式大多类似于PECL的组织化

好问题,BTW!我经常问自己同样的问题.多年来我一直在组织和重组我的目录结构.这真的取决于项目.我已根据你在这里提供的结构调整了上面的结构.

Answer 3

我建议您查看最近的两个 php 5.3 框架Symfony2和Lithium 中的组织方式。

他们背后的核心开发人员（与其他主要框架开发人员和 php 名​​人一起）积极定义标准的 php 5.3 命名约定，以便他们各自的组件可以相互使用，Zend 和其他可能遵循相同约定的库/框架：

http://groups.google.com/group/php-standards/web/php-coding-standard

在这两种情况下，bundle/libraries 都是一等公民，并且在组织它们时两者遵循相似的模式。

特别是 Lithium 内核本身就是一个库。它的组织方式如下：

$ ls
LICENSE.txt analysis    core        g11n        security    template    tests
action      console     data        net         storage     test        util

（我倾向于发现 Symfony 2 有点混乱/预测性较差，但这只是我自己的看法。）