Library Organization in .NET
        Posted  
        
            by 
                Greg Ros
            
        on Programmers
        
        See other posts from Programmers
        
            or by Greg Ros
        
        
        
        Published on 2012-10-22T08:44:14Z
        Indexed on 
            2012/10/22
            11:17 UTC
        
        
        Read the original article
        Hit count: 373
        
I've written a .NET bitwise operations library as part of my projects (stuff ranging from get MSB set to some more complicated bitwise transformations) and I mean to release it as free software. I'm a bit confused about a design aspect of the library, though.  
Many of the methods/transformations in the library come with different endianness. A simple example is a getBitAt method that regards index 0 as the least significant bit, or the most significant bit, depending on the version used.  
In practice, I've found that using separate functions for different endianness results in much more comprehensible and reusable code than assuming all operations are little-endian or something.
I'm really stumped regarding how best to package the library.
- Should I have methods that have LE and BE versions take an enum
parameter in their signature, e.g. Endianness.Little, Endianness.Big?
- Should I have different static classes with
identically named methods? such as MSB.GetBitandLSB.GetBit
On a much wider note, is there a standard I could use in cases like this? Some guide? Is my design issue trivial? I have a perfectionist bent, and I sometimes get stuck on tricky design issues like this...
Note: I've sort of realized I'm using endianness somewhat colloquially to refer to the order/place value of digital component parts (be they bits, bytes, or words) in a larger whole, in any setting. I'm not talking about machine-level endianness or serial transmission endianness. Just about place-value semantics in general. So there isn't a context of targeting different machines/transmission techniques or something.
© Programmers or respective owner