How to share object functionality



  • First post ever.

    Now  i'm in this company that work on shop automation
    since 6 months.

    So, our biggest project is a software that handles POS HW with a neat GUI interface, sales storing etc etc, nothing amazingly but here in italy the market is quite ground level in this sector.

    In this piece of SW we have a class named Bill, with various methods and properties, including a property ROWS that's a collection of ROW objects, ok?

    Last week i coded some routines that takes a COPY of a random bill obj and calulates some discount issues reading and modifying the rows obj contained in the ROWS collection.

    yesterday the hell comes out... Some customers starting to call in, sayng that their reports are all wrong, that totals are all crap and their software become completely crazy.

    So we go ahead and did some checks to see what's wrong with the latest implementation of the sofware.

    Here comes the WTF.

    Now, to share in the project source that DAMN ROWS COLLECTION, my collegue has declared a PUBLIC collection of rows that is instantiated once in a while and all the damn bill obj that u can create refers on that unique collections of rows.

    Now that's oop...





  • Clarify for me - Did your cow-orker just change the class that stored the rows, so that your own code recompiled fine, or did they change both the class and the code that accessed it?

    But since we're on about OOP and especially accessors, I can understand why Java did not include a 'getter' feature; I was working with LLBLGen the other day and found out (by debugging into the generated code) that a bunch of static things in classes are actually getters that instantiate a new object each time. ARGH! The semantic meaning of a getter should IMHO be "All values that come out of this getter are effectively the same unless the object has been altered otherwise." I'm not so lazy that I wouldn't type the extra "()" to distinguish the two.



  • is the culprit still working there? if yes, that would be a wtf on top of a wtf



  • Static methods that instanciate new objects are called Factory Methods, and are in fact a know pattern. Also, I don't think you should call those methods getters; A "Getter" should be to control access to a variable, on a non static object (well that's how I see that).



  • @Vaitrafra said:

    First post ever.

    Now  i'm in this company that work on shop automation
    since 6 months.

    So, our biggest project is a software that handles POS HW with a neat GUI interface, sales storing etc etc, nothing amazingly but here in italy the market is quite ground level in this sector.

    In this piece of SW we have a class named Bill, with various methods and properties, including a property ROWS that's a collection of ROW objects, ok?

    Last week i coded some routines that takes a COPY of a random bill obj and calulates some discount issues reading and modifying the rows obj contained in the ROWS collection.

    yesterday the hell comes out... Some customers starting to call in, sayng that their reports are all wrong, that totals are all crap and their software become completely crazy.

    So we go ahead and did some checks to see what's wrong with the latest implementation of the sofware.

    Here comes the WTF.

    Now, to share in the project source that DAMN ROWS COLLECTION, my collegue has declared a PUBLIC collection of rows that is instantiated once in a while and all the damn bill obj that u can create refers on that unique collections of rows.

    Now that's oop...



    How did the change you implemented get released when it caused such a show-stopper?

    sincerely,
    Richard Nixon



  • @Richard Nixon said:

    @Vaitrafra said:
    First post ever.

    Now  i'm in this company that work on shop automation
    since 6 months.

    So, our biggest project is a software that handles POS HW with a neat GUI interface, sales storing etc etc, nothing amazingly but here in italy the market is quite ground level in this sector.

    In this piece of SW we have a class named Bill, with various methods and properties, including a property ROWS that's a collection of ROW objects, ok?

    Last week i coded some routines that takes a COPY of a random bill obj and calulates some discount issues reading and modifying the rows obj contained in the ROWS collection.

    yesterday the hell comes out... Some customers starting to call in, sayng that their reports are all wrong, that totals are all crap and their software become completely crazy.

    So we go ahead and did some checks to see what's wrong with the latest implementation of the sofware.

    Here comes the WTF.

    Now, to share in the project source that DAMN ROWS COLLECTION, my collegue has declared a PUBLIC collection of rows that is instantiated once in a while and all the damn bill obj that u can create refers on that unique collections of rows.

    Now that's oop...



    How did the change you implemented get released when it caused such a show-stopper?

    sincerely,
    Richard Nixon

    Possibly whoever did the testing (if there even was any) assumed that the software author wouldn't do anything that incredibly dumb (possibly without even realising they were making that assumption). If they didn't try using more than one Bill object at the same time in the correct way, then it wouldn't get spotted - until it got released and the complaints from the customers came in.



  • @makomk said:

    @Richard Nixon said:
    @Vaitrafra said:
    First post ever.

    Now  i'm in this company that work on shop automation
    since 6 months.

    So, our biggest project is a software that handles POS HW with a neat GUI interface, sales storing etc etc, nothing amazingly but here in italy the market is quite ground level in this sector.

    In this piece of SW we have a class named Bill, with various methods and properties, including a property ROWS that's a collection of ROW objects, ok?

    Last week i coded some routines that takes a COPY of a random bill obj and calulates some discount issues reading and modifying the rows obj contained in the ROWS collection.

    yesterday the hell comes out... Some customers starting to call in, sayng that their reports are all wrong, that totals are all crap and their software become completely crazy.

    So we go ahead and did some checks to see what's wrong with the latest implementation of the sofware.

    Here comes the WTF.

    Now, to share in the project source that DAMN ROWS COLLECTION, my collegue has declared a PUBLIC collection of rows that is instantiated once in a while and all the damn bill obj that u can create refers on that unique collections of rows.

    Now that's oop...



    How did the change you implemented get released when it caused such a show-stopper?

    sincerely,
    Richard Nixon

    Possibly whoever did the testing (if there even was any) assumed that the software author wouldn't do anything that incredibly dumb (possibly without even realising they were making that assumption). If they didn't try using more than one Bill object at the same time in the correct way, then it wouldn't get spotted - until it got released and the complaints from the customers came in.



    That type of testing coverage is just as big a problem as the poor coding.

    sincerely,
    Richard Nixon



  • @Richard Nixon said:

    @makomk said:
    @Richard Nixon said:
    @Vaitrafra said:
    First post ever.

    Now  i'm in this company that work on shop automation
    since 6 months.

    So, our biggest project is a software that handles POS HW with a neat GUI interface, sales storing etc etc, nothing amazingly but here in italy the market is quite ground level in this sector.

    In this piece of SW we have a class named Bill, with various methods and properties, including a property ROWS that's a collection of ROW objects, ok?

    Last week i coded some routines that takes a COPY of a random bill obj and calulates some discount issues reading and modifying the rows obj contained in the ROWS collection.

    yesterday the hell comes out... Some customers starting to call in, sayng that their reports are all wrong, that totals are all crap and their software become completely crazy.

    So we go ahead and did some checks to see what's wrong with the latest implementation of the sofware.

    Here comes the WTF.

    Now, to share in the project source that DAMN ROWS COLLECTION, my collegue has declared a PUBLIC collection of rows that is instantiated once in a while and all the damn bill obj that u can create refers on that unique collections of rows.

    Now that's oop...



    How did the change you implemented get released when it caused such a show-stopper?

    sincerely,
    Richard Nixon

    Possibly whoever did the testing (if there even was any) assumed that the software author wouldn't do anything that incredibly dumb (possibly without even realising they were making that assumption). If they didn't try using more than one Bill object at the same time in the correct way, then it wouldn't get spotted - until it got released and the complaints from the customers came in.



    That type of testing coverage is just as big a problem as the poor coding.

    sincerely,
    Richard Nixon


    You are right Nixon, btw the time is what it is and everybody told me that he's an experienced coder...
    In addiction to that, the specifics of the project says thet the bill clas MUST be multi istance(u can have more than one bill object active at the same time).
    So, on a side ther's my "not test properly" fault, on the other side there's a big WTF.


Log in to reply