Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я читал о нём складывается такое впечатление, что это лишь доработки (ярче было бы сказать "костыли", но опять ведь воспримут не так ) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#).
Справедливо ли такое утверждение?
Или АОП может быть использовано и в простом процедурном программировании и, например, в функциональном программировании.
Интересно было бы узнать ваши мнения.
Здравствуйте, Курилка, Вы писали:
К>Собственно вопрос в сабж.
Буквально в двух словах. К>Я не сильный знаток АОП,
Подписываюсь. К>Или АОП может быть использовано и в простом процедурном программировании и, например, в функциональном программировании.
Подписываюсь.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Курилка, Вы писали:
К>Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я читал о нём складывается такое впечатление, что это лишь доработки (ярче было бы сказать "костыли", но опять ведь воспримут не так ) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#). К>Справедливо ли такое утверждение?
Нет. АОП ортогонально ООП, и вполне может быть реализовано для структурных языков.
К>Или АОП может быть использовано и в простом процедурном программировании и,
Может.
К> например, в функциональном программировании.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
К>>Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я читал о нём складывается такое впечатление, что это лишь доработки (ярче было бы сказать "костыли", но опять ведь воспримут не так ) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#). К>>Справедливо ли такое утверждение?
AVK>Нет. АОП ортогонально ООП, и вполне может быть реализовано для структурных языков.
К>>Или АОП может быть использовано и в простом процедурном программировании и,
AVK>Может.
К>> например, в функциональном программировании.
AVK>А есть смысл?
Вот я и говорю — что смысл в этих "костылях" нашёлся только для ООП, опровергни реальным примером, если можешь.
Object-oriented programming
From Wikipedia, the free encyclopedia.
Object-oriented programming (OOP) is a computer programming paradigm that emphasizes the following aspects:
Objects — packaging data and functionality together into units within a running computer program; objects are the basis of modularity and structure in an object-oriented computer program.
Abstraction — The ability for a program to ignore some aspects of the information that it is manipulating, i.e. the ability to focus on the essential. Each object in the system serves as a model of an abstract "actor" that can perform work, report on and change its state, and "communicate" with other objects in the system, without revealing how these features are implemented. Processes, functions or methods may also be so abstracted, and when they are, a variety of techniques are required to extend an abstraction:
Encapsulation — Also called information hiding: Ensures that objects cannot change the internal state of other objects in unexpected ways; only the object's own internal methods are allowed to access its state. Each type of object exposes an interface to other objects that specifies how other objects may interact with it. This prevents users from breaking the invariants of the program.
Polymorphism — References to and collections of objects may refer to objects of different types, and invoking an operation on a reference will produce behavior depending on the actual type of the referent.
Inheritance — Organizes and facilitates polymorphism and encapsulation by permitting objects to be defined and created that are specialized types of already-existing objects — these can share (and extend) their behavior without having to reimplement that behavior. This is typically done by grouping objects into classes, and defining classes as extensions of existing classes, thus and grouping classes into trees or lattices reflecting behavioral commonality.
It is in fact a set of ideas which mostly existed before. They have been brought together, with associated terminology, to create a programming framework. Together the ideas behind OO are said to be so powerful they create a Paradigm shift in programming.
The exact definitions of these have some variation depending on point of view. In particular, languages with static typing often have slightly different view of OO than languages with dynamic typing, caused by focus on compile-time vs. run-time properties of the programs.
Notes: Abstraction is important to but not unique to OOP. Reusability is a benefit often attributed to OOP.
OOP is often called a paradigm rather than a style or type of programming to emphasize the point that OOP can change the way software is developed, by changing the way that programmers and software engineers think about software.
The Paradigm of OOP is essentially not that of programming, but one of design, a system is designed by defining the objects that will exist in that system, the code which actually does the work is irrelevant to the object, or the people using the object due to encapsulation. The challenge in OOP therefore is of designing a sane object system.
Aspect-oriented programming
From Wikipedia, the free encyclopedia.
In computing, the programming paradigm of aspect-oriented programming (AOP) centers on constructs called aspects, which treat concerns of a separate set of objects, classes, or functions. Although commonly associated with object-oriented programming (OOP), aspect-oriented programming concepts need not confine themselves to the OOP world .
Any program has principled points (join points) where programmers can identify and modify the program semantics. In AOP, programmers use a language-feature called a pointcut to specify join points, and advice (code like methods or functions) to specify the behavior to join at those points. Some variants of AOP also enable programmers to extend the types in the system. Together, these features enable aspects to implement behavior for concerns that crosscut the core concern of the application.
For example, a telecommunications application might have a core concern of routing calls, but code for timing and billing those calls would crosscut the whole object hierarchy. Aspect-oriented programming has the design goal of separating these concerns from the core concerns. It moves code not related to solving the domain problem from the business logic into a separate module. The application code no longer contains pieces of crosscutting concerns scattered across modules; instead, programmers maintain crosscutting concerns in aspects; this makes it easier to maintain both the core and crosscutting concerns.
The steps to successful aspect-oriented programming comprise:
1. The designer defines and separates the concerns, core and crosscutting.
2. The developer writes independent modules to implement them.
3. The AOP system combines the modules (AOP calls this "weaving").
The sequence of steps results in an easy-to-use solution woven from smaller solutions. IDEs and debuggers can display crosscutting concerns in a natural way.
AspectJ, based on Java, developed at Xerox PARC by Chris Maeda of Xerox PARC, who originally coined the term "aspect-oriented programming": no one remembers exactly when. Gregor Kiczales, it is worth noting, coined the term "crosscutting". The Xerox group's what? was later integrated into the Eclipse Foundation's Eclipse Java IDE, has become (or "becoming?") the most widely-known aspect-oriented language.
Aspects emerged out of object-oriented programming and have functionality similar to using meta-object protocol. Aspects relate closely to programming concepts like subjects, mixins, and delegation.
From a mathematical point of view, one could see aspects as a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, aspect-oriented programming enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension -- rather than as a fully-flavoured independent paradigm. Friedrich Steimann, for example, has proposed such a view.
But in fact, AOP proponents promote it as an external package shippable along with some application. The program itself has for example no support for security, but voila! The AOP package can serve as a modular extension to the application serving the needs of the customer.
While at the syntactic level AOP program code appears separate, separation does not apply at run-time level. Without a declaration of dominating aspects, concern-weaving can become unpredictable. In fact, the reality of debugging code poses one of the hardest problems for the AOP community. If the separation of code looms as such a large concern, maybe other ways to achieve this exist, such as C#'s partial types... However, such approaches lack a quantification mechanism enabling programmers to reach several join points of the code with one declarative statement.
Здравствуйте, Курилка, Вы писали:
AVK>>А есть смысл?
К>Вот я и говорю — что смысл в этих "костылях" нашёлся только для ООП, опровергни реальным примером, если можешь.
Приведи реальный пример для ООП и убери классы. Получишь пример для процедурного программирования.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
AVK>>>А есть смысл?
К>>Вот я и говорю — что смысл в этих "костылях" нашёлся только для ООП, опровергни реальным примером, если можешь.
AVK>Приведи реальный пример для ООП и убери классы. Получишь пример для процедурного программирования.
Курилка -> "АОП — доработка ООП?"
К> Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я К> читал о нём складывается такое впечатление, что это лишь доработки К> (ярче было бы сказать "костыли", но опять ведь воспримут не так ) К> ООП-подхода. Т.е. все основные применения и примеры связаны с К> объетами и ООП-языками (Java, C#). К> Справедливо ли такое утверждение? К> Или АОП может быть использовано и в простом процедурном К> программировании и, например, в функциональном программировании. К> Интересно было бы узнать ваши мнения.
Ну дадим определение. Дальше то что?
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, hrg, Вы писали:
hrg>Курилка -> "Re[2]: АОП — доработка ООП?"
hrg>>>Ну дадим определение. Дальше то что?
К>> Определение я не просил вообще-то
hrg>Тогда поясни, плз, цель твоего вопроса.
Ну если ты читать не умеешь, то извиняй
Для тех кто в танке формулируем примитивнее:
Вопрос — как соотностися АОП и ООП — связанные ли это вещи и как связанность/несвязанность соотносится с тем, что подавляющее большинство применений из ООП.
Курилка -> "Re[4]: АОП — доработка ООП?"
hrg>>>>Ну дадим определение. Дальше то что?
К>>> Определение я не просил вообще-то
hrg>>Тогда поясни, плз, цель твоего вопроса.
К> Ну если ты читать не умеешь, то извиняй К> Для тех кто в танке формулируем примитивнее: К> Вопрос — как соотностися АОП и ООП — связанные ли это вещи и как К> связанность/несвязанность соотносится с тем, что подавляющее К> большинство применений из ООП.
— "А правда, можно есть не только ножом и вилкой, а еще используя ложку?"
/ООП & AOP/
— "Правда. Они никак не взаимосвязаны. Неторые еще и палочками едят"
/функциональные/
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
hrg>просто не вижу тему обсуждений.
hrg>- "А правда, можно есть не только ножом и вилкой, а еще используя ложку?" hrg>/ООП & AOP/ hrg>- "Правда. Они никак не взаимосвязаны. Неторые еще и палочками едят" hrg>/функциональные/
hrg>
Ключевой вопрос — а почему АОП и ООП настолько связаны?
На него ты не удосужился даже задуматься, видимо...
Продолжая твои аналогии:
Вот про нож с вилкой я могу это ещё объяснить, но вот про АОП и ООП:
я не вижу что люди нож (АОП) без вилки (ООП) используют.
Не надо мне про сферического коня в вакууме тут рассказывать в оч. раз — реальный пример ты можешь привести?.
Здравствуйте, Курилка, Вы писали:
К>Ключевой вопрос — а почему АОП и ООП настолько связаны?
А они связаны?
К>я не вижу что люди нож (АОП) без вилки (ООП) используют.
А много ли тех, кто просто вилку, без ножа, не использует?
К>Не надо мне про сферического коня в вакууме тут рассказывать в оч. раз — реальный пример ты можешь привести?.
Вот ты пристал с примером. Ну, скажем применяем мы АОП для контроля доступа к методам(функциям). Где здесь привязка к ООП?
Здравствуйте, Курилка, Вы писали:
К>Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я читал о нём складывается такое впечатление, что это лишь доработки (ярче было бы сказать "костыли", но опять ведь воспримут не так ) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#). К>Справедливо ли такое утверждение? К>Или АОП может быть использовано и в простом процедурном программировании и, например, в функциональном программировании.
То, что АОП нередко рассмативают как "расширение" для ООП, объясняется imho тем, что 1) АОП родилось как метод решения некоторых проблем ОО-проектирования, и первоначально разрабатывалось людьми, тесно связанными с Java. 2) эффективно преимущественно при разработке "больших" систем, где традиционно "рулит" ООП.
AR>То, что АОП нередко рассмативают как "расширение" для ООП, объясняется imho тем, что 1) АОП родилось как метод решения некоторых проблем ОО-проектирования, и первоначально разрабатывалось людьми, тесно связанными с Java. 2) эффективно преимущественно при разработке "больших" систем, где традиционно "рулит" ООП.
AR>Тем не менее:
AR>АОП для Common Lisp;
А вот CLOS ты там не увидел чтоли? Как-то плохо похоже что это без ООП
hrg>>просто не вижу тему обсуждений.
hrg>>- "А правда, можно есть не только ножом и вилкой, а еще используя hrg>>ложку?" hrg>>/ООП & AOP/ hrg>>- "Правда. Они никак не взаимосвязаны. Неторые еще и палочками едят" hrg>>/функциональные/
hrg>>
К> Ключевой вопрос — а почему АОП и ООП настолько связаны?
Кто связал? Кто посмел? Просто первоначально он решал проблемы ООП.
К> На него ты не удосужился даже задуматься, видимо...
Думать ботам не положено
К> Продолжая твои К> аналогии: К> Вот про нож с вилкой я могу это ещё объяснить, но вот про АОП К> и ООП: К> я не вижу что люди нож (АОП) без вилки (ООП) используют. К> Не К> надо мне про сферического коня в вакууме тут рассказывать в оч. К> раз - К> реальный пример ты можешь привести?.
сти?.
Хм... какой тебя пример удовлетворит? Как к процедурному програмированию
прикрутить АОП? Пример на конкретном языке?
Здравствуйте, Курилка, Вы писали:
К>Собственно вопрос в сабж. Я не сильный знаток АОП, но по тому, что я читал о нём складывается такое впечатление, что это лишь доработки (ярче было бы сказать "костыли", но опять ведь воспримут не так ) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#). К>Справедливо ли такое утверждение?
Несправидливо. Просто Ява и Шарп стали отличными полигонами для развития новых технологий. Сишники не могут вылезти из битов, а для того чтобы оценить АОП нужно подняться на другой уровень абстракции.
К>Или АОП может быть использовано и в простом процедурном программировании и, например, в функциональном программировании. К>Интересно было бы узнать ваши мнения.
АОП — это возможность не писать код. Любая парадигма (структурное программирование, функциональное, ООП) пораждает структуру программы, а АОП повзоляет как бы выделить из этой структуры аспекты и реализовать их перпендикулярно общей структуре программы. Похожие вещи делаются на многих ФЯ. Это там называется макросами или мета-программированием.
Мета-программировение это несколько более широкая технология чем АОП. Но АОП ею реализовать обычно можно. Поэтому ФЯ обычно не нуждаются в АОП. Но точнее сказать, оно в нем есть, но не называется АОП-ом.
Ну, а структурное программирование просто не доходит до АОП. Оно останавливается на куда более примитивных проблемах.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
) ООП-подхода. Т.е. все основные применения и примеры связаны с объетами и ООП-языками (Java, C#). 
