Получаем доступ к приватным свойствам объектов в PHP без рефлексии

Сразу вспомнилось

#define private public

От php я далек, но если уж свойство делают закрытым, то как раз ради ограничения доступа к нему, потому что прямые обращения автор класса счел нежелательными или даже опасными. Подобные нарушения реально нужны или рассматриваются только ради спортивного интереса?

Доказательное планирование

Ваш вариант определенно звучит лучше. Исправил. Благодарю!

Доказательное планирование

Возможно — этой области я не особо компетентен. Я добавил Ваш вариант интерпретации к переводу отдельной сноской для полноты картины.

Доказательное планирование

Да «доказательство» — слишком сильное слово, но «наблюдение» мне показалось все же слабоватым и теряющим смысл. Суть методики сводится к оценкам («показаниям») разработчиков, адекватность или несостоятельность которых и доказывается статистически.

Доказательное планирование

Я тоже столкнулся с рядом трудностей, когда попытался использовать методику. Но и пользу она принесла — пусть все не совсем по плану, зато есть неотфонарная дата завершения) К тому же новые и отсеяные задачи частично компенсируют друг друга — текущий проект еще не закончен, но за три месяца (из теоретических пяти) идем со всего лишь с двухдневным отставанием от первоначального плана, хоть за это время он и изменился процентов на 20…

Доказательное планирование

По поводу оценки времени, думаю, речь идет о том, что начинать нужно нужно с мнения конечного специалиста, а уж насколько ему реально доверять, как раз и покажет исследование. Новоприбывшим разработчикам рекомендуется изначально ставить самый низкий уровень доверия.

Если же в вашу команду приходит новый оценщик, у которого еще нет накопленных данных, предполагайте худшее — приписывайте ему ложную историю с большим разбросом скоростей до тех пор, пока он не справится с полдюжиной реальных задач.

Доказательное планирование

Все картинки взяты из оригинальной статьи. На сайте автора есть ссылка на продукт, поддерживающий описываемый подход.

Стихи в коде

А да — почему-то я тоже equals сперва подумал — тогда звучит)

Стихи в коде

Русские поэты-программисты сильно ограничены необходимость смешивать языки — полностью русских языков программирования не так много(
Так

s = FILENAME + 3

должна читаться суржиком, чтобы звучать, а такое часто ранит чувствительную душу поэта…

Грабли 2: Виртуальное наследование

Вот и грабли просто дают возможность получить по лбу, а уж наступает сам человек. Ясное дело, что само по себе виртуальное наследование ни в чем виноватым быть не может. Цель статьи — предостеречь от неудачного проектного решения, а не обвинить язык.

Грабли 2: Виртуальное наследование

Я имел в виду удивление в первый раз) Потом-то дошло…

Грабли 2: Виртуальное наследование

Да вот и я удивился — один раз

[C++] Всё ли мы знаем об операторах new и delete?

Прочитав про две разные сущности, ожидал дальше увидеть два разных примера применения каждой из них. Но не увидел. Как можно воспользоваться этим различием между new-оператором и new-ключевым словом в процессе разработки?

Грабли 1: Восстание одиноких фениксов

Вот и я к тому же выводу пришел. Иногда этот паттерн помогает, но основывать на нем всю архитектуру явно не стоит.

Грабли 1: Восстание одиноких фениксов

Конечно были) Просто их трудно было найти из-за того, что профилировщик выводил информацию о них в общий список с ругательствами на память, выделенную Singleton'ами. В результате получалось около 10 тысяч сообщений. В общем, довольно проблемная была система. Когда же удалось разобраться с одиночками, осталось несколько сотен реальных проблем.

Грабли 1: Восстание одиноких фениксов

Да, со стековым проблем с псевдоутечкой не было бы. Но осталась бы проблема взаимосвязи. Чтобы обеспечить удаление стековых элементов в заданном порядке, придется создать их в обратном порядке, т.е где-то нужно будет записать что-то типа

Singleton1::getInstance();
Singleton2::getInstance();
//....
SingletonN::getInstance();

Это позволит рассчитывать, что при завершении работы будет удален сначала SingletonN, потом Singleton[[N-1]] и так далее. Но если, например, в деструкторе Singleton1 будет вызов Singleton2::getInstance, то все может и упасть. Кроме того, вызов getInstance только ради того, чтобы обеспечить правильный порядок разрушения похож скорее на костыль, делающий невозможным создание при первом использовании (например, если за время работы приложения Singleton1 ни разу не пригодился, то логично вообще не создавать его экземпляр).

Грабли 1: Восстание одиноких фениксов

Он не пострадал. Его книга вспомнилась из-за восстания удаленных классов. А так он сам и писал, что одного правильного решения, как удалять Singleton классы не существует — все по ситуации.

Грабли 1: Восстание одиноких фениксов

Интерфейс реализации не содержит
class Singleton
{
public static Singleton* getInstance();
//…
}
А пример в статье уже из соответствующего cpp-файла

Грабли 1: Восстание одиноких фениксов

Как это не static. Тогда бы вообще механизм не работал. Я привел пример реализации метода, чтобы показать что использовался не такой подход

Singleton* Singleton::getInstance() {
      static Singleton instance;
      return &instance;
}

То, что метод статический, указывается в заголовочном файле. Я его не приводил, посчитав, что интерфейс Singleton'a уже всем давно примелькался)

Грабли 1: Восстание одиноких фениксов

В приложении существовало большое количество одиночек — классы, отвечающие за ведение лога, загрузку ресурсов, вывод звука. Даже класс с основной логикой приложения был Singleton. А уничтожать их нужно для того, потому что профилировщик видел new без delete и считал все выделенное одиночками утечкой.