Вопрос об организации занятий и названии их

Question

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

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

abstract class Archive {}

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

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

class Archive_Zip extends Archive {}

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

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

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

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

Есть ли у вас какие-либо предложения или аргументы против моего подхода? Что-то плохое я сделал?

Answer 1

Мне нравится подход 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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

$archive = new Archive_Zip();

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

Answer 5

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

Answer 6

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

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