Тенденции современного программирования. Плюсы vs Минусы

а, все-таки знаете про MVC.

"есть хоть какой-нибудь смысл то я идиот."
ну, попробую пояснить.
контроллер - обрабатывает данные и управляющие воздействия от пользователя, информирует модель и представление о необходимости соответствующей реакции.
так вот, в случае со stateless объектами я не смогу программировать, используя классический ОО способ.
предположим у меня есть форма ввода и к ней я хочу пристегнуть какую-либо проверку, причем данные для проверки должны поступать от разных элементов управления. в случае stateless объекта я должен создать объект-посредник, который аккумулирует в себе все введенные поьзователем данные и одним вызовом обратиться к проверяющему объекту, размещенному на сервере. т.е. если бы проверяющий объект был на клиенте или был statefull, то мне не пришлось бы создавать дополнительный объект-посредник. другой пример - это реализация мастера, когда набор элементов управления каждой следующей страницы зависит от выбора, сделанного пользователем на предыдущем шаге.


"А то что никто не поручится за их значения от вызова к вызову"
Инкапсуляция - объединение данных и кода, манипулирующего зтими данными.
я указываю какими данными нужно проинициализировать объект - пусть это будет два числа, потом вызываю метод, например сложения этих чисел и получаю результат совсем не тот, который ожидал получить, какая с точки зрения клиента тут инкапсуляция. серверный объект нарушил контракт, он сложил не те числа. опять же нарушение классических ООП принципов.

еще раз повторюсь в этом случае имеет смысл говорить о компонентно-сервисном программировании, построенном с использованием парадигмы ООП, но никак не о ООП программировании в чистом виде.

"Слишком выского о себе оговорите - Волгоград."
я готов признать, что хватил лишку, если Вы не тот Гость, который судит о Волгограде по этому форуму.

ПС. про полиморфизм почему-то Вы умолчали.

AlTk добавил [date]1107450235[/date]:
Bob,
"практически не касается основной темы."
так вот это: "компонентно-сервисном программировании, построенном с использованием парадигмы ООП" и есть современная тенденция.
при использовании stateless объектов - сервисное программирование, если можно так сказать, а при использовании statefull объектов - компонентное программирование.

 

А если эти два числа статические поля? Тогда все ОК?
Это не единственный пример который демонстрирует "классическую" инкапсуляцию для объектов без поддержки состояния. Когда я говорил, про то, что никто не поручится за их значения от вызова к вызову, меня интересовала возможность определять данные в принципе, а какую смысловую нагрузку они будут нести, можно определить лишь в каждом конкретном случае.

Вы можете возразить, что, мол, я "притянул" компонент или сервис (в вашей терминологии) к определению "классического" объекта. Я же стараюсь вас подвести к той мысли, что современное програмирование уже переопределило концепцию ООП 20 века (Инкапсуляция, Наследование и Полиморфизм). Эта концепция больше не может удовлетворять нуждам современного ОО программирования. Это легко доказать. На сегодняшний день существует несколько формулировок, которые соревнуются между собой в "объективности", но не в одной больше нет слова инкапсуляция.

В том числе компонентно-ориентированное программирование (как современная тенденция) не использует парадигму ООП, но является ООП. Компонент определяет как он может распределяться в качестве прикладного объекта. Одни типы компонентов могут представлять объекты реального мира, другие распределяться на рабочий поток (с поддержкой состояния или без него) и т.д. Но они так и остануться объектами.

А откуда у вас взялось деление на сервисы и компоненты? По какому признаку? Поддержка состояния?

На уровне модели? контроллера? или представления?

к форме и пристегните. (сэкономьте время на модели и контроллере используя ооп и потрате больше услий на форму - на нее пользователи смотрят)

Это действие реализуется у вас контроллером? В этом случае никакого криминала нет. Причем не важно есть ли поддержка состояния или нет, лишь бы этот объект реализовывал рабочий поток. Но это уже специфика каждого конкретного случая - модели.

А если это stateless объект в вашем случае контроллер, то это не удачный выбор компонента для реализации контроллера.

Нужна поддержка состояния между предствалением и контроллером. Для этого существуют специальные типы компонент (для реализации контроллеров). Модель может и не поддерживать состояния. В чем проблема?

 

к сожалению, я потерялся в Вашем сообщении.

