none
Whats the best practise for desinging Utility library? RRS feed

  • Question

  • I am designing utility library to pass log information & results such as results of every method execution time (this is one purpose out of all). At present, I have built my library and with a static class so that when developer wants to pass the log, it would call this static class method and pass information. I have seen many like this built in .Net libraries

    Inside this library, I have a static class and inside this class I have one private static variable and few static methods. One method (Named 'SetUp') is to create an instance of this static variable & other methods use this variable. To avoid concurrency, some suggests to have that class designed as normal class so that each time developer create an instance use that instance instead of using same instance across the application. Moreover, having this kind of implementation means no more additional methods to do set up an instance.

    However, some developers would like to have this library built in dependency injection design pattern and register this as a singleton dependency so developers would call this in their constructor and assign to a private variable in their class to use.

    My questions are as follows.

    1. Will there be memory problem as static would be written in heap and if I use singleton, i have one reference in the heap and multiple variables in stack link with one heap slot?
    2. Technically decoupling this would allow the developers to have their own development separate from its users. Is it more beneficial rather than the fact that developer are asked to develop in this pattern?
    3. If I'm not wrong, singleton's life time as long as application is alive. Will it be same for static class and variables inside the static class?
    4. What is best way to implement utility library?

    Your opinion is highly appreciated. 

    Thanks in advance



    • Edited by Gayan19911212 Thursday, March 26, 2020 8:08 AM Correction
    Thursday, March 26, 2020 3:08 AM

All replies

  • You may have a static object an object that doesn't need to be instance. A static library, I have not heard of that.  Now of days, the  de facto is to use dependency injection in OOP.  But for an static object, you might as well apply the 'new' is glue principle, IMO.

    https://ardalis.com/new-is-glue

    https://deviq.com/dependency-inversion-principle/

    Now if the other developers were using DI and IoC with using  the objects in the utility library, that would be the ideal situation. You should go with what the other developers are requesting and not come to the conlusion it's your way or hit the highway. That doesn't make for a good architect.


    • Edited by DA924x Thursday, March 26, 2020 6:04 AM
    Thursday, March 26, 2020 6:02 AM
  • @DA924x, Thanks for replying back. 

    Yes, you are right if other developers requests, it is the way to go but the thing is, now we have another teams comes on board they propose that way we propose this way. so I need to check pros and cons of each way.

    BTW I have edited the question as I wanted to class not the library.

    Forgive me, could you elaborate more on "Now of days, the  de facto is to use dependency injection in OOP.  But for an static object, you might as well apply the 'new' is glue principle, IMO."?

    My static class as follows

    public static class Log
    {
        private static LogEvent objX;
    
        public static void SetUp()
        {
            objX = new LogEvent();
        }
    
        public static void LogMe(string message)
        {
            objX.LogMe(message);
        }
    }


    • Edited by Gayan19911212 Thursday, March 26, 2020 8:27 AM added code
    Thursday, March 26, 2020 8:23 AM
  • Hello,

    Before designing a library checkout what's already out there.

    https://stackoverflow.com/questions/1260157/whats-the-most-widely-used-logging-framework-in-c

    Rather than building your own unless they don't fulfill your needs.

    I don't think this is the way to go.

    public class Singleton<T> where T : class, new()
    {
        private Singleton() { }
    
        private static readonly Lazy<T> _instance = new Lazy<T>(() => new T());
    
        public static T Instance => _instance.Value;
    }


    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Thursday, March 26, 2020 10:33 AM
    Moderator
  • Forgive me, could you elaborate more on "Now of days, the  de facto is to use dependency injection in OOP.  But for an static object, you might as well apply the 'new' is glue principle, IMO."?

    Yes, now of days, developers are being taught how to write loosely coupled clean code by using DI and an IoC.  Whether or not one is  using a Core or non Core solution or whether or not one is using an ASP.NET or Windows desktop solution,  one can still apply the principles of writing clean code.

    https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/may/asp-net-writing-clean-code-in-asp-net-core-with-dependency-injection

    <copied>

    When looking at code to evaluate its coupling, remember the phrase “new is glue.” That is, anywhere you see the “new” keyword instantiating a class, realize you’re gluing your implementation to that specific implementation code. The Dependency Inversion Principle (bit.ly/DI-Principle) states: “Abstractions should not depend on details; details should depend on abstractions.

    In addition to the new keyword, “static cling” is another source of tight coupling that makes applications more difficult to test and maintain.

    <end>

    To me that static class/object is 'static cling'. 

    https://www.weeklydevtips.com/episodes/005

    <copied>

    The goal of the phrase 'new is glue' is to stick in developers' heads so that when they are writing or reviewing code that directly instantiates an object, they understand that this is tightly coupling their code to that particular object implementation.

    <end>

    So I don't see why that wouldn't apply to a 'static cling' object and tightly coupling developer's code to the static object's implementation.

    So one hand, you give those developers that want to use a static object and let them do so, but on the other hand, you give the developer that wants to write clean code the ability to DI the object.  

    You should be able to do that since a classlib project can accommodate both types of objects.




    • Edited by DA924x Thursday, March 26, 2020 12:26 PM
    Thursday, March 26, 2020 11:50 AM
  • @Kareninstructor Thanks for the reply.

    My main task is to build a wrapper so that developer would not need to worry about logging part. As for the logging framework, Thanks for copying that link I'm aware of some.

    May I know what you mean by "I don't think this is the way to go."? 

    At present, decoupling way is the popular method but people still more utility classes are built in static.

    Friday, March 27, 2020 8:12 AM
  • @Kareninstructor Thanks for the reply.

    My main task is to build a wrapper so that developer would not need to worry about logging part. As for the logging framework, Thanks for copying that link I'm aware of some.

    May I know what you mean by "I don't think this is the way to go."? 

    At present, decoupling way is the popular method but people still more utility classes are built in static.

    I should had expanded on this, when using a generic singleton there are no guarantees there will only be one instance of T. Example, I have a class named ResultItem with a property LineNumber. In one method of another class I use it incorrectly (everyone makes mistakes).

    var resultSingleton = Singleton<ResultItem>.Instance;
    resultSingleton.LineNumber = 12;

    Then someplace else

    Singleton<ResultItem>.Instance.LineNumber = 10;
    The first has no link to the second. Of course if used properly a generic method can work.  Secondly there is usually a reason for having this in the first place, within the singleton have you thought about what will go into to it? To handle different logic? Example, the following singleton focuses only on one topic rather than multiples.


    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Friday, March 27, 2020 10:58 AM
    Moderator