PHP Tests Helper - помощник при проведении тестов

На счет предложений:
Добавь метод создания sql кода для заполнения таблиц.

 

И опять про sql. Было бы полезно иметь возможность генерить связанные данные для таблиц. Для проверки join.

 

а вот по поводу проверки скорости работы sql я опять отсылюсь

 

TheShock
Одно замечание по стилистике написания кода:
В интерфейс не следует вносить объявление конструктора и/или деструктора.
Интерфейс описывает логическую абстракцию методов объекта, конструктор же является служебным и, по сути, не является равноправным членом класса.
У объекта, подобно человеку, есть две стадии: рождение и смерть.
Для этих стадий мы можем определить какие-то действия, но, в любом случае, без этих действий невозможна суть существования, т.е определим мы конструктор или нет, существовать он всё равно будет.

Поэтому стилистика объектно-ориентированного программирования не требует описания конструктора в интерфейсе, поскольку интерфейс оъбявляет методы, которые должны быть обязательно в имплементирующем классе, а конструктор и деструктор так и так существует на уровне объекта.

Это только поправка.

 

Интерфейс лишь создаёт регламент методов, которые обязаны быть реализованы в классе.
Конструктор так и так существует, опишем мы его или нет.
Поэтому необходимости описывать ни сам конструктор, ни его аргументы — нет.

Во всяком случае на одном иностранном форуме — DevNetworks — мы этот вопрос обсуждали.
Большинство стояло на мнении, что конструктор не должен быть объявлен в интерфейсе, сколько бы аргументов он не принимал.

Лично я придерживаюсь этого, поскольку человек волен распоряжаться конструктором всё-таки так, как он хочет.
А интерфейс задаёт регламент обязательных методов класса, без которых объекта быть не может.

 

По идее описание конструктора в интерфейсе возможно. В тех случаях, когда мне необходимо создавать объект по конкретным данным или вообще без данных. Например, есть интерфейс "Поверхность" и тогда любой объект, реализующий этот интерфейс, должен иметь конструктор с параметрами длина и ширина. Или объект реализующий интерфейс "ПервоеЧтоПопалосьПодРукуДляБроска" должен иметь конструктор без аргументов.

PS. Могу описать алгоритм для join'ов на словах.

 

Я не перестану повторять, что интерфейс задаёт методы, которые обязаны быть реализованы в объекте.
Приведу пример даже: есть интерфейс, описывающий некую модель, возмем ручку.
Какие функции должна реализовывать ручка?
Ею можно писать, для этого внутри должен содержаться ещё один объект - стержень, который находится в оболочке и является low-level объектом по отношению к колпачку.
Так вот интерфейс описания ручки мог вы выглядеть следующим образом:

PHP:

1. <?
2.  
3. interface IPenCommon
4. {
5.     public function Write($text);
6.     public function Flush();
7. }
8.  
9. interface IBar implements IPenCommon
10. {
11.     protected function FillInk($level);
12.     protected function SetInkColor($color);
13.     public function FlushInk($level);
14. }
15.  
16. interface IPen implements IBar
17. {
18.     public function SetCat();
19.     public function DropCap();
20. }
21.  
22. ?>

В данном примере мы может видеть методы FillInk и SetInkColor, которые определяет производитель ручки.
Интерфейс описывает то, без чего не может существовать ручки, производитель может описать следующий класс реализации:

PHP:

1. <?
2.  
3. class GelPen implements IPen
4. {
5.     public function __construct($color, $level)
6.     {
7.         $this->SetInkColor($color);
8.         $this->FillInk($level);
9.     }
10.  
11.     /* Тут идут методы интерфейсов ... */
12. }
13.  
14. ?>

В конструктор передаются аргументы для производства ручки.
Но что если производитель захочет сделать так:

PHP:

1. <?
2.  
3. class GelPen implements IPen
4. {
5.     public static $ob = null;
6.  
7.     public static function CreatePen($color, $level)
8.     {
9.           // Обращаемся к статическому свойству и пишем туда другой класс
10.     }
11.  
12.     /* Тут идут методы интерфейсов ... */
13. }
14.  
15. ?>

Т.е описывая конструктор в интерфейсе вы завязываете руки тому, кто реализовывает этот интерфейс.
Интерфейс обязан описывать только те методы (и свойства), которые класс должен иметь для полноценной работы.
Интерфейс — это не каша из методов, которые из-за прихоти туда запихнули, а очень кратко-структурированное объединение методов, описывающих свойства объекта, которые он будет иметь при себе.
При этом не имеет значения, будет у класса конструктор, или как-то по-другому будут передаваться данные, интерфейсу срать на это, поскольку его цель в описании СТРУКТУРЫ ОБЪЕКТА, а конструктор таковым не является.

 

