Пишу набор классов: RAR, ZIP и Trip. Все они имеют общий интерес: это форматы архивов. Итак, я изначально думал об этом:

1) Напишите базовый абстрактный класс

abstract class Archive {}

И поместите его в «библиотеки / архив / архив.php».

2) Напишите классы zip, rar и trip

class Archive_Zip extends Archive {}

И поместите их в "библиотеки / архив / zip.php"

3) Получите доступ к определенному классу (например, Zip), как это

$this->archive->zip->...

Это был мой первоначальный подход. Однако как вы думаете, это хороший подход? Стоит ли мне вообще их абстрагировать? Каковы плюсы и минусы простого написания файла "библиотеки / zip.php" (и всех остальных по отдельности)?

У вас есть предложения или аргументы против моего подхода? Я сделал что-то плохое?

1
Tower 9 Июн 2009 в 19:31

6 ответов

Лучший ответ

Мне нравится подход Zend Framework.

Файлы :

lib/Archive.php
lib/Archive/Zip.php
lib/Archive/Rar.php

Код:

require_once 'Archive_Zip';
$zip = new Zip();

См. Это: http : //framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.classes

2
eipipuz 9 Июн 2009 в 16:16

Поскольку № 3 на самом деле не следует из № 1 или № 2, альтернативный подход состоит в том, чтобы просто создать экземпляр объекта, когда он вам нужен ... вот так:

$archive = new Archive_Zip();

Готово. Не нужно усложнять его больше, чем нужно.

1
Allain Lalonde 9 Июн 2009 в 15:38

Основное преимущество абстрактного класса - это общий интерфейс, который можно использовать во всем коде. После этого вы сможете переключить реализацию на другой формат архива, не меняя кучу кода. Я нечасто использовал PHP, поэтому этот ответ основан на общих принципах ООП. Казалось бы, архивы были бы хорошим кандидатом для этого подхода, поскольку они разделяют общий набор операций.

1
Mark Goddard 9 Июн 2009 в 15:38

Лично я не особо использовал абстрактные классы. В лучшем случае они кажутся проверкой вашего собственного кода, гарантируя, что вы определили набор методов в своем подклассе.

Само по себе наследование подойдет вам, и поможет иметь базовый класс Archive, если существует ряд методов, общих для ваших подклассов.

0
Annika Backstrom 9 Июн 2009 в 15:38

Самое замечательное в наличии базового класса Archive в этой проблеме состоит в том, что он действительно должен помочь вам определить набор общедоступных методов для клиентского кода для управления архивными файлами, независимо от формата архива. (Другой способ сделать то же самое - определить интерфейс Archive, который реализуют все ваши другие классы. Но я подозреваю, что вы получите общий код во всех классах; наличие Archive в качестве базового класса дает вам хорошее место для этого.)

0
grantwparks 9 Июн 2009 в 16:58

Это зависит от вашей реализации. Будете ли вы использовать шаблон стратегии, чтобы определить, какой алгоритм сжатия использовать? Если алгоритмы сжатия могут использоваться взаимозаменяемо среди других битов кода, абстрагируйте их.

Должны ли они придерживаться одного и того же контракта и иметь общие функции? Вероятно. Это хорошее использование абстракции.

Кроме того, если это просто помогает вам создать логическую ассоциацию для удобства чтения, дерзайте. Это мое мнение.

1
Kevin Swiber 9 Июн 2009 в 15:38