попытаюсь написать про то, что понял.
1.
а. есть классическое ООП - назовем его объектно-ориентироанным программированием с исходным кодом.
б. есть компонентное программирование, которое построено на парадигме ООП.
с. есть дальнейшее развитие компонентного программирования, но оно тоже построено на парадигме ООП.
везде есть наследование, полиморфизм и инкапсуляция.
накаждом этапе, грубо говоря, повышались уровни абстракции, повторного использования, платформонезависимости, безопасности и т.д.

2.
после того, как появилось компонентное программирование оно разделилось на две ветки. назовем их объектную и сервисную. в первом случае мы имеем объекты statefull, во втором stateless, опять же, грубо говоря.

3. приемы программирования для объектов statefull и stateless отличаются как для клиента,так и для сервиса.
в случае statefull объектов все остается по-старому, как в классическом ООП, а в случае stateless объектов на клиенте заводится объект-посредник, который копит в себе все необходимые данные, потом их одним вызовом толкает на сервер, а на сервере объект программируется таким образом, что его логика построена на том, что все его данные, а также данные всех других объектов с которыми он взаимодействуют существуют только в период вызова метода объекта клиентом. вот-тут то, с точки зрения клиента и нарушается понятие инкапсулиции в серверном объекте.

ПС. теперь про MVC
M - модель - объект приложения,
С - контроллер см. выше;
V - вид - эранное представление.
в случае со statefull объектами так три объекта и остаются.
в случае cо stateless объектами добавляются лишние объекты-посредники для каждой пары объектов, находящихся в "разных местах" и причем здесь удачность выбора мне непонятно.
соответственно и клиент и сервер для случаев stateless и statefull будут иметь _разный_ исходный код.

ППС. "В том числе компонентно-ориентированное программирование (как современная тенденция) не использует парадигму ООП, но является ООП."
это что???
КОП является (суть) ООП.
ООП построена на (использует) парадигме ООП
следовательно КОП построена на (использует)... (дальше сами).

 

Нет ни классического ООП, ни не классического. Есть ООП в том виде, в котором оно существует сегодня и которое расширяет "вчерашнее" ООП. То есть

Компонентное программирование суть объектно-ориентированное. Компонент декларирует как он может распределятся в качестве прикладного объекта. Наиболее распространеные типыкомпонентов:
- компоненты сущности (персистентные или нет) - моделируют предметы реального мира.
- компоненты действия (с поддержкой состояния или без) - моделируют рабочий поток.
- компоненты управляемые сообщениями (всегда без состояния) - моделируют асинхронные
сообщения
- адапторы ресурсов (транзакционные и нет) - используются для интеграции.
и т. д.
Присмотритесь. Компоненты различаются функциональным назначением, но никак не поддержкой состояния. А объединяет их концепция ООП.

Даже грубо говоря не верно. Компонентное программирование не разделилось ни на какие ветки. Каждый тип компонентов (см. выше) используется для своих целей. И все это в рамках одного проекта.

Сейчас Вы, похоже, говорите о шаблоне Session Facade. Суть его в том, что компненты сущности (entity) не передаются наружу напрямую. Для изменения свойств компонента-сущности используется метод объекта-действия (session, отсюда и название), который несет информацию о контексте в котором это изменение происходит. А в качестве параметра гоняют объект-значение (value object). Кроме того Session Facade создает дополнительный уровень изоляции.
Этот замечательный шаблон одинаково подходит для использования как для сессий с состоянием так без состояния!!!!!!! Более того, это один из самых распространенных шаблонов и его использование считает хорошим тоном.

Это не верно, например, можно дергать компоненты-сущности. Они какими были такими и остались (в пределах транзакции, естественно).

Хто такой сервер и хто такой клиент в терминах MVC? А серьезно смотри выше.

 

"Компонентное программирование суть объектно-ориентированное"
это было давно, но это правда . прогаммировал СОМ-компоненты (они даже работали) на Си и на Паскаль, ООП парадигму использовал, а само ООП нет. знаете почему? да потому что ООП нет ни в Си, ни в Паскале. вот так.

"Компонентное программирование не разделилось ни на какие ветки. Каждый тип компонентов (см. выше) используется для своих целей."
да хоть как назовите, но когда программисты садятся писАть код им важно занть - это stateless объект или statefull. вот и все.

"Сейчас Вы, похоже, говорите о шаблоне Session Facade"
у Вас что там, в голове мешанина чтоль, иль Вы издеваетесь над программистами? (и не надо столь много восклицательных знаков ставить, как будто Вы откровение какое-то высказали).
зачем мне фасад. есть один объект на сервере и одини на клиенте. ОДИН там и ОДИН сям, какой такой фасад-масад? из-за того, что я не могу вызывать последовательно методы серверного объекта в случае stateless мне нужен ЛИШНИЙ объект посредник, который аккумулирует в себе вызовы, а потом скопом отправляет на сервер.

