Поставил на НР 6540 и Toshiba L40-15F.
WiFi, звук и видео работают нормально.
Скорость работы хорошая. Хорошая альтернатива Windows для
дома-для-семьи.
думаю, это для крупных компаний, которым нужна высокая надежность, масштабируемость для БД Оракла. здесь это получат.
девиз Оракла: железо и софт созданы друг для друга. т.е. используя это максимально снимаем возможные проблемы на уровне железа.
Наверно, Автор имеет ввиду способность гибко распределять и масштабировать вычислительные русурсы при применении виртуализации,
что приводит к более экономному расходованию аппаратных ресурсов.
Понимаете ли, весь смысл дискуссии в том, повсеместно ли применим ООП-дизайн. Ну и да, не надо путать «определение объектов прикладной области» и построение модели классов, это совсем не одно и то же.
Как я уже говорил, я не понимаю, почему для произвольной прикладной задачи ядром проекта будет модель классов.
Я бы еще раз попросил бы вернуться в тему «ООП», хотелось обсуждать «Как нам это правильно сдеать в ООП», а не то, нужно ли ООП или нет, в определенных случаях.
Мой «message» звучит таким образом:
чаще всего наибольшие трудности возникают при построении модели прикладной области, то, что автор статьи называет «домейнщиной».
Автор, как раз и говорит, что тяжело решить кому какие методы привязать, что решается вводом объектов-менеджеров.
Нет. Сущности выделяют при анализе бизнес-процесса.
Вы о какой методике анализа бизнес-процессов говорите?
Я почему решил что Вы про БД, так как термин «сущность» у меня ассоциируется с концептуальной моделью БД.
Вы почему-то считаете, что объектная модель — это обязательный результат проектирования прикладного решения. Вам не приходит в голову, что бывают иначе декомпонуемые системы?
Я ранее писал, что рассуждаю в рамках дискуссии посвященной ООП-дизайну, соответсвенно говорю про декомпозицию методом определения объектов прикладной области.
Ядро системы очень часто не имеет ничего общего с прикладной областью.
Возможно Вы неправильно меня поняли, я имею ввиду не то, что иногда называют «engine». Я имею ввиду фокусирование инженера-программиста на построении модели классов, для него это «ядро» проекта.
И иногда эти два аспекта могут быть реализованы даже в разных парадигмах.
Эта проблем решается выделением специальной сущности — «менеджера». В результате у объекта типа «банковский счёт» не остаётся метода перевести_на(счёт, сумма), а вместо этого у объекта типа «менеджер счетов» появляется метод перевести_с_на(с_счёт, на_счёт, сумма).
Вы говорте о том, что мы приходим к тому, что «Domain objects» лишаются методов и все, что касается их поведения передается объектам-менеджерам. Это удобно с точки зрения дизайна ПО, но это «ломает» концепцию моделирования кусочка реального мира с помощью ООП(полагаю это основная причина его создания), так как бизнес-логика отделяется от бизнес-объектов.
Проектировать нужно модель сущностей. А куда они там лягут — в классы, в БД или в сообщения — другой вопрос.
если мы дискутируем в рамках статьи Автора, посвященной ООП-дизайну, то я не согласен. Позвольте изложить свое
видение:
Начинаем проектирование с определения объектов прикладной области(Domain Objects), они же Бизнес-объекты. Сущности, как Вы написали, определяют при построении концептуальной модели БД. Мы же заходим с другой стороны.
Анализируем прикладную область, строим различные модели, в финале строим модель классов, а уже потом проектируем БД(если мы планируем ее использовать) для сохранения объектов.
Думаю, что концентрация на модели классов очень важна, так как это и есть «ядро» системы(с позиции инженера-программиста), насколько точна и удобна будет эта модель, зависит успех конструирования ПО.
Современные domain classes, кроме того, на деле почти всегда являются «прослойкой» к записям в таблицах баз дынных и проектируются изначально в СУБД или в средстве проектирования СУБД.
мне кажется, что сейчас часто главное это моделирование прикладной области, которое может является довольно сложной задачей, поэтому проектировать нужно именно модель классов. А куда «лягут» объекты, в реляционную или объектную СУБД, в XML или в другое «хранилище» объектов, это другой вопрос.
Приложение на флеше не зависит от браузеров, а только от флэшплеера.
Разработка на HTML5 ещё не гарантирует преимуществ перед flex, т.к. находится в стадии становления.
Сейчас браузерные войны закончились и проблем с кросс-браузерной совместимостью стало гораздо меньше, чем раньше.
Уход с Flash в HTML/CSS/JS является тенденцией, ее нужно только увидеть.
Например, сайт поддержки компании Oracle, был выполнен на Flash. Пользоваться им было, мягко говоря, нудобно. Хотя поначалу впечатлял визуально. Некоторое время назад компания анонсировала, что появилсь и HTML-версия, которую можно выбрать при входе, но она еще не настолько функциональна, как Flash. Затем сообщение, что обе версии равны по функционалу. И вот совсем недавно, что Flash-версия будет отключена и дальнейшая работа будет в HTML-версии.
Сильными козырями Flash были, и еще наверно остаются, потоковое аудио/видео.
Но ведь вам этого не надо? Уже где-то показывали VoIP-звонилку на HTML5, youtube уже на HTML5.
«Цветут бурным цветом» различные JS-библиотеки, облегчающие создание визуальных компонентов и предложений в этой сфере станет еще больше.
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!
Интерфейс — это абсолютно абстрактный класс, который не содержит реализаций методов, а только их объявления.
Классы могут реализовывать один или более интерфейсов.
Для реализации web-интерфейса системы, была выбрана flex-технология (расширяющая базовые возможности flash).
Думаю, что на сегодняшний день это плохая идея.
1) Даже Adobe, владелец технологии, делает шаги в сторону HTML5, правда пока только в области мобильных платформ.
2) Разработка клиентской части медленнее, чем на HTML/CSS/JS, так как требуется перекомпиляция после внесения изменений.
3) Привязка к поставщику(Vendor lock-in), то есть к Adobe: только от него можно получить SDK и среду разработки Flash Builder, альтернативы среды выполнения(flash plugin), тоже пока сильно уступают «Flash Plugin» от Adobe.
WiFi, звук и видео работают нормально.
Скорость работы хорошая. Хорошая альтернатива Windows для
дома-для-семьи.
девиз Оракла: железо и софт созданы друг для друга. т.е. используя это максимально снимаем возможные проблемы на уровне железа.
что приводит к более экономному расходованию аппаратных ресурсов.
Я бы еще раз попросил бы вернуться в тему «ООП», хотелось обсуждать «Как нам это правильно сдеать в ООП», а не то, нужно ли ООП или нет, в определенных случаях.
Мой «message» звучит таким образом:
чаще всего наибольшие трудности возникают при построении модели прикладной области, то, что автор статьи называет «домейнщиной».
Автор, как раз и говорит, что тяжело решить кому какие методы привязать, что решается вводом объектов-менеджеров.
Фразу понял, просто не могу привыкнуть к применяемой Вами терминологии.
Вы о какой методике анализа бизнес-процессов говорите?
Я почему решил что Вы про БД, так как термин «сущность» у меня ассоциируется с концептуальной моделью БД.
Я ранее писал, что рассуждаю в рамках дискуссии посвященной ООП-дизайну, соответсвенно говорю про декомпозицию методом определения объектов прикладной области.
Пожалуйста объясните фразу «результат проектирования прикладного решения».
Возможно Вы неправильно меня поняли, я имею ввиду не то, что иногда называют «engine». Я имею ввиду фокусирование инженера-программиста на построении модели классов, для него это «ядро» проекта.
Простите, Вы здесь о чем?
Вы говорте о том, что мы приходим к тому, что «Domain objects» лишаются методов и все, что касается их поведения передается объектам-менеджерам. Это удобно с точки зрения дизайна ПО, но это «ломает» концепцию моделирования кусочка реального мира с помощью ООП(полагаю это основная причина его создания), так как бизнес-логика отделяется от бизнес-объектов.
если мы дискутируем в рамках статьи Автора, посвященной ООП-дизайну, то я не согласен. Позвольте изложить свое
видение:
Начинаем проектирование с определения объектов прикладной области(Domain Objects), они же Бизнес-объекты. Сущности, как Вы написали, определяют при построении концептуальной модели БД. Мы же заходим с другой стороны.
Анализируем прикладную область, строим различные модели, в финале строим модель классов, а уже потом проектируем БД(если мы планируем ее использовать) для сохранения объектов.
Думаю, что концентрация на модели классов очень важна, так как это и есть «ядро» системы(с позиции инженера-программиста), насколько точна и удобна будет эта модель, зависит успех конструирования ПО.
мне кажется, что сейчас часто главное это моделирование прикладной области, которое может является довольно сложной задачей, поэтому проектировать нужно именно модель классов. А куда «лягут» объекты, в реляционную или объектную СУБД, в XML или в другое «хранилище» объектов, это другой вопрос.
Сейчас браузерные войны закончились и проблем с кросс-браузерной совместимостью стало гораздо меньше, чем раньше.
Уход с Flash в HTML/CSS/JS является тенденцией, ее нужно только увидеть.
Например, сайт поддержки компании Oracle, был выполнен на Flash. Пользоваться им было, мягко говоря, нудобно. Хотя поначалу впечатлял визуально. Некоторое время назад компания анонсировала, что появилсь и HTML-версия, которую можно выбрать при входе, но она еще не настолько функциональна, как Flash. Затем сообщение, что обе версии равны по функционалу. И вот совсем недавно, что Flash-версия будет отключена и дальнейшая работа будет в HTML-версии.
Сильными козырями Flash были, и еще наверно остаются, потоковое аудио/видео.
Но ведь вам этого не надо? Уже где-то показывали VoIP-звонилку на HTML5, youtube уже на HTML5.
«Цветут бурным цветом» различные JS-библиотеки, облегчающие создание визуальных компонентов и предложений в этой сфере станет еще больше.
Интерфейс — это абсолютно абстрактный класс, который не содержит реализаций методов, а только их объявления.
Классы могут реализовывать один или более интерфейсов.
Думаю, что на сегодняшний день это плохая идея.
1) Даже Adobe, владелец технологии, делает шаги в сторону HTML5, правда пока только в области мобильных платформ.
2) Разработка клиентской части медленнее, чем на HTML/CSS/JS, так как требуется перекомпиляция после внесения изменений.
3) Привязка к поставщику(Vendor lock-in), то есть к Adobe: только от него можно получить SDK и среду разработки Flash Builder, альтернативы среды выполнения(flash plugin), тоже пока сильно уступают «Flash Plugin» от Adobe.
Adobe Flash повторяет судьбу апплетов Java.