Однако же, указать, какого типа должен быть каждый параметр метода, все-таки можно — при помощи Type Hinting. Так что с этой точки зрения все в порядке.
Почему никто не указал, что PHP слаботипизированный язык.
Поэтому нельзя полноценно указать, какой из типов данных будет присутствовать внутри функции
Это и есть основное различие с типизированными языками, такими как Java или C#. И эта особенность и легла в основу ограничений языка PHP
Поэтому разработчики PHP и не создавали возможность overload(override) для этого языка, потому что неизвестно какой именно параметр и какого именно типа будет в сигнатуре метода
Так как нет возможности перегрузки метода, соотвественно нет и возможности наследования нескольких интерфейсов с одинаковыми именами методов.
Строгий порядок выполнения нужен далеко не всегда.
Геморность для поддержки — вопрос спорный.
Один флаг для очистки после выполнения в последнем тесте — куда проще реализовать, чем создавать, наполнять и удалять каждый раз один полноценный объект
Во-первых, нигде в статье не указывалось, что речь идёт исключительно о юнит-тестировании.
PHPUnit — достаточно полноценный инструмент, чтобы проводить и другие виды тестирования.
Во-вторых, я не спорю про изолированность тестов, и не стараюсь сломать эту идеологию!
Но как пример:
надо создать и промодифицировать объект.
1. создать объект — результатом получить идентификатор объекта (object_id)
2. сохраняем object_id
3. передаем object_id в качестве параметра (плюс дополнительные параметры функции)
Если в качестве зависимости поставить на создание объекта, то в конечном итоге, при несоздании объекта следующий тест проигнорируется. Таким образом, и поведение системы не изменится, и будет известно в каком месте тест не проходит.
А дальше — каждый выбирает тот инструмент и решение, которое ему больше подходит (нравится)
в случае с @depends — сваливается только один тест, остальные игнорируются.
Это поведение уже заложено в PHPUnit.
Я только упорядочил тесты с учётом зависимостей.
Любой код зависит от внешних данных, передаваемых параметров и т.д.
И да, свести к минимуму зависимость от состояния — можно. Но, протестировать реакции на состояние тоже надо. И данный пример (статья) предлагает возможное решение.
Я предлагаю ИНСТРУМЕНТ, которого, по моему мнению, не хватало.
Как его использовать и использовать ли вообще — дело каждого
Обложки может и не быть (ни одна фотография в галерее не отмечена как обложка) — но что-то нужно вывести заместо нее
Под обложкой это и подразумевалось: либо выделенная (is_main_foto), либо первая is_published.
Вопрос был собственно в другом, и я специально вставил условие задания.
Надо вывести альбомы для категорий с лимитом? Почему тогда в условии речь зашла про фотографии, если нигде кроме как «обложка» они не фигурируют?
То есть, если исходить из ситуации, что надо просматривать каждый раз, разрешены ли для публикации все категории, галереи и фотографии — то тогда понятно, почему приходится работать с тремя таблицами одновременно. Хотя мне не встречалось, чтобы можно было получить, допустим id категории, и при этом эта категория была недоступна… (ну это уже надо смотреть на реальные условия)
То есть, условие
3) Для всех задач нельзя показывать пустые галереи и категории, то есть те категории в которых нет галерей и те галереи в которых нет категорий
должно присутствовать во всех запросах. Теперь становится более понятным задание.
Хотя, логично предположить, что условие выполнено, если id уже известно ;-)
А на третье:
Порядок того, что должно быть выведено:
Категории
В каждой категории энное количество альбомов (лимит N)
Для каждого альбома — обложка
Правильно?
Тогда непонятно — каким образом в данную конструкцию вписываются фотографии (кроме обложки), о которых собственно и идёт речь в задании :-/
Если по условию задачи: все элементы ordi разные для одной галереи.
А если с чистой логики: не может один и тот же элемент (с одним и тем же id) иметь два разных значения ordi.
Но ошибка действительно есть ;-) двойку потерял. Да и плюс, элементов в тестовую таблицу накидал парочку всего и просмотрел, что порядок ordi может не соблюдаться, то есть, элемент мы конечно найдём, но не обязательно тот, который действительно искали.
Этот запрос на следущий элемент:
select pim2.*
from photo_image pim cross join photo_image pim2
on (pim.g_id=pim2.g_id and pim.g_id=GALLERY_ID)
where pim2.ordi > pim.ordi and pim2.is_published=1 and pim.id=IMAGE_ID
order by pim2.ordi ASC
limit 0, 1
Этот запрос на предыдущий:
select pim2.*
from photo_image pim cross join photo_image pim2
on (pim.g_id=pim2.g_id and pim.g_id=GALLERY_ID)
where pim2.ordi < pim.ordi and pim2.is_published=1 and pim.id=IMAGE_ID
order by pim2.ordi DESC
limit 0, 1
Кроме того, если уже хочется, чтобы было точно известно, что мы не должны получить тот же id фотографии (хотя и предыдущих запросов хватит), то можно добавить
where pim2.ordi < pim.ordi and pim2.is_published=1 and pim.id=IMAGE_ID and NOT(pim.id=pim2.id)
Ну вот, очередной вариант, когда автор не до конца рассказывает задачу, а в приведённом решении разжевывает каждое решение, основываясь только на том, подходит решение для него лично или нет, или базируясь на однозначно своём решении
Берём условие первой задачи:
Дано ID категории. Нужно написать запрос (один!) который бы получал все галереи этой категории, для каждой из которых получал ID главной фотографии, а если таковой нет — то ID какой-нибудь входящей в категорию (все равно, лишь бы была фота)
И теперь самое главное не понимаем, зачем присоединять дополнительную таблицу, если уже известна c_id? (id категории)
Вторая задача:
Дано ID фоты. Если хотите — так же ID галереи. Требуется с минимум усилий определить следующую/предидущую фоту в порядке по ordi. (напоминаю, что тут только по ordi принимать решение нельзя так как следующая/предидущая может быть и is_published = 0, таким образом надо взять ближайшую которая is_published = 1). Задача решается 2-мя запросами, я уверен что можно решить и одним (без UNION) но у меня не получилось. Если у кого получится тому респект и уважуха. :-)
Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! И самое главное непонятно, зачем делать это одним запросом (хотя условия могут быть разные).
Опять таки, в решении: если уже известна id фотографии, ЗАЧЕМ присоединять ещё дополнительно две таблицы, если можно использовать только одну с фотографиями?
Третья (последняя) меня подвергла в полное уныние, ибо я так понимаю, что все поняли как поняли задачу, соответственно и решили как поняли
Это самая жесть. Дано некоторое число N. Требуется вывести список категорий, и количество последних альбомов в них, причем для каждой категории это количество не должно быть больше N и отсортировано в порядке убывания по ordi. То есть допустим 3 категории, в 1-ой 10 фоток, во второй 25, а в третей только три. Нужно чтоб на выходе было для первой 5 последних (с наибольшими ordi отсортированных по убыванию), для второй 5 (аналогично) и для 3-ей — 3 (аналогично). Плюс условие первой задачи, то есть надо еще главную фоту для галереи или какую-нибудь еще
То есть, если я правильно читаю условие:
1. Дано число N.
2. Вывести список категорий
3. В каждой категории надо вывести список альбомов не более N. и т.д.
Соответственно, выводить надо альбомы? или же всё-таки фотки?
Итоговые вопросы: если альбомы, зачем привязываться к фоткам, если фотки — зачем мучаться с обложкой альбома.
То есть, условие задачи поставленно абсолютно некорректно
Собственно, предложенные решения меня подвергли больше в уныние.
Хотя задачи голову на часок помогли отвлечь ;-)
Можно только для массивов или объектов!
Поэтому нельзя полноценно указать, какой из типов данных будет присутствовать внутри функции
Это и есть основное различие с типизированными языками, такими как Java или C#. И эта особенность и легла в основу ограничений языка PHP
Поэтому разработчики PHP и не создавали возможность overload(override) для этого языка, потому что неизвестно какой именно параметр и какого именно типа будет в сигнатуре метода
Так как нет возможности перегрузки метода, соотвественно нет и возможности наследования нескольких интерфейсов с одинаковыми именами методов.
Геморность для поддержки — вопрос спорный.
Один флаг для очистки после выполнения в последнем тесте — куда проще реализовать, чем создавать, наполнять и удалять каждый раз один полноценный объект
API системы с черным ящиком внутри
И да, в tearDown необходимо использовать флаги для очистки
внутри теста можно указать, когда можно очищать данные
Я не говорил о чужих решениях и чужих ошибках
Речь шла о том, чтобы не использовать копию своего кода
PHPUnit — достаточно полноценный инструмент, чтобы проводить и другие виды тестирования.
Во-вторых, я не спорю про изолированность тестов, и не стараюсь сломать эту идеологию!
Но как пример:
надо создать и промодифицировать объект.
1. создать объект — результатом получить идентификатор объекта (object_id)
2. сохраняем object_id
3. передаем object_id в качестве параметра (плюс дополнительные параметры функции)
Если в качестве зависимости поставить на создание объекта, то в конечном итоге, при несоздании объекта следующий тест проигнорируется. Таким образом, и поведение системы не изменится, и будет известно в каком месте тест не проходит.
А дальше — каждый выбирает тот инструмент и решение, которое ему больше подходит (нравится)
Это поведение уже заложено в PHPUnit.
Я только упорядочил тесты с учётом зависимостей.
Что касается статьи, посмотрим.
Любой код зависит от внешних данных, передаваемых параметров и т.д.
И да, свести к минимуму зависимость от состояния — можно. Но, протестировать реакции на состояние тоже надо. И данный пример (статья) предлагает возможное решение.
Я предлагаю ИНСТРУМЕНТ, которого, по моему мнению, не хватало.
Как его использовать и использовать ли вообще — дело каждого
А если необходимо протестировать общее поведение объекта?
Таск-лист есть, календарь можно синхронизировать (например, с тем же гуглом)
Под обложкой это и подразумевалось: либо выделенная (is_main_foto), либо первая is_published.
Вопрос был собственно в другом, и я специально вставил условие задания.
Надо вывести альбомы для категорий с лимитом? Почему тогда в условии речь зашла про фотографии, если нигде кроме как «обложка» они не фигурируют?
То есть, условие
должно присутствовать во всех запросах. Теперь становится более понятным задание.
Хотя, логично предположить, что условие выполнено, если id уже известно ;-)
А на третье:
Порядок того, что должно быть выведено:
Категории
В каждой категории энное количество альбомов (лимит N)
Для каждого альбома — обложка
Правильно?
Тогда непонятно — каким образом в данную конструкцию вписываются фотографии (кроме обложки), о которых собственно и идёт речь в задании :-/
А если с чистой логики: не может один и тот же элемент (с одним и тем же id) иметь два разных значения ordi.
Но ошибка действительно есть ;-) двойку потерял. Да и плюс, элементов в тестовую таблицу накидал парочку всего и просмотрел, что порядок ordi может не соблюдаться, то есть, элемент мы конечно найдём, но не обязательно тот, который действительно искали.
Этот запрос на следущий элемент:
Этот запрос на предыдущий:
Кроме того, если уже хочется, чтобы было точно известно, что мы не должны получить тот же id фотографии (хотя и предыдущих запросов хватит), то можно добавить
Берём условие первой задачи:
И теперь самое главное не понимаем, зачем присоединять дополнительную таблицу, если уже известна c_id? (id категории)
Вторая задача:
Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! И самое главное непонятно, зачем делать это одним запросом (хотя условия могут быть разные).
Опять таки, в решении: если уже известна id фотографии, ЗАЧЕМ присоединять ещё дополнительно две таблицы, если можно использовать только одну с фотографиями?
Третья (последняя) меня подвергла в полное уныние, ибо я так понимаю, что все поняли как поняли задачу, соответственно и решили как поняли
То есть, если я правильно читаю условие:
1. Дано число N.
2. Вывести список категорий
3. В каждой категории надо вывести список альбомов не более N. и т.д.
Соответственно, выводить надо альбомы? или же всё-таки фотки?
Итоговые вопросы: если альбомы, зачем привязываться к фоткам, если фотки — зачем мучаться с обложкой альбома.
То есть, условие задачи поставленно абсолютно некорректно
Собственно, предложенные решения меня подвергли больше в уныние.
Хотя задачи голову на часок помогли отвлечь ;-)
В запросе было pig, переносил — забыл поменять ;-)
ЗЫ. более интересна реакция на решение второй задачи