Где-то читал, что для управления боевыми системами подводной лодки достаточно 486-го процессора. Видимо для управления менее сложными системами он более чем подходит. Потому и производят.
Писал про самые обычные либы.
А интерфейс менять плохо. Лучше расширять его наследованием. Например если надо изменить интерфейс Component, делаем ComponentEx отнаследованный от Component, и добавляем новые методы.
И обратная совместимость сохранится.
В свое время хапнул горя с JNI. Был враппер к внешней либе. Проблемы были с управлением памятью. Для сборщика мусора нативные объекты не существуют. Он вполне может грохнуть java-объект, который держит указатель на нативный, хотя нативный еще используется. В итоге падает вся ява-машина, вместе с аппликейшн-сервером и всей инфраструктурой.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Из моего опыта.
Встречал, приближенно, три типа заказчиков.
1. Хочу вот такую штуку. Без техзадания. Без требований. Устное или письменное перечисление благих пожеланий.
2. Вот техзадание. Все довольно подробно, но без конкретных требований.
3. Техзадание и список требований со скриншотами, таблицами, порядком и принципами работы, описанием оборудования и моделей девайсов.
В первом случае, при попытке наладить диалог, выяснить требования, составитьь какой-никакой план, обосновать бюджет заказчик пропадает. Если повезет и он таки появится на связи, то с гордостью сообщает, что нашел исполнителя в два-три(!) раза дешевле.
Во втором случае все доходит до планирования работ. Попытки обосновать проектирование и подробный список требований, договора с включением списка требований, как критерия исполнения договора приводят к тому, что заказчик отказывается от услуг. В качестве причины — нашел в 1,5-2 раза дешевле.
В третьем все проходит на ура, список требований, как часть договора, готовится техпроект, утверждается, начинается разработка. Принимается, подписывается акт приемки. Все довольны, заказчик остается с вами и в дальнейшем снабжает проектами и работой. Как причину объясняет, что у нас все быстро, качественно, то что надо, в срок, и в 2-3 раза дешевле.
Имхо, когда заказчик точно знает, что хочет, то знает чего от исполнителя требовать. И адекватно стоимость и качество оценивает.
У меня есть опыт работы в конторах, в которых был компонентный подход в командной разработке, есть опыт работы в конторах, где этого подхода нет.
В компаниях с компонентым подходим проект разбивали на компоненты для удобства планирования разработки и тестирования. Сторонние библиотеки и компиляторы были строго регламентированы. Работал билд-сервер.
Для компонентов, которые были строго частью проекта, интерфейсы писали с использованием PIMPL идиомы. Для компонентов, которые могли быть расширены в функциональности и могли бы иметь более широкое применение, интерфейсы делали COM-подобными.
При таком подходе очень удобно автоматизировать тестирование. И не раз случалось, компонентом интересовались из другого отдела. Проблем с переносом в таком случае практически никогда не было.
Возможно второй пример в моей статье не очень удачный, скорее всего я просто не весь контекст ситуации для второго примера изложил.
Как примеры:
Компонеты отделялись по функциональности и разработчикам.
Надо написать протокол — берем либу из другого отдела, реализующую доступ к TCP. Сверху пишем свою либу, реализующую протокол. Тест для нее отдельный. Это один человек.
Нужен XML парсер для настроек. Другой человек. Отдельный компонент и тест.
Доступ к базе. Отдельный компонент. COM-интерфейс. База ведь может расширяться. Тестирование отдельно.
Тестировщикам всегда есть чем заняться. Какие-то компоненты готовы раньше, какие-то позже.
Я в статье рассказал, что если решили использовать компонентную модель разработки, то вот как можно писать интерфейсы.
Ну как-то так.
Рожденное в приватной функции решение я выношу в какой-нибудь Tools.lib, как и написал в статье.
На счет приватных функций в интерфейсе компонента, приведите пример, плз.
Да где я тут догмы пропагандирую? И перфекционизм где?
Я рассказал, как можно интерфейсы оформлять.
А никто и не говорил о культе. Все согласны, что бывают задачи, которые очевидно могут быть использованы неоднократно. Да и хотя бы в целях удобства отладки логически законченный функционал отлаживать и тестировать удобнее отдельно. Вот ради таких случаев и следует реализовывать его в отдельном компоненте.
А про приватные методы в интерфейсе, вот этого я не понял. Это к чему? Я как раз пытался рассказать, что этого делать нельзя.
«Т.е. уважаемый предлагает плевать на задачи которые ставятся перед разработчиками и разрабатывать модули с тестированием во всевозможных условиях пусть даже далеких от реалий проекта»
Я такого не писал.
«реализовать работу приложения по определенному интерфейсу для работы с API какого либо сервиса»
Описываем, какие функции из API сервиса нам нужны. Пишем интерфейс, предоставляющий работу с этими функциями. В идеале пишем тест для интерфейса. Реализуем компонент-wrapper между API сервиса и нашим приложением. Пока пишем, постоянно проверяем тестом работу компонента. Компонент отлажен. Подключаем его к проекту.
Если нет времени — можно тест не писать. Отлаживать запарно только.
Да, и никого ни к чему не принуждаю. Личное дело каждого, сколько потом реализаций одного и тоже же будет.
А интерфейс менять плохо. Лучше расширять его наследованием. Например если надо изменить интерфейс Component, делаем ComponentEx отнаследованный от Component, и добавляем новые методы.
И обратная совместимость сохранится.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Встречал, приближенно, три типа заказчиков.
1. Хочу вот такую штуку. Без техзадания. Без требований. Устное или письменное перечисление благих пожеланий.
2. Вот техзадание. Все довольно подробно, но без конкретных требований.
3. Техзадание и список требований со скриншотами, таблицами, порядком и принципами работы, описанием оборудования и моделей девайсов.
В первом случае, при попытке наладить диалог, выяснить требования, составитьь какой-никакой план, обосновать бюджет заказчик пропадает. Если повезет и он таки появится на связи, то с гордостью сообщает, что нашел исполнителя в два-три(!) раза дешевле.
Во втором случае все доходит до планирования работ. Попытки обосновать проектирование и подробный список требований, договора с включением списка требований, как критерия исполнения договора приводят к тому, что заказчик отказывается от услуг. В качестве причины — нашел в 1,5-2 раза дешевле.
В третьем все проходит на ура, список требований, как часть договора, готовится техпроект, утверждается, начинается разработка. Принимается, подписывается акт приемки. Все довольны, заказчик остается с вами и в дальнейшем снабжает проектами и работой. Как причину объясняет, что у нас все быстро, качественно, то что надо, в срок, и в 2-3 раза дешевле.
Имхо, когда заказчик точно знает, что хочет, то знает чего от исполнителя требовать. И адекватно стоимость и качество оценивает.
В компаниях с компонентым подходим проект разбивали на компоненты для удобства планирования разработки и тестирования. Сторонние библиотеки и компиляторы были строго регламентированы. Работал билд-сервер.
Для компонентов, которые были строго частью проекта, интерфейсы писали с использованием PIMPL идиомы. Для компонентов, которые могли быть расширены в функциональности и могли бы иметь более широкое применение, интерфейсы делали COM-подобными.
При таком подходе очень удобно автоматизировать тестирование. И не раз случалось, компонентом интересовались из другого отдела. Проблем с переносом в таком случае практически никогда не было.
Возможно второй пример в моей статье не очень удачный, скорее всего я просто не весь контекст ситуации для второго примера изложил.
Как примеры:
Компонеты отделялись по функциональности и разработчикам.
Надо написать протокол — берем либу из другого отдела, реализующую доступ к TCP. Сверху пишем свою либу, реализующую протокол. Тест для нее отдельный. Это один человек.
Нужен XML парсер для настроек. Другой человек. Отдельный компонент и тест.
Доступ к базе. Отдельный компонент. COM-интерфейс. База ведь может расширяться. Тестирование отдельно.
Тестировщикам всегда есть чем заняться. Какие-то компоненты готовы раньше, какие-то позже.
Я в статье рассказал, что если решили использовать компонентную модель разработки, то вот как можно писать интерфейсы.
Ну как-то так.
На счет приватных функций в интерфейсе компонента, приведите пример, плз.
Да где я тут догмы пропагандирую? И перфекционизм где?
Я рассказал, как можно интерфейсы оформлять.
А про приватные методы в интерфейсе, вот этого я не понял. Это к чему? Я как раз пытался рассказать, что этого делать нельзя.
Я такого не писал.
«реализовать работу приложения по определенному интерфейсу для работы с API какого либо сервиса»
Описываем, какие функции из API сервиса нам нужны. Пишем интерфейс, предоставляющий работу с этими функциями. В идеале пишем тест для интерфейса. Реализуем компонент-wrapper между API сервиса и нашим приложением. Пока пишем, постоянно проверяем тестом работу компонента. Компонент отлажен. Подключаем его к проекту.
Если нет времени — можно тест не писать. Отлаживать запарно только.
Да, и никого ни к чему не принуждаю. Личное дело каждого, сколько потом реализаций одного и тоже же будет.