关于班级组织和命名的问题
我正在编写一组类：RAR、ZIP 和 Trip。 它们都有一个共同的兴趣：它们都是存档格式。 所以，我最初考虑这样做：
1）编写一个基本抽象类
abstract class Archive {}
并将其放置在“libraries/archive/archive.php”中。
2) 编写 zip、rar 和 trip 类
class Archive_Zip extends Archive {}
并将它们放在“libraries/archive/zip.php”中
3) 像这样访问特定类（例如 Zip）
$this->archive->zip->...
这是我最初的方法。 但是，您认为这是一个好方法吗？ 我应该首先抽象它们吗？ 仅编写“libraries/zip.php”文件（以及所有其他文件）的优点和缺点是什么？
您对我的方法有什么建议或论点吗？ 我是不是做了什么坏事了？
I am writing a set of classes: RAR, ZIP and Trip. They all share a common interest: they are archive formats. So, I initially thought about doing this:
1) Write a base abstract class
abstract class Archive {}
and place it at "libraries/archive/archive.php".
2) Write zip, rar and trip classes
class Archive_Zip extends Archive {}
and place them at "libraries/archive/zip.php"
3) Access the specific class (e.g. the Zip) like this
$this->archive->zip->...
This was my initial approach. However, do you think this is a good approach? Should I even abstract them at the first place? What are the pros and cons of just writing a "libraries/zip.php" file (and all others separately)?
Do you have any suggestions or arguments against my approach? Is there something bad I have done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我喜欢 Zend Framework 方法。
文件：
代码：
请参阅：http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.classes
I like Zend Framework approach.
Files:
Code:
See this: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.classes
由于#3 并不真正遵循#1 或#2，另一种方法是在需要时实例化该对象......如下所示：
完成。 没有必要让它变得更加复杂。
Since #3 doesn't really follow from #1 or #2 an alternative approach is just to instantiate the object when you need it.. like this:
Done. No need to complicate it more than necessary.
抽象类的主要好处是可以在整个代码中使用通用接口。 然后，您将能够将实现切换到另一种存档格式，而无需更改一堆代码。 我没有经常使用 PHP，所以这个答案是基于一般的 OOP 原则。 档案似乎是该方法的一个很好的候选者，因为它们共享一组共同的操作。
The main benefit of an abstract class is a common interface that you can use throughout your code. You will then be able to switch the implementation to another archive format without changing a bunch of code. I have not used PHP a lot, so this answer is based on general OOP principles. It would seem like achives would be a good candidate for the approach since they share a common set of operations.
这取决于您的实施。 您会使用策略模式来确定使用哪种压缩算法吗？ 如果压缩算法可以在其他代码位之间互换使用，请将它们抽象化。
他们是否应该遵守相同的合同并共享共同的功能？ 大概。 这是抽象的一个很好的运用。
另外，如果它只是帮助您为了可读性而创建逻辑关联，那就去做吧。 这就是我的看法。
It depends on your implementation. Will you use a Strategy pattern to determine which compression algorithm to use? If the compression algorithms could be used interchangeably among other bits of code, abstract them.
Should they adhere to the same contract and share common functionality? Probably. This is a good use of abstraction.
Also, if it just helps you create a logical association for the sake of readability, go for it. That's my take on it.
就我个人而言，抽象类并没有太多用处。 充其量，它们似乎是对您自己的代码的检查，确保您在子类中定义了一组方法。
继承本身对您很有帮助，如果您的子类有许多通用方法，那么拥有一个 Archive 基类将会有所帮助。
Personally I have not had much use for abstract classes. At best, they seem to be a check on your own code, ensuring you have defined a set of methods within your subclass.
Inheritance itself will do you well, and it will help to have a base Archive class if there are a number of methods common to your subclasses.
在这个问题中，拥有 Archive 基类的好处在于，它应该真正指导您为客户端代码定义一组公共方法来操作存档文件，而无需考虑存档格式。 （做同样事情的另一种方法是定义一个 Archive 接口，所有其他类都实现该接口。但我怀疑您最终会在所有类中得到一些通用代码；将 Archive 作为基类可以为您提供一个放置它的好地方。）
The great thing about having an Archive base class, in this problem, is it should really guide you to define a set of public methods for client code to manipulate archive files, without regard to the archive format. (The other way to do the same thing would be to define an Archive interface, which all your other classes implement. But I suspect you'll end up with some common code in all of the classes; having Archive as your base class gives you a good place to put that.)