• (disco) in reply to s73v3r

    There's value in knowing that in a particular circumstance you're assured of a new GUID.

  • (disco) in reply to Anonymous
    Anonymous:
    I agree that the XML Documentation Comments (simply referred as "comments" in the article) are useless, but not really a WTF since it is how the XML Documentation Comments should be used for. Just like most Javadoc comments.

    I remember a project at uni (some kind of multi-threaded multi-agent simulator in Java - simple stuff, a grid, and a few types of animals with interactions between them - lions eat gazelles, snakes bite lions, birds eat snakes, etc.) with an explicit requirement that every class and method should be properly JavaDoced.

    After a hundred of comments like this:

    /** Sets the life counter
 * @param value - new value
 */
public void setLifeCounter (int value) {
  this.LifeCounter = value
}

    I started to slowly give up. But that wasn't even the worst - how do you sensibly describe a Snake class? Or Bird class? In the end, I copied the definitions from Wikipedia and turned my JavaDoc into a somewhat snarky book on animals.

    Code-docs are awesome, unless it's you who's writing them. Then they're pure evil.

  • (disco) in reply to FrostCat
    FrostCat:
    I would swear that back in the day Java applets in a web page were scriptable.

    They were, if you used the right options when loading the applet. But who writes new pages with them these days?

  • hypersw (unregistered)

    It might so happen that Jonathon soon learns new words, like unit testing, auto mocks, all that peculiar enterprise things which might need interfaces instead of plain random stuff. The comments are lol, but no harm.

  • (disco) in reply to FrostCat

    I used to work with a piece of software that would accept unicode but not display it after saving. The compiller errors also didn't bother telling you what was wrong.

  • Object not found (unregistered)
    chubertdev:
    AwesomeRick:
    I don't understand the submitter's problem with the namespace "Business.Common". Seeing the full namespace Business.Common.Services, my first thought would be a library supplying business logic, available in both client and server code, and that the classes in here are services. Where's the WTF?
    It generally leads to the anti-pattern of just throwing everything business-related into Business.Common and creating a God object.
    You mean a Guid object.

    If you're confused, let me explain the difference. God object: They're all the same one. Guid object: It's unique.

    Got it?

  • (disco) in reply to tom103
    tom103:
    They're not just comments, they're _documentation_ comments, which is completely different. It's not uncommon for documentation comments to state the obvious (although in this case the author could probably have put a little more effort in them).

    That does not make it any more useful. If there is nothing useful to be added to the name, just leave it at that and set the documentation generator to extract all non-private symbols.

  • (disco) in reply to nmclean

    I did indeed mean "a different means of calculating the byte pattern" that is stored in a "normal" .NET Guid type, as other have pointed out.

    Type "1" Guids (though possibly illegal) have some significant advantages. Fixed Value (repeatable) Guids have use for elements such as testing (previously mentioned by others)

  • (disco) in reply to nzifnab
    nzifnab:
    Since when can Java be called from JavaScript?

    Since Java 7 (with Rhino) and Java 8 with Nashorn. In JavaFX you can do some crazy shit between an HTMLView running JS code and Java code running in the JavaFX side and JavaScript code running on Nashorn handling stuff from the JavaScript in the HTMLView.

  • (disco)

    What a bizarre article. Usually a namespace will be split by functionality or domain areas or whatever. But inevitably some service classes will have quite general functionality, so you want a place to put them. Why not call that "Common"?

    And... has Remy never heard of mocking?

  • (disco) in reply to Ben
    Ben:
    And... has Remy never heard of mocking?

    Are you mocking Remy?

  • (disco) in reply to VinDuv
    VinDuv:
    Are you mocking Remy?

    i forget s that required or forbidden?

  • (disco) in reply to accalia
    accalia:
    i forget s that required or forbidden?

    Yes.

  • (disco) in reply to error

    which one?

  • (disco) in reply to accalia
    accalia:
    which one?

    Whichever is less convenient at the time, probably.

  • (disco) in reply to FrostCat
    FrostCat:
    Whichever is less convenient at the time, probably.

    -sigh- i was afraid of that...

  • (disco) in reply to Ben

    If you are doing things like this your class design is wrong.

    This is so core to .net, are they going to be passing around IString next?

  • (disco) in reply to s73v3r

    You should be building separate binaries or jars for your client app and server. Everything in Common needs to be included in both binaries, whereas a class in Server shouldn't be included in the Client binary (or jar if you're doing a Java client-server.) I realize many debs these days focus on web apps where the client is a browser, but think of the rest of the ecosystem: iOS apps, Windows programs, *nux programs. Something like Skype, or Minecraft, or any number of other programs, all have both a client and a server component. Should code that needs to be in both places (eg: URL parsing) be copy-pasted into both code bases? Wouldn't it make more sense to configure your build server to include the code from Common when building each code base?

  • (disco) in reply to AwesomeRick

    I'm not saying there isn't any value in sharing code between client and server. I'm saying there's very little, if any value in creating a special namespace/package for it just to say it's shared. There are infinitely better package names to put those classes in. Things that actually describe what the code in that package is doing, rather than where it's used.

  • (disco)

    Isn't the real WTF here the insistence of the use of OO where you need to create an interface do depend on, a concrete implementation, then remember to wire these up in your IoC container.

    Alternatively, taking a function approach, you'd just pass in a function that returns a GUID. Then for your normal usage, you'd just pass in Guid.NewGuid.

  • Ikoai Bachiro (unregistered)

    Enterprise is more about doing things in the most indirect and bloated way possible so you can spend more time being paid to do less (look at all the Java boilerplate), while justifying the complexity with buzzwords like "robust", "extensible", "maintainable", etc.

  • (disco) in reply to Daniel_Bradley
    Daniel_Bradley:
    Isn't the real WTF here the insistence of the use of OO where you need to create an interface do depend on, a concrete implementation, then remember to wire these up in your IoC container.

    It doesn't make much sense for a single-operation interface. It makes a lot more sense once you need multiple operations to satisfy the interface protocol. Which is most of the time but not here…

  • (disco) in reply to lucas

    It's not totally ridiculous. Sometimes you might want to use a GUID that's generated in a different way than the default .NET implementation (which is essentially a giant random number).

    Real world example: It's not uncommon to use GUIDs as part of a clustered index on a database table -- not necessarily the best idea, but it happens quite a bit, and it has some legitimate advantages when used with ORMs, replication, and some other scenarios.

    If you use standard (random) GUIDs, you'll experience severe fragmentation, and insert performance will be absolutely terrible. So, people came up with something called a COMB, which is basically a GUID that's part random number, part timestamp, so that sequentially generated GUIDs will be in an increasing sort order. This helps tremendously with database performance.

    The kicker is, the "sort order" of a GUID varies from database system to database system: MS-SQL sorts them by the last six bytes for some reason; MySQL, Oracle, and Postgres variously sort them as strings vs. sequences of bytes, whereas .NET often treats them internally as a combination of numeric values, which can introduce endianness issues depending on the system where they're generated.

    Is this particular case overkill? Possibly; maybe even "probably" since they're clearly not using any special implementation. But there are some legitimate scenarios where it makes sense to abstract your GUID creation.

  • (disco) in reply to Jeremy_Todd
    Jeremy_Todd:
    It's not totally ridiculous. Sometimes you might want to use a GUID that's generated in a different way than the default .NET implementation (which is essentially a giant random number).

    But you probably only need it in one part of your application. The aforementioned implementation would probably be used in multiple parts of your application; changing it would be risky.

    If you need a custom GUID for database indices, write a DatabaseGuidService class and don’t put it in a namespace with Common in its name.

  • (disco) in reply to VinDuv

    Well, true, but I'm feeling charitable today so I'd say that maybe this is just a default implementation, and there might be another specialized implementation of that interface in their data access assembly that gets preferentially injected when it's needed.

    Okay, yeah, probably not.

  • (disco) in reply to Jeremy_Todd
    Jeremy_Todd:
    Real world example: It's not uncommon to use GUIDs as part of a clustered index on a database table -- not necessarily the best idea, but it happens quite a bit, and it has some legitimate advantages when used with ORMs, replication, and some other scenarios.

    If you use standard (random) GUIDs, you'll experience severe fragmentation, and insert performance will be absolutely terrible.

    What kind of insert load do you have where you need to both cluster on the PK and worry about it being always ascending? In any sane scenario where you aren't doubling the size of the table every week (which would become unsustainable very quickly on any hardware), you just make sure to leave some free space at the leaf level of the clustered index and you don't get fragmentation. It doesn't take more than a few percent to almost completely eliminate it if your clustered index is well distributed - which, coincidentally, GUIDs are.
  • (disco)

    This page is getting ridiculous.

    This is totally fine to do. With effectively four lines of code you gain full control over the Guid implementation, full unit test support and standardized methods of object creation (I'd much rather see this then 7 different ways of object creation in code).

    You would have never needed to look into this interface as it was passed to you. You only did so to try to feel superiority about bitching over something utterly insignificant. There used to be real WTFs on this site...

  • (disco) in reply to Pew_Gamesalot
    Pew_Gamesalot:
    This is totally fine to do. With effectively four lines of code you gain full control over the Guid implementation, full unit test support and standardized methods of object creation (I'd much rather see this then 7 different ways of object creation in code).

    The use of classes/interfaces to encapsulate a single function is a major smell that points the WTF straight at the addled language designers that produced Java, and later on, early versions of C#. In a language with first-class functions, those four lines of code would no longer be needed at all!

    To C#'s credit though: the guys at DevDiv figured out their mistakes faster than the Java team ever did.

  • (disco) in reply to tarunik
    tarunik:
    The use of classes/interfaces to encapsulate a single function is a major smell that points the WTF straight at the addled language designers that produced Java, and later C#.
    It's not catastrophic though, and you need to beware that you're not discounting standard functions, such as those managing service identity. Function identity has been a bit of a known bear, but it's far more well-defined for services even if those services have effectively only a single operation. Once you support standard profile operations as well (such as an equality test, or introspection) then you've no longer got a single operation.

    Major code smells are more things like having services where everyone tightly binds to a single implementation of the service. That's far dodgier…

  • (disco) in reply to dkf
    dkf:
    It's not catastrophic though, and you need to beware that you're not discounting standard functions, such as those managing service identity. Function identity has been a bit of a known bear, but it's far more well-defined for services even if those services have effectively only a single operation. Once you support standard profile operations as well (such as an equality test, or introspection) then you've no longer got a single operation.

    Here's the rub: the base language function type should handle that by default.

  • (disco) in reply to tarunik
    tarunik:
    In a language with first-class functions, those four lines of code would no longer be needed at all!

    Can you explain why, please? This isn't obvious to me.

  • (disco) in reply to boomzilla
    boomzilla:
    Can you explain why, please? This isn't obvious to me.

    You no longer need a wrapper-anything to inject a function into a dependency when you have first-class functions.

    In Python:

    def thingThatNeedsGUIDs(arg1, arg2, arg3, guidGenerator = uuid.generate):
    # do something that needs GUIDS
    pass

    Using this with non-default guidGenerators is as simple as passing the non-default generator as the extra argument.

  • (disco) in reply to tarunik

    Oh, yeah, OK. That difference seems pretty trivial to me, though. I wouldn't get so worked up about it.

    Though honestly, having a class that you can swap out like that seems likelier to be cleaner for the stuff @Pew_Gamesalot was talking about. Unless you're injecting that first class function at a higher level (i.e., uuid.generate is something that's injected), at which point we're back into the trivial realm.

    I can see why one method might appeal to someone for aesthetics or whatever, but seems like six of one, half dozen of the other to me.

  • (disco) in reply to boomzilla

    I don't see any difference tbh. Whatever you inject into the IGuidService is of no interest for me as implementer of the functionality that uses it. What would make any implementation the "default"? That is the major smell.

    tarunik basically did a big rant on how he doesn't know C# has first class functions and then some. It is a multi paradigm language.

Leave a comment on “Enterprise GUID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article