в оригинале принцип звучал так: «What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.»
т.е. вообще говоря, LSP определяет некое условие, когда один тип объектов можно считать подтипом другого. и хотя и указатели, и классы имеют отношение к типам, но в целом, не сводятся только к ним. поэтому об этих вещах, в отношении данного принципа, можно говорить лишь в смысле каких-то частных интерпретаций.
кстати, принцип имеет импликативную форму (A => B), а это значит, что обратное утверждение в нём не сформулировано. следовательно, на основании данного принципа нельзя утверждать обратное: дескать, «правильное» наследование — когда S is a subtype of T — обеспечит неизменность поведения вашей программы при использовании объектов первого типа, вместо объектов второго типа. чем, кстати, в некоторых кейсах ООП активно пользуются — передавая программе разные объекты для того, чтобы изменить её поведение. образно говоря, хотя тип «колёса легкового автомобиля» являются конкретизацией типа «колёса», легковушка может вести себя на дороге по-разному, в зависимости от конкретной «резины».
в жизненном цикле программы можно условно выделить два периода: разработки и развития. в период разработки, когда все требования и код запросто помещаются в голове, эффект от TDD на фоне других методик не очень заметен. просто держите себя в руках, следуя классическим методикам программирования — ООД, паттерны, и что там ещё проходили в школе — и вы обязательно достигнете желаемого результата. преимущества от TDD появляются на втором этапе, когда, условно говоря, часть предыдущих разработчиков уже уволилась, а у оставшихся нюансы требований стёрлись из памяти. в отличие от людей, тесты не бросают работу и ни чего не забывают.
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
Также то, что Unicode поддерживается только UTF-16, а не UTF-8, что было бы сильно логичнее.
ходят слухи, что ms office понимает csv в utf-8 когда в начале файла есть нужный BOM (так-ли это на самом деле не могу проверить за неимением сего чуда).
мм. интересно, это чудо как-то ограничивает количество пунктов в меню и количество символов в надписях? как реагирует если у уже открытого меню меняется описание javascript'ом (добавил 100 пунктов, через секунду убрал)? как решат проблему, что в меню можно добавить пункты с привычными пользователю названиями, но выполняющие совершенно иные действия?
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.
думаю, корпорации это бизнес, а бизнесу нужны гарантии. заказчик, заключая полугодовой контракт с разработчиком сайта, хочет быть уверен, что получит современный результат. разработчик, в свою очередь, хочет зафиксировать объем работ. как быть, если за это время появятся ещё две версии браузера, с неизвестными нюансами? по сути — лишние риски, которые ни заказчику, ни разработчику нафик не упёрлись.
Мажорные версии браузеров, для разработчиков сайтов, долгое время символизировали определённые стандарты и, соответственно, степень проработки вёрстки под них, то бишь объём работ в итоге, ТЗ, контракты… Куда понесло FireFox? 4 версии X 2,5 популярные платформы нехило прибавят работы верстакам и тестировщикам за этот год — такими темпами себестоимость веб-интерфейсов скоро станет слишком высокой. Зачем гонка версий нужна «корпорации добра», понятно — они строят собственную платформу. А вот на что рассчитывает Mozilla?
хотел сказать, что такой интерфейс для отправки POST запроса мне кажется бесчеловечным. в мире TDD есть лучшие примеры, реализующие ту же функциональность. прямо мм… как некоторые шоткаты на хабре)
видимо, так и появилась возможность пушить коммиты из prime в hub — вполне себе решение, если нет возможности содержать процесс с блэк^H^H^H^H стэйджингом и тестировщиками)
вы контролер из аэроэкспресса? (у меня уже несколько раз проверяли валидность билета методом такого вот гениального взгляда на распечатку с баркодом, без всякой аппаратуры :))
т.е. вообще говоря, LSP определяет некое условие, когда один тип объектов можно считать подтипом другого. и хотя и указатели, и классы имеют отношение к типам, но в целом, не сводятся только к ним. поэтому об этих вещах, в отношении данного принципа, можно говорить лишь в смысле каких-то частных интерпретаций.
кстати, принцип имеет импликативную форму (A => B), а это значит, что обратное утверждение в нём не сформулировано. следовательно, на основании данного принципа нельзя утверждать обратное: дескать, «правильное» наследование — когда S is a subtype of T — обеспечит неизменность поведения вашей программы при использовании объектов первого типа, вместо объектов второго типа. чем, кстати, в некоторых кейсах ООП активно пользуются — передавая программе разные объекты для того, чтобы изменить её поведение. образно говоря, хотя тип «колёса легкового автомобиля» являются конкретизацией типа «колёса», легковушка может вести себя на дороге по-разному, в зависимости от конкретной «резины».
поэтому на коротких, одноразовых вещах (включая и описанные эксперименты на студентах) TDD не даст особых преимуществ, и запросто может оказаться экономически не выгодным. в проектах же, у которых этап развития существенно превышает этап разработки, TDD серьёзно сокращает издержки, снижая риски развала системы. думаю статистика лишь отражает вовлечённость людей в проекты того или иного рода.
мы начали использовать TDD в тот момент, когда развитие одного из наших сервисов пошло вразнос — когда каждое изменение стало откликаться появлением десятка багов в разных местах — стоимость модификаций перешла все разумные пределы и проект оказался на грани закрытия. начали с очевидного — стали описывать тестами требования высокого уровня (т.е. с приёмочных и интеграционных тестов). позже пришло понимание зачем нужно юнит-тестирование. к настоящему времени в проекте сменились два состава разработчиков. месяц назад мы закончили рефакторинг, затронувший почти половину кода. думаю, что без тестов это было бы сделать практически не реально, поскольку все требования наизусть уже не помнит ни кто.
кажется, дизайнеры выбрали себе действительно «серьёзную» ЦА: которая печатает одним пальцем, и воспринимает клавиатуру, в основном, как неотьемлемое ноутбучное украшение.
при «слепой» печати, когда кисти рук лежат на клавиатуре, и смотришь на экран, точки-индикаторы на клавишах находятся вне поля зрения, а индикатор на Caps Lock не будет видно совсем, ведь именно эта часть клавиши всегда закрыта мизинцем левой руки. зато перед глазами постоянно будут мелькать индикаторы питания, жесткого диска и т.п. фигня, которая бывает полезна лишь в редких случаях, в остальных лишь утомляет глаза.
отсутствие переходников hdmi/vga в комплекте означают дополнительные телодвижения для подключения внешнего монитора или проектора на презентациях. неужели такая «экономия» в комплектации действительно даёт недешевой модели сколь-нибудь существенное конкуретное преимущество в цене?
при всём уважении к марке, данная модель не вызывает желания её купить.
а если вместо отступов сделать скобочки, будет обратно похоже на Lisp :)
хотел сказать, что такой интерфейс для отправки POST запроса мне кажется бесчеловечным. в мире TDD есть лучшие примеры, реализующие ту же функциональность. прямо мм… как некоторые шоткаты на хабре)