• (unregistered)

    <FONT style="BACKGROUND-COLOR: #efefef">Is it really a wtf? To me it just shows the reason we now have asp.net.</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">Legacy asp is fine, but if you use it, then stop talking about pure object-orientation. It isn't gonna happen.</FONT>

  • (cs) in reply to

    ???? It doesn't matter what platform this is done on or what language is used -- this would still be an abuse of OOP. Sometimes abstraction can be taken too far (Jackson Pollack), and there's been a well-supported rumour that a single class can support several methods.

  • (unregistered)

    Do the database access class names really end in "CRUD"? That should tell you something right there.

     

  • (cs) in reply to Stan Rogers

    [quote user="Stan Rogers]there's been a well-supported rumour that a single class can support several methods.
    [/quote]

    You lie! [;)]

  • (cs) in reply to Stan Rogers

    What I meant to says was:

    Stan Rogers:
    there's been a well-supported rumour that a single class can support several methods.

    You Lie! [;)]

     

     

  • (cs)

    I have to admit that, although the code could use a rewrite it doesn't look like a major WTF in itself to me.

    The comments below, though, just blow me away. It uses a seperate class for every method? And all those classes need to be initialized? Sjeez... That's quite some overhead :). I guess it'd be quite more 'elegant' if you just put them all in one 'User' or whatever class and promote some of them to 'Shared' or static methods (shared bool AccountExists(string name), for example). Yes, at this, I say: WTF!

  • (unregistered)

    Whoever wrote this was surely hardcore.

    You know they put in some serious hours at the job for this one...jeez-louise!

    WTF

  • (cs)

    The only thing this guy got right is dividing up the If statements like that. It doesn't look at all pretty, but if you were to put all of them on the same line, VB will perform them ALL even if it encounters one that fails. The programmer still sucks because of the instantiating of a COM object with every call. Ugh.

  • (cs) in reply to

    <font size="4">"Do the database access class names really end in "CRUD"? That should tell you something right there."

    That's a DB Component development in-joke. I've worked on plenty of CRUD systems, and they are often called CRUD, even when they aren't crud.

    (For those who were genuinely wondering)
    </font> <font size="4">CRUD = Create, Read, Update, Delete.</font>


  • (cs)

    Are you sure this isn't part of your forum software? [:P]

  • (cs) in reply to Katja

    Good old Structured Programming collides with newfangled Object Oriented.

  • (cs)

    Something tells me a few different teams did different pieces of this in wildly different ways, and then found out they had to integrate them parts. :p

    (That style is a pet peeve of mine. I prefer a clear, concise list of failure situations, followed by unindented code, rather than a mountain of indents whose side effects you can only find by searching for the same indented one and praying the indentation is correct. Obviously it doesn't matter for branches that are equally complex or where each side has to pass through for cleanup... but WHY make it so much more difficult to read here? Ingrained habit?)

  • (cs) in reply to foxyshadis

    <font face="Times New Roman">I too prefer the unindented style that returning from the middle of a function gives you:</font>

    <font face="Courier New"> If</font>    <font face="Courier New"> sUserName == "" Then
        Response.Redirect("login.asp?Err=1")
        Return
    End     If
    If Not     CheckLicences(sUserName) Then
            Response.Redirect("login.asp?Err=6")
        Return
    End If</font>

    <font face="Times New Roman"> However, the real problem here is that he broke the cardnal rule of if/else statements: put the short case first:</font>

    <font face="Courier New"> If sUserName == "" Then

        Response.Redirect("login.asp?Err=1")
    Else
        If Not     CheckLicences(sUserName) Then
                Response.Redirect("login.asp?Err=6")
        Else
            ...
        End If

    End If

    <font face="Times New Roman">If you do that, you do get a bit of nesting, but it's still quite readable.</font>
    </font>

  • (cs) in reply to foxyshadis
    foxyshadis:
    That style is a pet peeve of mine. I prefer a clear, concise list of failure situations, followed by unindented code, rather than a mountain of indents whose side effects you can only find by searching for the same indented one and praying the indentation is correct.


    Don't you just love the totally arb mix of negated and non-negated conditions as well?
  • (unregistered)

    Anybody notice that it checks the password if the CheckDisabled returns true? Then it only allowed disabled user to login?

     

  • (cs) in reply to

    If Not(CheckPasswordExpDate(sUserName, sPassword)) Then

    <FONT color=#000000>This strikes me as a function having the wrong name...</FONT>

    <FONT color=#000000>A function called 'CheckPasswordExpDate' makes me think it returns something other than a boolean. Maybe a Date?</FONT>

    <FONT color=#000000>They should have called it 'CheckPasswordExpired' IMHO.</FONT>

    <FONT color=#000000></FONT> 

    <FONT color=#000000>Drak</FONT>

  • (cs) in reply to Katja

    Classic!

  • (cs) in reply to Katja

    Katja:
    Are you sure this isn't part of your forum software? Stick out tongue

    Classic.

    That's what I meant to say, *mutters something about the board*

  • (cs)
    Alex Papadimoulis:

    ...a Windows-DNA architecture...



    Is that like programming by evolution or the Evolution Pattern?
    Are we talking mutation here?
  • (unregistered)

    I always thought a fun (albeit perfectly pointless) way to do a state machine would be to write a set of functions which return pointers to each other (or references, if that's what the language supports (but not closures with their own state -- don't make me come over there!)).

    In C/C++, of course, you can't define a function which returns a pointer to itself (this is a logical impossibility, not a language feature; think about it). So you'd have to resort to goofy typecasts, which would spoil the fun. You could, however, define a base class with a single pure virtual which returns a pointer to the base class. For each state function, you would then derive a class from the base. None of the classes would have any data members, nor any member functions other than the one virtual. Define one instance of each (the state functions can't be static, for obvious reasons), and you're in business.

    Now that would be a "curious perversion", but not a WTF. But contemplate this: If your base class were a COM interface, your state machine could be arbitrarily extensible. And that might actually be worth doing.

  • (cs) in reply to
    In C/C++, of course, you can't define a function which returns a pointer to itself (this is a logical impossibility)


    Really ? Never heard of function pointers ? If you can design a function that call itself, why this same function would not be able to return a pointer to itself ?

    I'm sure its possible... probably that this code would make a good entry here, but still ;-)
  • (cs) in reply to Drak

    Drak:
    <FONT color=#000000>They should have called it 'CheckPasswordExpired' IMHO.</FONT>

    No, they should have called it

    <FONT face="Courier New">HasPasswordExpired()</FONT>

    or

    <FONT face="Courier New">PasswordHasExpired()  
    </FONT>(as in "<FONT face="Courier New">If User.PasswordHasExpried then</FONT>"  --- see? it's like English!)

    We want names which not only indicate what is the type of the return value, but also make it clear what that value means.

     

  • (cs) in reply to martinm1000

    martinm1000:

    Really ? Never heard of function pointers ? If you can design a function that call itself, why this same function would not be able to return a pointer to itself ?

    Yes, we have, and no it's not.

    Consider the general form :

    <FONT face="Courier New">T func(void);</FONT>

    A pointer to such a function would be

    <FONT face="Courier New">T (*pfunc)(void);</FONT>

    Now, it declare a function returning a pointer to itself, you'd have to substitute the second code snippet in for T in the first.  But, you'll still have a T in there, so you'll have to substitute again, and again, and so on.  You're stuck with a recursive declaration with no end it sight.

  • (cs) in reply to JamesCurran

    hmmm, looks like you are right ;-)
    Good discussion here


  • (unregistered)

    Yes! You finally fixed the horizontal scrolling - that was bugging me for so long.

    Keep up the good word - I'll read the post in a few mins.

    - Reagan Williams

  • (cs) in reply to JamesCurran
    JamesCurran:

    [image] martinm1000 wrote:

    Really ? Never heard of function pointers ? If you can design a function that call itself, why this same function would not be able to return a pointer to itself ?

    Yes, we have, and no it's not.

    Consider the general form :

    <FONT face="Courier New">T func(void);</FONT>

    A pointer to such a function would be

    <FONT face="Courier New">T (*pfunc)(void);</FONT>

    Now, it declare a function returning a pointer to itself, you'd have to substitute the second code snippet in for T in the first.  But, you'll still have a T in there, so you'll have to substitute again, and again, and so on.  You're stuck with a recursive declaration with no end it sight.

    bah, trivial:

    typedef void * (*returns_self) (void);
    void* IReturnMyself(void);
    main()
    {
        returns_self recurseforever = IReturnMyself;
        while (1)
        {
            recurseforever = ((returns_self)recurseforever());
        }
    }

  • (cs) in reply to dbt
    dbt:
    bah, trivial:

    typedef void * (*returns_self) (void);

    The original statement was

    you can't define a function which returns a pointer to itself

    Your example doesn't do that.  It defines a function which returns a void* and then uses a sledge hammer to pound it into the right type.  (Note that a void* is required to be able to hold a pointer to any data type, but is NOT required to be able to hold a pointer to a function)

  • (cs) in reply to JamesCurran
    JamesCurran:
    [image] dbt wrote:
    bah, trivial:

    typedef void * (*returns_self) (void);

    The original statement was

    you can't define a function which returns a pointer to itself

    Your example doesn't do that.  It defines a function which returns a void* and then uses a sledge hammer to pound it into the right type.  (Note that a void* is required to be able to hold a pointer to any data type, but is NOT required to be able to hold a pointer to a function)

    Here's to hoping a quote of a quote works :P

    There's no way to do this by declaring the function without any content beforehand is there (God, what's that called again? Pre-declaration?)? I'm not sure, that's why I'm asking [:S]

  • (unregistered)

    For what it's worth dept:

    The following compiles in Component Pascal:

    MODULE Test;

        TYPE
         StateFunc = POINTER TO EXTENSIBLE RECORD END;
            PROCEDURE(x:StateFunc) Do():StateFunc, NEW,  EXTENSIBLE;
            BEGIN
                RETURN x;
                END Do;
       
    END Test.

    Maysonl at gmail

  • (unregistered) in reply to martinm1000
    martinm1000:
    In C/C++, of course, you can't define a function which returns a pointer to itself (this is a logical impossibility)


    Really ? Never heard of function pointers ? If you can design a function that call itself, why this same function would not be able to return a pointer to itself ?


    I'm sure its possible... probably that this code would make a good entry here, but still ;-)


    wtf: Here it is in Component Pascal(see www.oberon.ch/blackbox/)

    MODULE StateFuncs;

        TYPE
            State* = POINTER TO EXTENSIBLE RECORD
                func*: StateFunc;
                END;
           
            StateFunc* = PROCEDURE (x: State) : StateFunc;
           
           
            END StateFuncs.
  • (cs)

    A fine example of why "a code block should only have one exit point!" is a bad idea.

     

    Mind you - soneone ought to explain elseif (or elif) to this person.

  • (cs) in reply to

    A very old joke, you whippersnapper. Create/Review/Update/Delete. Used for any formm whose basic role in life is to allow a user to edit a row or rows in a database.

  • (cs) in reply to Miles Archer

    Miles Archer:
    Good old Structured Programming collides with newfangled Object Oriented.

    Object Oriented builds on structured. Each generation of computing languages has done the same job: to encapsulate complexity into managable chunks.

  • (cs) in reply to martinm1000
    martinm1000:
    In C/C++, of course, you can't define a function which returns a pointer to itself (this is a logical impossibility)



    Really ? Never heard of function pointers ? If you can design a function that call itself, why this same function would not be able to return a pointer to itself ?

    I'm sure its possible... probably that this code would make a good entry here, but still ;-)

    And it would return type "pointer to a function returning a pointer to a function returning a po ...". Hmm. I guess you'll just have to make it a void* and cast it.

    Or, 

    [code language="java"]interface CallableThing {
       CallableThing callMe();
    }[/code]

    which is how you do polymorphism in OO languages.

  • DamienD (unregistered)

    That's functional programming!

  • Max Guernsey, III (unregistered)

    "But if your object-oriented solution is a class for each function you need, I'm not sure any enterprise architecture pattern will help."

    This is crafted to imply that "a class for each function you need" is inherently bad, which is a very naive position to take. The real problems, here, are duplication and coupling.

    This duplication and coupling problem appears to extend down into the two COM layers mentioned in that every UI method corresponds to one business rule object and every business rule object corresponds to one data access object. It seems unlikely for this to be a natural design.

    The number of functions per class have nothing to do with it.

Leave a comment on “Object Disoriented ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article