"Хто такой сервер и хто такой клиент в терминах MVC"
ой, да просто описка, Вы и кэ тому придрались. лучше бы ответили на термино-логические несоответсвия в Ваших предыдущих сообщениях. а я хотел написать реализация клиента и сервера, в зависимости от расположения контроллера и модели (сервер или клиент) и в зависимости от типа объектов (stateless или statefull) будет иметь разный исходный код.

ПС. так и быть, я приведу пример. есть ИС безопасности, метрики которой основаны на проверке нескольких критериев, пусть их будет N. в случае несрабатывания одного из критериев система возвращается в первоначальное состояние. метрика может основываться на зависимости одного критерия от другого.
так вот в случае stateless мы должны сначала определить все критерии (N штук) и потом скопом передать на сервер. в случае statefull мы можем передавать на сервер данные по очереди.

ППС. "и его использование считает хорошим тоном"
уж поверьте мне, хорошим тоном считается использование того, что позволит снизить сопровождение и модернизацию или, говоря современным языком, ТСО - совокупную стоимость владения, так что если надо будет, то я наплюю на все теории.

 

Шаблоны проектирования - это практика проверенная жизнью. Тоже современная тенденция.

Нет у меня желания и цели к Вам придираться. Я не преподаватель на экзамене, а Вы, надеюсь, не студент. Не понятно было - вот и все.

Вас "заклинило" на слове stateless. Я пытаюсь донести до Вас, что

компонентов различаются по функциональности, а не по поддержке состоянию.
ДА НЕ ДЕЛЯТЬСЯ КОМПОНЕНТЫ НА STATELESS и STATEFUL. Программистам нужно знать КАК ПРИКЛАДНОМУ ОБЪЕКТУ поставить в соответствие КОМПОНЕНТ.

Не в обиду, но похоже, что либо Вы не владеете предметной областью, либо ваш инструментарий не допускает такого моделирования.
Я предлагаю разобраться, прежде всего, в типах компонентов. Скажите, какие типы компонентов вы используете для моделирования прикладных объектов?

 

"Шаблоны проектирования - это практика проверенная жизнью. Тоже современная тенденция."
я, если честно, ожидал что Вы что-то подобное ответите.
знаю я кое-что про шаблоны проектирования, но практика - это всего лишь практика. это не закон в физическом смысле (напрмиер закон Ньютона), это не закон силы вещей (для того, чтобы сделать нож нужно переплавить руду) и это не закон в государственном смысле (например, постановление Госгортехнадзора), которые нужно обязательно выполнять. так что для одного случая одна практика, для другого другая.


"Не в обиду, но похоже, что либо Вы не владеете предметной областью, либо ваш инструментарий не допускает такого моделирования."
эту фразу я не понял. какой инструментарий и какая предметная область?

"давайте разберем Ваш пример" (С) в случае когда SecuritySystem реализована как stateless

SecuritySystem securitySystem = SecuritySystemLocator.getInstance();
System.out.println(securitySystem.getState());

ServerPolicy policy = new ServerPolicy("policy 1");
securitySystem.verify(policy);

System.out.println(securitySystem.getState()); // эта строка не имеет смысла - securitySystem уже забыла про policy1.
// правильный вызов такой: securitySystem.getState(policy1, ... , policyN).
в случае stateless система не может получать критерии последовательно.
кстати, а где у Вас в примере SecurityManager?
и вообще, для конечного автомата лучше подходит шаблон State - все таки "это практика проверенная жизнью".

ПС. "В этом примере, на самом деле, затрагивается очень важный момент - транзакции."
это вы к чему сказали?
если система безопасности проверяет глаза, пальцы и т.д. и принимает решение на основании произведения вероятностей "хорошести" каждого параметра, сравнивая его (произведение) с порогом Р, то если на каком-то этапе мы получили вероятность меньшую Р, то дальше проверять нет смысла - вот и получается, вроде как вместе, а вроде как и по-отдельности.

 

Ну вот. Сначало прозвучало, что

а теперь вероятности "хорошести" перемножаются как для независимых событий.

В такой постановке состояние системы может поменяться "под действием" одного критерия. Проверка каждого критерия есть транзакция, которая (грубо) гарантировано переведет систему из одного состояния в другое. Если между критериями есть зависимость, то границы транзакции могут выйти за пределы метода проверки одного критерия. В этом случае, наверное, лучше отдавать на проверку метрику целиком.

