• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Taming Brownfield Codebases with AOP
 

Taming Brownfield Codebases with AOP

on

  • 209 views

 

Statistics

Views

Total Views
209
Views on SlideShare
209
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Lots of brownfield codebases are a messed mix of procedural, OO and functional programming styles. It’s not uncommon to see an OO language used to write an application in purely procedural code. The result is that the code is tightly coupled through out. Add to this a lack of file, code and namespace organization and you’ll quickly feel like you’re running around in circles when you’re trying to navigate through the code.Once you do get a feeling for the code you’ll notice that there are glaring consistency issues. One API might have logging enabled on it while another doesn’t. When logging is implemented the messages entered into the log may differ method to method. Different techniques for transaction management may be used in different locations. In short, every time you step into a section of code it’s a learning experience.All of these things culminate in one undeniable fact; any change you make to the codebase is a dangerous change. No matter how trivial the change you make there will always be some unintended side effect that cascades through the application breaking something. You can’t easily protect yourself from this either. The previous developers didn’t create a full suite of unit/integration tests for you to rely on, and those that they did create don’t really test anything of significance. To add tests that protect you from breaking changes you need to change the code to make it more testable; a classic chicken and egg issue.
  • Consistency - how features are implemented - where features are implementedEvery new feature, or gain in consistency, can’t require a rewrite.Have to understand the risk in each change and be able to back out the change if the risk assessment was wrong
  • Granularity – each aspect can be attached where appropriate; class, method, event, etc.Reversibility – AOP can be backed out and individual aspects can be backed out
  • Existing frameworksMVC inherit from HandleError and apply via ConfigWCF add transaction mgmt to every callNhibernate add auditing to every CUD action
  • - Implementation isolationapplication, class, method/property/event level attachment gives optionsAdditive changes are the least risky. Modification

Taming Brownfield Codebases with AOP Taming Brownfield Codebases with AOP Presentation Transcript

  • Taming Brownfield Codebases with AOP
  • The typical Brownfield codebase • Spaghetti code • Tightly coupled • Lack of organization • Inconsistent • Dangerous to change
  • Brownfield reclamation • Introduce consistency • Require minimal effort • Introduce limited risk
  • How AOP can help • Introduce consistency • Aspects are isolated and centralized features • Require minimal effort • Make use of pre-existing aspects • Introduce limited risk • Granularity choices • AOP is reversible
  • AOP choices • Interceptors • Depends on Inversion of Control Containers • Requires Dependency Inversion/Injection patterns in the code • Existing frameworks • Many have injection points • Isolated functionality added at these points is AOP • IL Weaving • Modifies the code post compilation • Limited codebase changes
  • IL Weaving • Each aspect is an implementation • Granular attachment options • Changes are usually additive
  • Implementation [NotifyPropertyChanged] public class Person { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get { return this.FirstName + " " + this.LastName; } } }
  • Implied Functionality public class Person : INotifyPropertyChanged { private string firstName; private string lastName; public event PropertyChangedEventHandler PropertyChanged; protected virtual void OnPropertyChanged(string propertyName) { if ( this.PropertyChanged != null ) { this.PropertyChanged( this, new PropertyChangedEventArgs(propertyName) ); } } public string FirstName { get { return this.firstName; } set { if ( this.firstName != value ) { this.firstName = value; this.OnPropertyChanged("FirstName"); this.OnPropertyChanged("FullName"); } } } public string LastName { get { return this.lastName; } set { if ( this.lastName != value ) { this.lastName = value; this.OnPropertyChanged("LastName"); this.OnPropertyChanged("FullName"); } } } public string FullName { get { return this.FirstName + " " + this.LastName; } }
  • Implementation public class OrderFulfillmentService { [HandleException] public void Fulfill( Order order ) { // Do stuff. } }
  • Implied Functionality public class OrderFulfillmentService { public void Fulfill( Order order ) { try { // Do stuff. } catch ( Exception e ) { if ( ExceptionHandler.Handle(e) ) throw; } } }
  • Implementation [assembly: Log(AttributeTargetTypes="Contoso.Crm.Orders.*", AttributeTargetMemberAttributes = MulticastAttributes.Public)] public class OrderFulfillmentService { public bool IsValid( Order order ) { if ( order.Lines.Count == 0 ) return false; if ( order.Amount < 0 ) return false; return true; } }
  • Existing implementations • Toolkits exist for many common needs • Logging • INotifyPropertyChanged • Exception handling • Some will be difficult to use in brownfield scenarios
  • Moving forward with AOP and Brownfield • IL weaving is the • Easiest technique to add non-functional requirements • Lowest impact to existing code • Easiest to back out • Make use of existing aspects • Don’t forget to leverage frameworks already used
  • Donald Belcham @dbelcham donald.belcham@igloocoder.com