Последние замечания по реализации
Если вы дочитали до этой точки, то вы – герой! Bravissimo! Kudos!
Чтобы сохранить статью краткой и понятной (и чего смешного?), я не стану вдаваться в скучные рассуждения о деталях реализации получения и переключения методов. В этом нет ничего интересного. Но если вам всё-таки интересно: качайте код и смотрите – он полностью рабочий! Названия классов и методов, могут немного отличаться, т.к. я правил его параллельно, но особых изменений быть не должно.
Внимание! Перед использованием кода в вашем проекте, внимательно прочитайте paenultimus. А если не знаете что значит paenultimus, кликайте по ссылке.
Использование
Перехват методов и свойств
Первое, нам нужна доменная модель. Ничего особенного.
public interface IActor{ string Name { get; set; } void Act();} public class Actor : IActor{ public string Name { get; set; } public void Act() { Console.WriteLine("My name is '{0}'. I am such a good actor!", Name); }}Теперь нам нужно действие
public class TheConcern : IConcern<Actor>{ public Actor This { get; set; } public string Name { set { This.Name = value + ". Hi, " + value + " you've been hacked"; } } public void Act() { This.Act(); Console.WriteLine("You think so...!"); }}При инициализации приложения мы сообщаем реестру о наших точках соединения
// Weave the Name property setterAOP.Registry.Join ( typeof(Actor).GetProperty("Name").GetSetMethod(), typeof(TheConcern).GetProperty("Name").GetSetMethod() ); // Weave the Act methodAOP.Registry.Join ( typeof(Actor).GetMethod("Act"), typeof(TheConcern).GetMethod("Act") );
И, наконец, мы создаем объект в фабрике
var actor1 = (IActor) AOP.Factory.Create<Actor>();actor1.Name = "the Dude";actor1.Act();Обратите внимание, что мы запросили создание класса Actor, но мы можем привести результат к интерфейсу, потому будем приводить к IActor, т.к. класс его реализует.
|
|
|
Если запустить всё это в консольном приложении, получим:
My name is 'the Dude. Hi, the Dude you've been hacked'. I am such a good actor!
You think so...!
Перехват File.ReadAllText(string path)
Здесь две небольшие проблемы:
• Класс File статичный
• и не реализует никакие интерфейсы
Помните о «добро»? Среда не проверяет тип возвращаемый прокси и соответствие интерфейсу.
Значит мы можем создать любой интерфейс. Никто его не реализует ни цель, ни действие. В общем, мы используем интерфейс как контракт.
Давайте создадим интерфейс прикидывающийся статичным классом File.
public interface IFile{ string[] ReadAllLines(string path);}
Наше действие
public class TheConcern{ public static string[] ReadAllLines(string path) { return File.ReadAllLines(path).Select(x => x + " hacked...").ToArray(); }}Регистрация точек соединения
AOP.Registry.Join ( typeof(File).GetMethods().Where(x => x.Name == "ReadAllLines" && x.GetParameters().Count() == 1).First(), typeof(TheConcern).GetMethod("ReadAllLines") );
И, наконец, исполнение программы
var path = Path.Combine(Environment.CurrentDirectory, "Examples", "data.txt");var file = (IFile) AOP.Factory.Create(typeof(File));foreach (string s in file.ReadAllLines(path)) Console.WriteLine(s);В этом примере, обратите внимание, что мы не можем использовать метод Factory.Create, т.к. статические типы не могут использоваться как аргументы.
|
|
|
Основы унифицированного процесса разработки
"Тяжелые" и "легкие" процессы разработки
В этой лекции мы рассмотрим детально два процесса разработки — унифицированный процесс Rational (Rational Unified Process, RUP) и экстремальное программирование (Extreme Programming, XP). Оба они являются примерами итеративных процессов, но построены на основе различных предположений о природе разработки программного обеспечения и, соответственно, достаточно сильно отличаются.
RUP является примером так называемого "тяжелого" процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр. Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять. Многочисленные вспомогательные действия дают надежду сделать возможным успешное решение задач по конструированию и поддержке сложных систем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.
|
|
|
Для достижения этого выполняется иерархическое пошаговое детальное описание предпринимаемых в той или иной ситуации действий, чтобы можно было научить обычного работника действовать аналогичным образом. В ходе проекта создается много промежуточных документов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачи на более простые. Эти же документы служат для проверки правильности решений, принимаемых на каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов, необходимых для получения желаемых результатов.
Экстремальное программирование, наоборот, представляет так называемые "живые" (agile) методы разработки, называемые также "легкими" процессами. Они делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы.
Дата добавления: 2021-03-18; просмотров: 94; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!