Там же где и Policy Я извиняюсь за не аккуратность - форма не самый лучший редактор кода и я сильно торопился. Когда поместил ответ то увидел эти ошибки, но все равно не знал как их исправить.

все бы так если б не policy.getSomethingAboutThisPolicy() который возможно успел поведать о себе какому-то более надежному компоненту чем компонент-действие без поддержки состояния .

Код на клиентской стороне зависит только от класса Policy и интрефейса SecurityManager. Больше не от чего! Соответсвие реальному миру не находите?

 

"а теперь вероятности "хорошести" перемножаются как для независимых событий. "
согласен, тут я Вас обманул.

"все бы так если б не policy.getSomethingAboutThisPolicy() который возможно успел поведать о себе какому-то более надежному компоненту"
это я не понял. возможно из-за слов "Something" и "какому-то". поконкретнее бы.

по-моему, я понимаю, что Вы хотите сказать, но для этого хотелось бы увидеть исправленный пример. и тогда я, может быть, смогу проккоментировать Вашу фразу: "Код на клиентской стороне зависит только от класса Policy и интрефейса SecurityManager. Больше не от чего!"

 

Исправленный пример (для случая когда критерии зависимые):

/**
* Security System's facade.
*
*/
public interface SecurityManager extends EJBObject {
/**
* Returns current state of this system.
*
* @return integer value identified the state of this system.
* @throw RemoteException Communication fails.
*/
public int getState() throws RemoteException;

/**
* Verifies specified policy and triggers this system to the appropriate state.
*
* Each policy is part of the security metrics, if verification of specified policy
* fails the entire metrics fails and the system is rolled back to it's previous state.
*
* @param policy policy being verified.
* @throw RemoteException Communication fails.
*/
public void verify(Policy policy) throws RemoteException;
}

/**
* Security policy.
*/
public class Policy implements Serializable {

/**
* Creates new instance of the Policy.
*
* @param name the name of the Policy being instantiated.
*/
public Policy(String name) {
....
}

/**
* Represents characteristics identified this policy.
* These characteristics can be used to negotiate session establishment.
*
* @return characteristics
*/
public Object getSomethingAboutThisPolicy() {
return ...
}

}

Примерный код на клиентской стороне:

SecurityManager securityManager = SecurityManagerLocator.getInstance(managerName);
System.out.println(securityManager.getState());

securityManager.verify(new Policy("eye"));
System.out.println(securityManager.getState());

securityManager.verify(new Policy("pin"));
System.out.println(securityManager.getState());

Кажется ничего не забыл.
Код на клиентской стороне зависит только от прикладных объектов Policy и SecurityManager.

По поводу something, к сожелению, совсем конкретно только в конкретном случае. А по "какому-то" - по спецификациям J2EE, когда экземпляр компонента без состояния переключается между клиентами (а это происходить каждый вызов его метода), происходит изменение контекста SessionContext для того, что бы отразить контекст компонента и клиента, вызвавшего метод. Экземляр компонента включается в контекст транзакции клиентского запроса и может получить доступ к информации в SessionContext специфичной для данного клиентского запроса.

P.S. Этот пример служит только демонстрационным целям. В жизни в этом нет никакой необходимости.

 

минуточку,
"-то более надежному компоненту чем компонент-действие без поддержки состояния".
"Экземляр компонента включается в контекст транзакции клиентского запроса и может получить доступ к информации в SessionContext"
т.е. на сервере существует либо объект statefull, либо какой-то другой сервис, который хранит данные между вызовами методов серверного объекта с одного и того же клиента, так?

 

У системы безопасности есть состояние и его кто-то должен хранить.

Но клиенту, о том, каким способ храниться состояние знать противопоказано. Ему нужен только интрефейс взаимодействия с системой безопасности и определение критериев безопасности. В этом случае код на клиентской стороне не будет зависеть от реализации интрефейса системы безопасности.

 

значит получается:
сервер полностью statefull - код одинаков на сервере и на клиенте, то есть размщаем мы объект на сервере или на клиенте - мы ничегго не переписываем.
сервер stateless, но есть "какой-то" - в случае переноса объекта на сервер мы его код должны чуть-чуть подправить.
сервер полностью stateless. при переносе объекта на сервер мы должны править и клиента и сервер.
так?

 

Я ничего не понял. Можно по подробней.