Design Patterns – How to Implement Graceful Fallback on Old Platforms

If you're measuring methods then this is a classic example of cross-cutting concerns that AOP is designed to solve.

My Java is weak, but something like this in C# using PostSharp would work...

Create a ProfileAttribute class that does the profiling and logs it to some log file/database/whatever

public sealed class ProfileAttribute : Attribute
{
    private StopWatch stopWatch;

    public override OnEntry(MethodExecutionArgs args)
    {
        this.stopWatch = new StopWatch();
        this.stopWatch.Start();
    }

    public override OnExit(MethodExecutionArgs args)
    {
        this.stopWatch.Stop();
        /* 
        log(string.Format("[{0}]{1}.{2} took {3}ms", 
            DateTime.Now, 
            args.ClassName, // may not be actual member name, I forget
            args.MethodName, // may not be actual member name, I forget
            stopWatch.Elapsed.TotalMilliseconds));
        */
    }
}

Then, you can attribute any method that you want to profile (without having to clutter up the code too much) just by applying the attribute like so:

[Profile]
public void WatchedMethod()
{
    /* Code */
}

Afterwards, you can check your log(s) and should see something like:

[Jan 1, 2012 00:00:01]MyClass.WatchedMethod took 1.001ms

[Jan 1, 2012 00:00:02]MyClass.WatchedMethod took 1.000ms

[Jan 1, 2012 00:00:03]MyClass.WatchedMethod took 1.002ms

edits

At which point... it makes sense to write a small utility that can pull the data from logs, filter it, and present it in such a way that is usable to you (average the running times, show outlier times, etc.)

Also note that using certain AOP frameworks (maybe AspectJ... not sure) you can also decide what build(s) certain aspects can be built into... ie. you can weave this profile attribute into the debug build, but not weave it into the release build.

Note about runtime performance:

If your weaver is a compile-time weaver, it will inject the aspect's code into your code during the build. Using PostSharp with the example given, the resulting code will be:

private StopWatch stopWatch;

public void WatchedMethod()
{
    this.stopWatch = new StopWatch();
    this.stopWatch.Start();

    /* Code */

    this.stopWatch.Stop();
    /* 
    log(string.Format("[{0}]{1}.{2} took {3}ms", 
        DateTime.Now, 
        args.ClassName, // may not be actual member name, I forget
        args.MethodName, // may not be actual member name, I forget
        stopWatch.Elapsed.TotalMilliseconds));
    */
}

My thoughts:

A "Bar", as represented in your domain, has all of the things that may be needed in either place: name, address, URL, logo, slogan, and "distance" (I'm guessing from the requester's location). Therefore, in your domain, there should be one "Bar" class that is the authoritative source of data for one bar, no matter where the data will be used later. This class should be mutable, so that changes to the bar's data can be made and saved when necessary.

However, you have two places in which this Bar object's data is needed, and both of them only need a subset (and you don't want that data to be changed). The usual answer is a "data transfer object" or DTO; a POJO (plain ol' Java object) containing the immutable property getters. These DTOs can be produced by calling a method on the main Bar domain object: "toScenario1DTO()" and "toScenario2DTO()"; the results being a hydrated DTO (meaning that you only need to use the long, complicated constructor in one place).

If you ever needed to send data back to the main domain class (to update it; what's the point of data if you can't change it as needed to reflect the current state of the real world?), you could construct one of the DTOs, or use a new mutable DTO, and hand it back to the Bar class using an "updateFromDto()" method.

EDIT: to provide an example:

public class Bar {
     private String name;
     private Address address; 
     private Distance distance;
     private Url url;
     private Image logo;
     private string Slogan;

     public OnlineBarDto ToOnlineDto()
     {
         return new OnlineBarDto(name, address, url, logo);
     }

     public PhysicalBarDto ToPhysicalDto()
     {
         return new PhysicalBarDto(name, address, distance, slogan);
     }

     public void UpdateFromDto(PhysicalBarDto dto)
     {
         //validation logic here, or mixed into assignments

         name = dto.Name;
         address = dto.Address;
         distance = dto.Distance;
         slogan = dto.Slogan;
     }

     public void UpdateFromDto(OnlineBarDto dto)
     {
         //Validate DTO fields before performing assignments

         name = dto.Name;
         address = dto.Address;
         url= dto.Url;
         logo = dto.Logo;
     }

     // getters/setters - As necessary within the model and data access layers;
     // other classes can update the model using DTOs, forcing validation.
}

public class PhysicalBarDto
{
     public final String Name;
     public final Address Address;
     public final Distance Distance;
     public final String Slogan;

     public PhysicalBarDto(string Name, Address address, Distance distance, string slogan) 
     { //set instance fields using parameter fields; you know the drill }
}

public class OnlineBarDto
{
     public final String Name;
     public final Address Address;
     public final Image Logo;
     public final Url Url;

     public OnlineBarDto(string Name, Address address, Url url, Image logo) 
     { //ditto }
}

The Address, Distance and Url classes should either be immutable themselves, or when used in the DTOs they should be replaced with immutable counterparts.