В отличии от многих других языков, в С++ нет чёткого понятия интерфейса или соотв. типа.
Для этого мы создаёт абстрактный класс (кстати, что мне не нравится в С++, так это реализация класса возможна за его пределами), поэтому он может содержать как свойства, так и методы.
Хотя в С++ — это общий шаблон проектирования, и интерфейсом называется лишь условно.
Поскольку происходит разделение только на логическом уровне там, тут я описал некоторые члены интерфейса как СВОЙСТВА, а не просто методы.

 

Совершенно согласен.
Конструктор в интерфейсе это редкое исключение из правила.

его цель описание поведения объекта.

А вообще я не сразу переключился на PHP. Т.к. в PHP для объекта возможен только один конструктор, то действительно:

 

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

 

Работа с одной таблицей.

Далее идут мысли по реализации, которые не проверены практикой. Думаю при столкновении с реальным миром многое может измениться.

Работа с одной таблицей.
Работа с одной таблицей имеет смысл, только если уже созданы таблицы с которыми мы хотим связать новую.
1. Вызов.
1.1 Вариант 1: добавляем поля в массив.

PHP:

1. <?php
2. $th->createQuery(array(
3.     'table' => 'messages',
4.     'fields' => array (
5.         'ID' => null,
6.         'Text' => array (
7.             'length' => array (8, 64),
8.             'chars'  => StringGenerator::LAT | StringGenerator::SPACES
9.             ),
10.         'newTableId' => array (
11.             'chars' => StringGenerator::NUM,
12.             'range' => array (0,30000),
13.             ),
14.         'oldTableId' => array (
15.             'chars' => StringGenerator::NUM,
16.             'range' => array (0,30000),
17.             ),
18.         ),
19.     'length'  => 100,
20.     'execute' => true,
21.     'links'=> array(
22.         'param' => array(
23.             'DNS' => '...',
24.             'DB' => 'MyDB',
25.             'takeFromDb' => true
26.             ),
27.         0 => array(
28.             0 => array(
29.                 'thisField' => 'newTabId',
30.                 'thatField' => 'id',
31.                 'type' => 'eq',
32.                 'linkTable' => 'newTable',
33.                 'column' => ...
34.                 'numLinks' => array(0, 2)
35.                 ),
36.             1 => array(
37.                 'thisField' => 'oldTabId',
38.                 'thatField' => 'id',
39.                 'type' => 'eq',
40.                 'linkTable' => 'oldTable',
41.                 'column' => ...
42.                 'numLinks' => array(0, 2)
43.                 ),
44.             'length' => 5
45.         1 => array(
46.             'thisField' => 'oldTabId',
47.             'thatField' => 'id',
48.             'type' => 'eq',
49.             'linkTable' => 'oldTable',
50.             'column' => ...,
51.             'numLinks' => array(0, 2)
52.             'length' => 10
53.             )
54.         )
55.     )
56. );
57. ?>

Как видно добавляется элемент links. Он содержит в себе массивы описывающие с какой таблицей связывать, по каким полям, каким образом, массив параметров (возможно имеет смысл перенести все это на объектную основу или выделить нумерованные элементы массива в отдельный массив).
link[0] – описывает запись связанную с двумя таблицами и говорит что надо создать пять таких записей.
link[1] – описывает запись связанную с одной таблицей.

Параметры:
DNS - строка подключения к БД
DB - база данных из которой брать информацию
takeFromDb - нужно ли брать данные из БД.
При takeFromDb=false DNS и DB необязательны и наоборот.
Я не знаю как ты организушь доступ к БД, возможно DNS и DB передавать не нужно.
type определяет как связывать поля. Надо определить как его задавать. Мне приходят в голову следующие варианты:
а) eq - равно, lt - меньше, gt - больше, le - меньше или равно, ge - больше или равно.
б) =, <, >, <=, >=
в) тупо константами 1, 2. 3 и т.д.

linkTable – необходимо при takeFromDb=true, чтобы знать из какой таблицы брать данные.
column – необходимо при takeFromDb=false. Данные из 'thatField'. Скорее всего опять массив.
length – количесто связанных записей. Надо решить либо это количество добавляется к общему числу записей в таблице (fullLength= length+links[0].length+ links[1].length +…), или уже включено в него (length – links[0].length – links[1].length – … = число несвязанных записей). Думаю первый вариант проще в реализации, но второй более удобен для использования.
numLinks – количество связей с одним полем в конечной таблице (от и до). Если array(0), то случайно. Если первая цифра 0, то параметр length обязателен. В противном случае параметр length игнорируется.
1.2 Вариант 2: добавляем аргументы в функцию.
Массив links становится вторым аргументом функции.
2.Проверки
а) Проверяем соответствие длин (если решим включать длины друг в друга).
б) Проверяем соответствие полей для связи полям описанным в массиве fields.
в) Проверяем типы полей для связи на соответствие друг другу.
г) Проверяем подключение к БД. Наличие нужной таблицы и нужных полей в таблице если takeFromDb=true
д) Проверить не конфликтность numLinks для записей, которые одновременно связаны более чем с одной таблицей.

PS. Приду домой продолжу.