Как правило у нас в Украине гостендеры идут на «высоких» откатах
Держите плюс =) Так происходит не только у одних вас. Высокие откаты — это чуть ли не единственный пункт при сделке, который на самом деле волнует чиновников.
Ну, СУБД разные бывают. Те, интерфейс которых построен на языке SQL, как раз и надлежит рассматривать как чёрный ящик.
Конечно, в идеале оно так и должно быть. Но в реальном мире вашим «черным ящиком» нужно ещё как-то управлять(устанавливать, настраивать, бэкапить, оптимизировать, масшабировать и т.д. — куча ньюансов) И вот здесь ваши теоретические познания SQL вам уже никак не помогут.
Вы не поняли меня. Я говорил про то, что не стоит "подходить к СУБД с позиции тупой хранилки данных(черному ящику)", т. к. этот подход в большинстве случаев приводит к печальным последствиям(за исключением проектов уровня hello world).
Даже самая «навороченная» СУБД не спасёт вас, если ваши ваши таблицы используются в качестве «свалки данных». Защиты от дурака в СУБД — нет =) Учитесь ею правильно пользоваться.
Но и подходить к СУБД с позиции тупой хранилки данных, пользуясь только синтаксисом самого первого стандарта SQL-89, согласитесь, тоже не правильно.
Как раз-таки из-за того, что большинство программистов подходят к СУБД с позиции «тупой хранилки данных» — и приходится прибегать к нестандартным запросам. И вот здесь — инстументы оракла сильно вас выручают =)
Рекурсия в БД — ЗЛО и не надо других вводить в заблуждение.
Полностью согласен. Проблемы с пониманием этого возникают у программистов, мыслящих только в процедурном ключе. Так же те не понимают как в реляционном мире SQL можно жить без for-ов, while-ов, switch-ей и if-ов… =))
Могу сказать и С++ программистам (простите меня, что о вас совсем забыл). Правда, что бы перефразировать сказанное, мне придётся немного подучить конструкторы в С++ =)).
Может сами попробуете переформулировать пункт №2 в терминах С++? Было бы здорово =))
Второй подход плох в принципе… init() метод можно 1) забыть вызвать, можно 2) вызвать 2жды, а можно и 3) не успеть вызвать(в моногопоточной среде).
Обьект должен рождаться «полноценным» либо «мертвым»(с выбросом исключения). Это упрощает процедуру инициализации приложения и уменьшает количество тесткейсов(вам не придётся писать тесты для случаев 1,2,3).
Единственный экземпляр самому создавать не надо. Он либо уже у вас есть(пришел в качестве параметра конструктора или метода — Dependency Injection), либо вы его получаете через посредника (Service Locator).
Расскажите-ка нам по-подробнее о процедуре тестирования вашего «недоношенного» объекта с 20 свойствами, взаимодействующего с внешними источниками данных и другим окружением на форме? Хотелось бы узнать, как выглядят тесты для такого монстра?
Было бы неплохо, если бы мы обсудили здесь паттерны/анти-паттерны проектирования, которые мешают написанию правильных тестов. Начну первым.
1) Singleton — ужаснейший анти-паттерн в тестировании и разработке. Чрезмерное использование синглетонов в проекте — очень… очень плохое решение.
2) «Недоношенный» обьект — когда после вызова конструктора по-прежнему необходима допололнительная инициализация… в виде вызовов init(), start(), polulate(...) Это всё Гнилой код.
Под мобильными платежами я обычно понимаю «дорогие SMS». Это удобно для потребителя, когда ему нужно провести оплату за какую-нибудь неважную мелочь — картинки посмотреть в закрытом альбоме, купить артефакт в онлайн игре и т.п. Но есть у них и минусы. Например, за квартплату/свет/детсад таким способом платить неудобно(таких денег на телефоне просто нет, нужна квитанция и т.д.). Да и поставщикам услуг для мобильных платежей тоже неохота делиться своими прибылями…
Единственный минус, ИМХО, который доставляет неудобства — это генерируемое в случае ошибки инициализации исключение org.apache.commons.logging.LogConfigurationException. Проблемы в подсистеме логирования не должны «мешать» работе основного кода.
selfix
Держите плюс =) Так происходит не только у одних вас. Высокие откаты — это чуть ли не единственный пункт при сделке, который на самом деле волнует чиновников.
Конечно, в идеале оно так и должно быть. Но в реальном мире вашим «черным ящиком» нужно ещё как-то управлять(устанавливать, настраивать, бэкапить, оптимизировать, масшабировать и т.д. — куча ньюансов) И вот здесь ваши теоретические познания SQL вам уже никак не помогут.
Даже самая «навороченная» СУБД не спасёт вас, если ваши ваши таблицы используются в качестве «свалки данных». Защиты от дурака в СУБД — нет =) Учитесь ею правильно пользоваться.
Как раз-таки из-за того, что большинство программистов подходят к СУБД с позиции «тупой хранилки данных» — и приходится прибегать к нестандартным запросам. И вот здесь — инстументы оракла сильно вас выручают =)
Полностью согласен. Проблемы с пониманием этого возникают у программистов, мыслящих только в процедурном ключе. Так же те не понимают как в реляционном мире SQL можно жить без for-ов, while-ов, switch-ей и if-ов… =))
new MyObject(Panel parent, MyObject.STYLE_FLAT|MyObject.STYLE_RIGHT|MyObject.COLOR_RED).
Это первое, что пришло в голову. Дальше нужно знать специфику вашего контрола =))
Может сами попробуете переформулировать пункт №2 в терминах С++? Было бы здорово =))
Обьект должен рождаться «полноценным» либо «мертвым»(с выбросом исключения). Это упрощает процедуру инициализации приложения и уменьшает количество тесткейсов(вам не придётся писать тесты для случаев 1,2,3).
Расскажите-ка нам по-подробнее о процедуре тестирования вашего «недоношенного» объекта с 20 свойствами, взаимодействующего с внешними источниками данных и другим окружением на форме? Хотелось бы узнать, как выглядят тесты для такого монстра?
1) Singleton — ужаснейший анти-паттерн в тестировании и разработке. Чрезмерное использование синглетонов в проекте — очень… очень плохое решение.
2) «Недоношенный» обьект — когда после вызова конструктора по-прежнему необходима допололнительная инициализация… в виде вызовов init(), start(), polulate(...) Это всё Гнилой код.
Продолжаем список…
JCL уже начиная с версии 1.0.5 лишён большинства проблем, обнаруженных далёком 2002-м году. Остались только фундаментальные проблемы с загрузкой и использованием общих данных/классов, касающиеся любой библиотеки в целом.
Единственный минус, ИМХО, который доставляет неудобства — это генерируемое в случае ошибки инициализации исключение org.apache.commons.logging.LogConfigurationException. Проблемы в подсистеме логирования не должны «мешать» работе основного кода.
Особенно понравилось это Начинаем с начала, или 'Hello, Java World!'. Рекомендую всем жаверам. И начинающим и опытным =)