насколько я понял аспекты привязываются к методам по именам. что происходит, если имя метода меняется — авторизация перестает проверятся, логи — записываться? есть-ли для таких случаев поддержка со стороны среды разработки, предупреждения какие-то?
… в тексте они неразличимы. При попытке объяснить, начинается блуждание в трех соснах. :) На самом деле object и type _это_ действительно объекты, но по-разному. :) object это объект потому, что он является экземпляром type, а type это объект, потому что он является подклассом object.
Более того object, и type — это объекты типа (классы), и у них тоже есть специальные атрибуты __name__, __bases___
Для понимания объектной модели python нужно обозначить два вида отношений: subclass-superclass (выражает частное-общее, например «человек» это «живое существо») и instance-type (выражает определение, «Таня» это «человек»). В русском (да и английском) языках, данные отношения обычно называют словом «это» (или «является»), поэтому
Для каждого j>0 заменить все присваивания L=j соответствующей подпрограммой Gj(в том числе и для L=1). Так как L больше никогда не будет присвоено значение j можно убрать проверку L=j (вместе с соответствующей ей веткой выполнения) из структуры программы.
выглядит как «inline» подпрограмм? эта затея осуществима для всех j>0, в любом случае? или тут схема маягче: «Для каждого j>0 пытаться заменить все присваивания L=j… », и «Если L больше никогда не будет присвоено значение j ...». Просто в данном примере заменились не все присавивания — «L=3» в структуре осталось.
Теперь построим цикл while do с заменой предикатных и функциональных блоков.
я правильно понимаю, что на этой схеме получилось нечто похожее на машину состояний — switch, в котором каждый case это подпрограмма, представляющая собой либо выбор нового значения L (одного из двух) либо выполнение операции и назначение нового L?:
L = 1
white L > 0:
switch L:
case 1: if p1 L = 2 else L = 3 ; break
case 2: f1; L = 6 ; break
...
case 8: f5; L = 0 ; break
Мне кажется для скрытия адресной строки есть разумное объяснение — google'у нужна связанность переходов. Для этого нужно, чтобы пользователи щелкали именно по ссылкам на страницах, а не меняли адресную строку как попало.
Значит в вашей системе эта логика является вполне нормальной — бизнес- — наверняка, окруженная полноценными тестами, документацией и проч. семейной атрибутикой. Нашим администраторам такая возможность не требуется. В итоге аналогичный код одиноко подвисает в слое тестов, в виде абсолютно неконтролируемой логики (чуть не сказал — женской). Получается, что интерпретация зависит от конкретного набора требований.
Так вот проблема — нужно-ли писать тесты для MotherObject или нет? :) Голос «за» — они рожают точно такие же объекты, какие появляются на свет у нормальной бизнес-логики (просто какими-то левыми сценариями). Голос «против» — кажется, это будут тесты, ради тестов.
Например, сценария createAndLoginUser() в реальном коде не существует — потому, что пользователей заводит администратор, но ни когда их не логинит. Логиняться пользователи всегда сами, но только в существующий аккаунт.
Однако в тестах очень часто участвуют именно такие вот залогиненные пользователи, поэтому от деталей их создания и логина хочется абстрагироваться. Думаю, такой код мог бы быть контроллером (если бы необходимость в такой логике, по факту, была не только в тестах).
Не знал, что это называется ObjectMother. Мы пришли к подобному паттерну, пытаясь абстрагироваться от часто повторяемых в тестах пользовательских сценариев (залогиниться, создать документ и т.п.). Поэтому называем такие фабрики UserScenario.
Только вот на душе остается какой-то не хороший осадок. Ведь эти «мамы», для того, чтобы рожать каких-то, прямо скажем, незапланированных детей, начинают «залетать» изрядными кусками сервисной логики. Причем эти куски, по своему характеру, очень напоминают соседей из business-logic — хоть тесты на них самих теперь пиши.
Вопрос о слабостях подразумевает, что в ответе вы узнаете про соискателя нечто, что возможно окажется за пределами ваших норм. Порядочный человек ни когда себе не позволит воспользоваться полученными сведениями для того, чтобы с пафосом уколоть соискателя в открывшееся слабое место, обеспечив себе ещё несколько гарантированных плюсиков. ;) Выше об этом уже писали.
Два этических вопроса:
1). Вы собеседуетесь с HR, которая уже наняла для компании 8 сотрудников. Двое из них тупые, трое — ленивые, один — умственно недоразвитый, сама она больна сифилисом. Посоветуете ли Вы ей освободить занимаемую должность?
Но прежде, чем ответить на этот вопрос, ответьте на другой:
2) Происходят выборы на должность программиста и Ваш голос — решающий. Краткие характеристики кандидатов:
а) ответил на все Ваши вопросы.
б) послал ко всем чертям.
Кого же Вы выбираете? Ответили?
Дневной оборот среднего предприятия, отправляющего платежи в банк, равен примерно сумме операций обычного физического лица за пол года-год. Отсюда мы получаем необходимость совсем разных систем для совершения операций там и там.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вся спецификация вот тут rfc2396. Синаксис URI, в самом общем случае, имеет вид:
<scheme>:<scheme-specific-part>
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
на днях, рассматривая логи коммитов, нашел удивительную чехорду патчей:затем
и так несколько раз. а как должно быть pythonic?
а нужно-ли делать, отступы на пустых строках, или нет:
или
?
записывать простоне напомните :?
насколько я понял аспекты привязываются к методам по именам. что происходит, если имя метода меняется — авторизация перестает проверятся, логи — записываться? есть-ли для таких случаев поддержка со стороны среды разработки, предупреждения какие-то?
Добавьте ссылку: www.cafepy.com/article/python_types_and_objects/python_types_and_objects.html — классическое чтиво по этой теме, объясняющее объектную модель python на простых примерах с картинками.
Для понимания объектной модели python нужно обозначить два вида отношений: subclass-superclass (выражает частное-общее, например «человек» это «живое существо») и instance-type (выражает определение, «Таня» это «человек»). В русском (да и английском) языках, данные отношения обычно называют словом «это» (или «является»), поэтому
кажется, что вариант комменте по ссылке не верный — если условие b изначально '0', то хвост алгоритма (E) не выполнится ни разу.
Так вот проблема — нужно-ли писать тесты для MotherObject или нет? :) Голос «за» — они рожают точно такие же объекты, какие появляются на свет у нормальной бизнес-логики (просто какими-то левыми сценариями). Голос «против» — кажется, это будут тесты, ради тестов.
Однако в тестах очень часто участвуют именно такие вот залогиненные пользователи, поэтому от деталей их создания и логина хочется абстрагироваться. Думаю, такой код мог бы быть контроллером (если бы необходимость в такой логике, по факту, была не только в тестах).
Только вот на душе остается какой-то не хороший осадок. Ведь эти «мамы», для того, чтобы рожать каких-то, прямо скажем, незапланированных детей, начинают «залетать» изрядными кусками сервисной логики. Причем эти куски, по своему характеру, очень напоминают соседей из business-logic — хоть тесты на них самих теперь пиши.
Вопрос о слабостях подразумевает, что в ответе вы узнаете про соискателя нечто, что возможно окажется за пределами ваших норм. Порядочный человек ни когда себе не позволит воспользоваться полученными сведениями для того, чтобы с пафосом уколоть соискателя в открывшееся слабое место, обеспечив себе ещё несколько гарантированных плюсиков. ;) Выше об этом уже писали.
1). Вы собеседуетесь с HR, которая уже наняла для компании 8 сотрудников. Двое из них тупые, трое — ленивые, один — умственно недоразвитый, сама она больна сифилисом. Посоветуете ли Вы ей освободить занимаемую должность?
Но прежде, чем ответить на этот вопрос, ответьте на другой:
2) Происходят выборы на должность программиста и Ваш голос — решающий. Краткие характеристики кандидатов:
а) ответил на все Ваши вопросы.
б) послал ко всем чертям.
Кого же Вы выбираете? Ответили?
по-моему, ответ соискательницы это равноценный троллинг, в ответ на неэтичный, по сути, вопрос.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.