Prolog построен на правилах. Фактически, любая система, которая полностью описывается набором правил и приоритетами, может быть легко описана на Prolog.
Для изучения концепций языка потребуется:
1) Учебный курс, хотя бы простельнький
2) 1 месяц обучения (предполагается, что общие сведения о языках, построенных на правилах вывода, имеются)
Подход, безусловно, гибкий. Но с его использованием появляются дополнительные проблемы. не претендуя на полноту списка, приведу те, которые пришли на ум:
Неявные ветвления логики. При каждом использовании подобного класса имеется неявное ветвление. Если таких переменных несколько, и на каждую комбинацию условий использовать свой класс, ветвлений становится 2^(количество таких переменных).
Не оговорено, что будет происходить, если объявим две диалектических переменных, каждая из которых при каком-то ограничении должна себя вести как другой класс. Допустим, сработают оба условия. Какой класс в итоге будет выбран?
Сложность отладки. Если в какой-то точке происходит Exception (наиболее простой случай), то понять, какие были значения переменных на момент его возникновения становится намного сложнее. Фактически, это следствие неявных ветвлений логики. Более того, без наличия поддержки IDE для поиска всех возможных ветвлений, анализ выполнения предшествующего ошибке кода становится почти непосильной задачей
Код становится менее прозрачным. Почему? Потому что интуитивно читая new ожидаешь поведения того объекта, который ты создал. Если же реально объект другой, да еще и не просто другой, а динамический, то думать в момент реализации о всех возможных вариантах — это очень сложно.
Увеличение рисков совершения ошибки. Следствие отсутствия прозрачности кода. Для большинства программистов среднего уровня вероятность совершить ошибку возрастает примерно в 2^(количество динамических переменных) раз. Оценка немного завышена (все-таки несколько вариантов, как правило, буду просмотрено), но просматривать все варианты ни один разработчик не будет. Это суждение основывается на личном опыте работы в команде.
Нарушаются базовые предпосылки ООП. В самом деле, сам по себе ООП был придуман для того, чтобы можно было уменьшить связность и увеличить управляемость кодом. Все его парадигмы направлены на уменьшение сложности понимания кода. Предложенная же концепция диалектических переменных наоборот увеличивает сложность.
По-моему данного списка более чем достаточно, чтобы рекомендовать не использовать данных подход.
Для справедливости отмечу плюсы выбранного подхода:
1) Гибкость. Возможность подмены логики без ее переписывания. Более того, Есть предпосылки для подмены классов в runtime. Это позволит изменять серверную логику без перезапуска, что является существенным плюсом для серверных решений.
2) Лаконичность. В итоге можно написать меньше кода, который будет делать то же самое.
В скобках не зря написано — рассматривать только синтаксис.
Насчет громоздкого кода. Конструкции типа Enum<T extends Enum> встречаются не только в стандартной библиотеке ) А, например, граф, параметризуемый типами вершин и ребер — уже минимум два generic-типа. Детально расписывать устройство проекта не буду — это выходит за рамки данного топика. Но сложные generic все-таки иногда необходимы.
В данном случае это как вариант синтаксиса.
Можно предложить и более лучший вариант.
Аналогов не знаю. Придумалось из-за того, что в двух проектах возникали сложные generic'и, и этой фичи очень не хватало. Согласен с тем, что это далеко не везде нужно, только в специфичных задачах.
Не согласен. Говорится о том, что необходимо поднимать общий уровень знаний. При изучении нового языка действительно изучаешь новые парадигмы (особенно если изучить принципиально отличающийся язык, например, Lisp или Prolog после Java). После этого в голове остается не язык, его синтаксис и семантика (детали забываются со временем), а именно основные идеи, заложенные в основу.
На самом деле, вы же не будете отрицать, что каждый язык создавался по той причине, что существующие языки не поддерживали все необходимые для разработки инструменты? Следовательно, если расставить языки программирования по прямой времени, то становится несколько более понятно, зачем это было сделано. И в итоге оно дает предпосылки к тому, куда двигаться дальше в этом направлении. И если за этим следить и, более того, участвовать, то будешь становиться все более и более классным специалистом.
Хотелось бы дополнительно отметить, что это высказывание сохраняет силу вне зависимости от специализации программиста на каком-то рабочем наборе языков.
Да, там исключение, так и должно быть.
Но вопрос стоит — что будет выведено? Перед исключением будут выведены еще и результаты выполнения метода print(), их и требуется показать.
Из своего личного опыта могу добавить, что самое важное в планировании:
1) Записывать все важные дела. Под важными понимаются:
— дела, завязанные на других людей (как правило задаются интервалом, в который они должны быть сделаны)
— работа (подвид первого, но лучше выделять отдельно)
2) Каждый день тратить по 10-15 минут (проще всего вечером) на планирование дел, как правило достаточно на неделю вперед
3) Всегда иметь под рукой этот список
Это помогает осуществить так называемое «глобальное» планирование.
Для каждого же подвида по необходимости имеет смысл делать собственное планирование, чтобы не сваливать все в одну кучу. Здесь очень важен принцип не более 7 фокусов внимания.
Я не зря подчеркнул слово «актуальные».
Проблема в том, что обычно в репозитории лежит рабочая версия кода, а на сервере — последний релиз. При этом иногда случаются форс-мажорные ситуации, когда в результате хот-фиксов релиз не соответствует НИ ОДНОЙ сборке из репозитория. Редкость, но все-таки иногда случается. В этом случае наличие XML предпочтительнее аннотаций.
Предлагаю улучшения к статье, чтобы пример стал более жизненным:
Для рассматриваемого класса NutritionFacts логично предусмотреть getter'ы для неизменяемых полей. Иначе получается, что объект-то мы построим, а воспользоваться им не сможем.
Поля Builder'а логичнее именовать в соответствием с конвенцией JavaBeans, а именно setXXX(). Поскольку данный способ является уже стандартом де-факто для Java, подобный подход улучшит читабельность кода.
Хотелось бы подметить, что для больших проектов использование XML вместо аннотаций удобнее, т.к. можно последить весь маппинг в одном месте. Когда же маппинг размазан по классам, навигация становится затруднительной. Естественно, это относится к тому случаю, когда используемая IDE не поддерживает визуализацию маппинга, построенного на аннотациях.
Вторым аргументов в пользу XML является то, что при поддержке сервера с рабочим приложением при отсутствии актуальных (для данной конкретной версии) исходников наличие файла с маппингом — большой плюс.
Для изучения концепций языка потребуется:
1) Учебный курс, хотя бы простельнький
2) 1 месяц обучения (предполагается, что общие сведения о языках, построенных на правилах вывода, имеются)
После этого его уже вполне можно использовать.
По-моему данного списка более чем достаточно, чтобы рекомендовать не использовать данных подход.
Для справедливости отмечу плюсы выбранного подхода:
1) Гибкость. Возможность подмены логики без ее переписывания. Более того, Есть предпосылки для подмены классов в runtime. Это позволит изменять серверную логику без перезапуска, что является существенным плюсом для серверных решений.
2) Лаконичность. В итоге можно написать меньше кода, который будет делать то же самое.
Насчет громоздкого кода. Конструкции типа Enum<T extends Enum> встречаются не только в стандартной библиотеке ) А, например, граф, параметризуемый типами вершин и ребер — уже минимум два generic-типа. Детально расписывать устройство проекта не буду — это выходит за рамки данного топика. Но сложные generic все-таки иногда необходимы.
Можно предложить и более лучший вариант.
Аналогов не знаю. Придумалось из-за того, что в двух проектах возникали сложные generic'и, и этой фичи очень не хватало. Согласен с тем, что это далеко не везде нужно, только в специфичных задачах.
На самом деле, вы же не будете отрицать, что каждый язык создавался по той причине, что существующие языки не поддерживали все необходимые для разработки инструменты? Следовательно, если расставить языки программирования по прямой времени, то становится несколько более понятно, зачем это было сделано. И в итоге оно дает предпосылки к тому, куда двигаться дальше в этом направлении. И если за этим следить и, более того, участвовать, то будешь становиться все более и более классным специалистом.
Хотелось бы дополнительно отметить, что это высказывание сохраняет силу вне зависимости от специализации программиста на каком-то рабочем наборе языков.
Но вопрос стоит — что будет выведено? Перед исключением будут выведены еще и результаты выполнения метода print(), их и требуется показать.
1) Записывать все важные дела. Под важными понимаются:
— дела, завязанные на других людей (как правило задаются интервалом, в который они должны быть сделаны)
— работа (подвид первого, но лучше выделять отдельно)
2) Каждый день тратить по 10-15 минут (проще всего вечером) на планирование дел, как правило достаточно на неделю вперед
3) Всегда иметь под рукой этот список
Это помогает осуществить так называемое «глобальное» планирование.
Для каждого же подвида по необходимости имеет смысл делать собственное планирование, чтобы не сваливать все в одну кучу. Здесь очень важен принцип не более 7 фокусов внимания.
Да будет так.
Проблема в том, что обычно в репозитории лежит рабочая версия кода, а на сервере — последний релиз. При этом иногда случаются форс-мажорные ситуации, когда в результате хот-фиксов релиз не соответствует НИ ОДНОЙ сборке из репозитория. Редкость, но все-таки иногда случается. В этом случае наличие XML предпочтительнее аннотаций.
Вторым аргументов в пользу XML является то, что при поддержке сервера с рабочим приложением при отсутствии актуальных (для данной конкретной версии) исходников наличие файла с маппингом — большой плюс.