Вот такой пример. Предметная область — транспорт.
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…
И правда, потестил сейчас оба варианта. Конкат быстрее оказывается.
Странно, потому что читал о таком способе и там убеждали в быстроте join, и тесты приводили. Я тогда не проверил сам, но запомнил. Извиняюсь, что привёл непроверенную информацию…
Кстати, интересно, что по тестам jsperf.com/concat-vs-join444/2 в некоторых браузерах join всё-таки быстрее. Но в остальных браузерах настолько медленнее, что небольшое превосходство в некоторых браузерах не окупится.
Вот мой тест: jsperf.com/concat-vs-join445
Интересно то, что при повышении объема данных join становится хуже и хуже…
Быстрее будет не складывать строчки, а складывать их в массив и потом join-ить:
var html = [];
for (var i=0; i<100; i++) {
html.push('<div>');
html.push(i);
html.push('</div>');
}
$('#div').append(html.join(''));
Операция join быстрее срабатывает, чем множество +
Спасибо за проделанную работу! Интересный класс получается.
Хотелось бы всё-таки сравнение скорости для вашего класса, DbSimple и PDO. DbSimple ругают за медлительность (по крайней мере, кое-где видел).
Сам использую DbSimple, очень нравится, «магия» в возвращаемом значении select() не пугает.
Да, но Новый Русский влил «кучу миллионов денег», и ему весь дом за год сделали. А свой, бесспорно, красивый дом работящая семья всю жизнь строила. И не удивлюсь, если вас, въехавшего на денёк-другой, тоже попросят прикрутить что-нибудь к их дому.
И ведь оба подхода имеют право на существование, нельзя сказать, что какой-то подход априори лучше. Но строить бизнес на втором подходе? Не стоит.
Интересно было бы календарное — сколько затрачено времени от общего времени проекта, в какой момент начали и когда закончили. Понятно, что программист всё время работал. Но вот другие работы были начаты в определённый момент и закончены в определённый.
Например, «музыку мы начали делать за месяц до релиза (даты, когда в начале думали делать релиз:), продлилось 3 недели».
Подобная инфа была бы не менее ценной, чем по затратам.
Тот же Badoo часто проводит на различных конференциях мастер-классы по хай-лоад. Проводит Алексей Рыбак. Я был в этом году на PHPConf, превосходный семинар (на весь день почти). Очень рекомендую посетить при возможности — не пожалеете нисколько. На самом деле крутая инфа, разжёванно и понятно.
Интересно. Такая фишка дополненной реальности Юрий Никитин описал в «Трансчеловеке» (2006 года роман). Я тогда был в восторге от тех идей, а сейчас они уже начали воплощаться потихоньку.
А почему нет? Я кликнул на ссылку — и мне приятно (10ГБ вместо 5), и человеку хорошо. Благотворительность.
К тому же автор сам благословил (сейчас уже убрал эту фразу).
P.S. Я свою не размещал (хотя, может, и стоило...)
Странный список разрешённых символов в пароле на сайте:
>only contain numbers and the characters a-z or the following special characters: # $ + =., _ — Странно то, что не разрешают вполне безобидные !@%&*()
С другой стороны, тест unitCanTakeDamage тестирует не только наличие метода, но и фиксирует его интерфейс, и если вдруг кто-то добавит ещё один параметр к методу, то тест непременно упадёт, и сразу будет понятно, в чём именно дело. Что довольно ценно, на мой взгляд.
Увидел в начале комментария слово «Agile», и подумал, что он будет в поддержку тестирования. Наверное, я совсем не понимаю, что такое Agile. Как можно практиковать Agile без тестирования? Agile ведь подразумевает, что код будут рефакторить?.. Или вы просто упомянули Agile, но сами его не практикуете?
Да, я знаю, что в манифесте Agile нет про тестирование, но не понимаю, как можно строить процесс разработки, основанный на непрерывном рефакторинге, без использования тестов. Сам я в тех моментах, где приходится делать рефакторинг, уже сильно запарился ручками проводить тесты, и всё-равно вылезают баги. На собственном опыте убедился в необходимости тестирования.
Спасибо за хорошую статью! Просто, но понятно, и задаёт направление для дальнейшего развития. Я сам пока только примеряюсь к юнит-тесированию, и тоже хочу попробовать начать с чего-то такого вот.
Я бы пару тестов объединил в один, например, unitCanTakeDamage и damageTakenReducesUnitHealth. Не понимаю, зачем отдельный первый тест? Он же тестирует только наличие метода takeDamage(), но не его работу. Второй тест проверит и то и другое. Не будет ли разделение на два отдельных теста чрезмерным стремлением затестировать всё подряд? Или именно в этом и заключается TDD? У того же Кента Бека во всех тестах есть assert-ы.
Интересно, что в комментариях больше говорили о тестировании в целом, чем о примере применения тестирования в статье, нет комментариев по делу от гуру TDD. А именно этого просил автор, и хотел бы увидеть и я.
Хм… Всё-таки ошибка перевода тогда.
modularize — гл.; амер. модЕлировать, собирать из блоков
Но уж никак не модУлировать.
Спасибо, сам что-то не догадался посмотреть в оригинал (или поленился?..)
>JavaScript, как и все современные языки, может модулировать логику внутри функций
Что значит «модулировать логику»? Это какой-то термин, или ошибка перевода? Ни разу не встречал этот глагол в контексте логики.
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…
Странно, потому что читал о таком способе и там убеждали в быстроте join, и тесты приводили. Я тогда не проверил сам, но запомнил. Извиняюсь, что привёл непроверенную информацию…
Кстати, интересно, что по тестам jsperf.com/concat-vs-join444/2 в некоторых браузерах join всё-таки быстрее. Но в остальных браузерах настолько медленнее, что небольшое превосходство в некоторых браузерах не окупится.
Вот мой тест: jsperf.com/concat-vs-join445
Интересно то, что при повышении объема данных join становится хуже и хуже…
var html = [];
for (var i=0; i<100; i++) {
html.push('<div>');
html.push(i);
html.push('</div>');
}
$('#div').append(html.join(''));
Операция join быстрее срабатывает, чем множество +
Хотелось бы всё-таки сравнение скорости для вашего класса, DbSimple и PDO. DbSimple ругают за медлительность (по крайней мере, кое-где видел).
Сам использую DbSimple, очень нравится, «магия» в возвращаемом значении select() не пугает.
Теперь бы ещё на Fabric.js версию… Может, kangax сделает?..
P.S. Как вам «Хоббит»? :)
И 2d, и 3d. Феерично! Но css-кода там много…
И ведь оба подхода имеют право на существование, нельзя сказать, что какой-то подход априори лучше. Но строить бизнес на втором подходе? Не стоит.
Например, «музыку мы начали делать за месяц до релиза (даты, когда в начале думали делать релиз:), продлилось 3 недели».
Подобная инфа была бы не менее ценной, чем по затратам.
А можно в таблицу с суммами ещё колонку с потраченным временем добавить?
Весь интернет не стоит жизни одного ребёнка, убитого педофилом.
К тому же автор сам благословил (сейчас уже убрал эту фразу).
P.S. Я свою не размещал (хотя, может, и стоило...)
>only contain numbers and the characters a-z or the following special characters: # $ + =., _ — Странно то, что не разрешают вполне безобидные !@%&*()
Да, я знаю, что в манифесте Agile нет про тестирование, но не понимаю, как можно строить процесс разработки, основанный на непрерывном рефакторинге, без использования тестов. Сам я в тех моментах, где приходится делать рефакторинг, уже сильно запарился ручками проводить тесты, и всё-равно вылезают баги. На собственном опыте убедился в необходимости тестирования.
Я бы пару тестов объединил в один, например, unitCanTakeDamage и damageTakenReducesUnitHealth. Не понимаю, зачем отдельный первый тест? Он же тестирует только наличие метода takeDamage(), но не его работу. Второй тест проверит и то и другое. Не будет ли разделение на два отдельных теста чрезмерным стремлением затестировать всё подряд? Или именно в этом и заключается TDD? У того же Кента Бека во всех тестах есть assert-ы.
Интересно, что в комментариях больше говорили о тестировании в целом, чем о примере применения тестирования в статье, нет комментариев по делу от гуру TDD. А именно этого просил автор, и хотел бы увидеть и я.
modularize — гл.; амер. модЕлировать, собирать из блоков
Но уж никак не модУлировать.
Спасибо, сам что-то не догадался посмотреть в оригинал (или поленился?..)
Что значит «модулировать логику»? Это какой-то термин, или ошибка перевода? Ни разу не встречал этот глагол в контексте логики.