В этом случае также есть ряд проблем.
Например, при тестировании системы с точки зрения безопасности необходимо не только тестировать «черный ящик», но и изучить программный код с целью выявления мест, где про безопасность халатно забыли. Мало времени, много мест рефакторинга, рассредоточение внимания — мало ли причин? А наличие одного единственного слабого место может привести к серьезным проблемам безопасности. За примером далеко ходить не надо — посмотрите web-браузеры )
В большой системе это чревато.
Когда дублирование кода хотя бы в трех модулях, каждый со своей спецификой использования — поддерживать такой код достаточно сложно, очень легко ошибиться.
Интерфейсы также нужны, когда разные части системы разрабатывают разные команды, между которыми слабая коммуникация (например, физическая удаленность команд, работающих над одним проектом).
Реинжинеринг физически необходим, когда простое решение начинает использоваться в разных частях системы, в каждой из которых нужно «так же, но чуть-чуть по-другому».
В некоторых случаях, например, таких, подобные шаблоны проектирования здорово облегчают жизнь тем, кто поддерживает и дорабатывает продукт.
Я всецело согласен, что делать из этого панацею не следует (в этом смысле пример из Википедии можно рассматривать лишь как учебный пример, который вряд ли применим на практике). Но тем не менее ценность обобщенных решений в сложных случаях никто не отменял.
Хотелось заострить на этом внимание, чтобы соблюсти некоторый баланс между «использовать» и «не использовать».
Я бы добавил к статье следующее замечание.
Перед возвратом соединения в пул все Statement'ы и ResultSet'ы, полученные с помощью этого соединения, автоматически закрываются в соответствии с API.
А для таких случаев придумана инкапсуляция )
Поясню: если уж собираем SQL какой-то оберткой, ничто не мешает задавать параметры вместе с плейсхолдером. В итоге параметры будут правильно связано, даже если структура запроса зависит от некоторых условий.
Браво! Побольше бы таких примеров ) А то нынче складывается мнение (у большинства IT-студентов), что, допустим, физику знать для программиста совершенно необязательно.
Не количество, а качество.
Если достигнутой целью будет, например, написание успешной GRID-системы — нет цены такому специалисту ) даже если у него нет другого опыта и достигнутых целей.
Аннотации хороши для статического задания конфигурации.
Они неприменимы, если конфигурация меняется в runtime, например.
Или если нужно уметь подменить конфигурацию без изменения исходников. Бывает, что требуется переконфигурять сервер без заливания новой, еще не до конца протестированной версии исходников.
И хорошо, что у нас еще не все в виде тестов. Потому что:
1) Это заставляет думать головой.
2) Нет заранее подсказанных вариантов, приходится изобретать самостоятельно.
3) При устной форме сдачи можно более полно составить представление о количестве и систематике знаний в голове у учащегося.
Если в ВУЗе по профильным предметам вместо устной формы превалирует письменная, или еще хуже — тестовая, то качество образования в нем значительно ниже, т.к. больше возможностей подсмотреть, списать и т.д. При устной форме это практически нереально.
Поскольку раньше таких средств не было, никто такого и не требовал. А в наше время, когда мобильник есть у каждого, оставаться на связи — это обязательное требование для делового мира. И вполне адекватное.
Например, при тестировании системы с точки зрения безопасности необходимо не только тестировать «черный ящик», но и изучить программный код с целью выявления мест, где про безопасность халатно забыли. Мало времени, много мест рефакторинга, рассредоточение внимания — мало ли причин? А наличие одного единственного слабого место может привести к серьезным проблемам безопасности. За примером далеко ходить не надо — посмотрите web-браузеры )
Когда дублирование кода хотя бы в трех модулях, каждый со своей спецификой использования — поддерживать такой код достаточно сложно, очень легко ошибиться.
Я всецело согласен, что делать из этого панацею не следует (в этом смысле пример из Википедии можно рассматривать лишь как учебный пример, который вряд ли применим на практике). Но тем не менее ценность обобщенных решений в сложных случаях никто не отменял.
Хотелось заострить на этом внимание, чтобы соблюсти некоторый баланс между «использовать» и «не использовать».
Перед возвратом соединения в пул все Statement'ы и ResultSet'ы, полученные с помощью этого соединения, автоматически закрываются в соответствии с API.
По-моему, ответ очевиден: вопрос бессмысленен, т.к. весовые категории разные )
Война браузеров приводит к их улучшению )
Поясню: если уж собираем SQL какой-то оберткой, ничто не мешает задавать параметры вместе с плейсхолдером. В итоге параметры будут правильно связано, даже если структура запроса зависит от некоторых условий.
Например, гениальны творения Баха :-) Но они отнюдь не просты!
Если достигнутой целью будет, например, написание успешной GRID-системы — нет цены такому специалисту ) даже если у него нет другого опыта и достигнутых целей.
Они неприменимы, если конфигурация меняется в runtime, например.
Или если нужно уметь подменить конфигурацию без изменения исходников. Бывает, что требуется переконфигурять сервер без заливания новой, еще не до конца протестированной версии исходников.
1) Это заставляет думать головой.
2) Нет заранее подсказанных вариантов, приходится изобретать самостоятельно.
3) При устной форме сдачи можно более полно составить представление о количестве и систематике знаний в голове у учащегося.
Если в ВУЗе по профильным предметам вместо устной формы превалирует письменная, или еще хуже — тестовая, то качество образования в нем значительно ниже, т.к. больше возможностей подсмотреть, списать и т.д. При устной форме это практически нереально.