1

I'm writing a central logging library. In it is an AutoLogAttribute method attribute that automatically logs entry/exit of methods and their parameters (automatically serialized) like this:

[AutoLog]
public void GenerateInvoice(string customerId)
{
    ...
}

// Outputs
// af8291: Entering GenerateInvoice with parameters: { customerId: 'GZilla' }
// af8291: Exited GenerateInvoice. Ellapsed time: 480.12 ms

My problem arises when parameters are POJOs that serialize to huge strings.

By default, I want to just ignore any non-primitives and allow users to specify how they'd like serialization to happen.

Importantly, since most objects are POJOs in my case, I can't start requiring extending an interface like ILoggable. Extending ToString() is also undesirable because ideally an object should be reconstruct-able from it.

I was thinking of allowing users to add custom object-string transformers to a global static list field in AutoLogAttribute (e.g. in some initializer code of their app). I know this is a very bad practice. My question is, is there a better way of solving my problem?

public class AutoLogAttribute
{
    // something like this
    public static Dictionary<Type,Func<object,string>> ParameterTransformers { get; private set; }
    ...
}


public class Program
{
    public static void Main(string[] args)
    {
        AutoLogAttribute.ParameterTransformers[Customer.Type] = (c) => c.Id;
        AutoLogAttribute.ParameterTransformers[Order.Type] = (o) => o.OrderNumber;
        ...
    }

    [AutoLog]
    public void ProcessOrder(Customer customer, Order order)
    {
        ...
    }
}
  • What do you mean by "better?" – Robert Harvey Jul 25 '16 at 22:07
  • @RobertHarvey where I don't have to do anything very ugly, i.e. "bad practices" or "anti-designs", like global static lists – makhdumi Jul 25 '16 at 22:10
  • Do you consider your existing code ugly, bad practice or anti-design? Why or why not? – Robert Harvey Jul 25 '16 at 22:15
  • Yes, because of the use of a global static list. I've edited my question to clarify. – makhdumi Jul 25 '16 at 22:26
1

If you want something to affect the application globally, then you will effectively have to use global/static variables in some form.

Bad practices are not dogmas you should religiously adhere to (see also cargo cult programming). You should understand the reason why they are bad, and consider whether those reasons apply in your situation or how could you mitigate them.

One of the reasons why global state is bad is that it can be modified from any place in a program, making it hard to understand what's happening. I don't think that's a big problem here, since the global state is likely going to be set once and then never modified.

There are other reasons why global state is bad (makes unit testing harder, has issues with multi-threaded programs), you should understand those and weigh whether they are relevant in your case and if they are, how to deal with them.

  • Very cool answer, thank you. You're right, with attributes I need something global and static no matter what. There's no way around that part. – makhdumi Jul 28 '16 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.