Комментарии 8
Что-то начал я слушать про СОЛИД (впервые про него узнал), и какая-то каша там. Прямоугольник, квадрат, я сам не понял и т.д. Ну не понял — не рассказывай. Вообще ситуация с квадратом как родительским классом — странная. По всему должно быть, что квадрат — это чайлд прямоугольника, который чайлд многоугольника, который чайлд фигуры. Но я не программист, я не знаю. Вам виднее…
Доклад я не смотрел, но попробую объяснить про прямоугольник и квадрат, как я понимаю эту проблему.
Если мы говорим о статических прямоугольнике и квадрате (то есть таких, которые мы создаём один раз и не можем после менять), то никаких проблем нет: класс такого квадрата можно сделать потомком класса такого прямоугольника, и принципу LSP это противоречить не будет.
Если же речь идёт о динамических квадрате и прямоугольнике, то тут перво-наперво надо осознать, какая динамичность имеется в виду. Например, можно говорить о прямоугольнике, у которого стороны меняются независимо друг от друга (о таком мы и говорим в этом кейсе). Но можно говорить и о прямоугольнике, который допускается увеличивать/уменьшать, сохраняя пропорции сторон. (А ещё можно говорить о прямоугольнике, у которого сохраняется разность сторон, и тому подобное, на сколько фантазии хватит).
Так вот, если в качестве базового класса мы возьмем динамический прямоугольник с инвариантными пропорциями, то динамический квадрат опять естественным образом делается его потомком — и никакого нарушения LSP! Динамический же прямоугольник общего вида, как ни странно, тоже можно сделать потомком того же базового класса, тогда он будет сиблингом (братом/сестрой) динамического квадрата.
Тут нелишне, правда, заметить, что потомки-то они оба потомки, но на разных основаниях. Динамический квадрат потомок потому, что является частным случаем (subclass-of). А динамический прямоугольник общего вида потомок, потому что расширяет функциональность.
Если мы говорим о статических прямоугольнике и квадрате (то есть таких, которые мы создаём один раз и не можем после менять), то никаких проблем нет: класс такого квадрата можно сделать потомком класса такого прямоугольника, и принципу LSP это противоречить не будет.
Если же речь идёт о динамических квадрате и прямоугольнике, то тут перво-наперво надо осознать, какая динамичность имеется в виду. Например, можно говорить о прямоугольнике, у которого стороны меняются независимо друг от друга (о таком мы и говорим в этом кейсе). Но можно говорить и о прямоугольнике, который допускается увеличивать/уменьшать, сохраняя пропорции сторон. (А ещё можно говорить о прямоугольнике, у которого сохраняется разность сторон, и тому подобное, на сколько фантазии хватит).
Так вот, если в качестве базового класса мы возьмем динамический прямоугольник с инвариантными пропорциями, то динамический квадрат опять естественным образом делается его потомком — и никакого нарушения LSP! Динамический же прямоугольник общего вида, как ни странно, тоже можно сделать потомком того же базового класса, тогда он будет сиблингом (братом/сестрой) динамического квадрата.
Тут нелишне, правда, заметить, что потомки-то они оба потомки, но на разных основаниях. Динамический квадрат потомок потому, что является частным случаем (subclass-of). А динамический прямоугольник общего вида потомок, потому что расширяет функциональность.
так в докладе говорится о том, что квадрат — это базовый класс для прямоугольника (а не его частный случай), так что с imwode я согласен, каша полнейшая. Очень хотелось уловить мысль докладчика, но не получилось.
Тоже ничего не понял, но если подумать, то квадрат может являться родителем для прямоугольника в том случае, если мы исходим от кол-ва свойств. Для описания квадрата достаточно одного свойства — «длина стороны a». Легко высчитываем его площадь, геометрию и прочее. Прямоугольник, унаследованный от квадрата, приобретает ещё и свойство «длина стороны b».
Четырёхугольник или многоугольник уже не очень вписывается в эту цепочку, потому, что у них нет свойства «длина стороны a/b», а есть количество точек и массив этих точек. Но опять же, подобное рассуждение ни к каким конкретным выводам меня не привело.
Четырёхугольник или многоугольник уже не очень вписывается в эту цепочку, потому, что у них нет свойства «длина стороны a/b», а есть количество точек и массив этих точек. Но опять же, подобное рассуждение ни к каким конкретным выводам меня не привело.
Очень плохо. Инструмент надо свой знать. Зачем докладчик взял инструмент в котором не разбирается. Если пишите на PHP приводите пример на PHP. В PHP есть интерфейсы и Вы не допустили бы такое количество ситуаций на докладе: статическое(классовый атрибут) объявление атрибута, заминка с метаклассами. Одним словом идея и желание у Вас отличное, но вот зачем выбрали неизвестный язык совершенно с другой философией непонятно. Опять таки если хотелось показать какие-то инструменты ну взяли бы Java с ее Spring и показали на реальном контейнере IoC.
Второй доклад, а по операциям у меня вопрос нельзя ли взглянуть на исходный код тестов. Так как что-то мне подсказывает, что 3 ** 30 будет оптимизирован на этапе создания байт кода, а вот pow(3, 30) сделает честные вычисления. Предпринимали ли Вы какие-то попытки для отключения оптимизации? Почему Вы используете IPython, а не классический CPython разработанного Гвидо?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Python Meetup 26.09.14: cовершенствуем код и ускоряем Python