We have 10,000 test cases!



  • A year ago, we were bought out. I saw an audit coming and got our test cases (among other things) in order. 

    This afternoon, a peer system came under the scrutiny of those same auditors. Their lead developer bragged to both manager and auditors that "We have 10,000 test cases!" to guarantee that our code works properly. We run them after every check in, and build/test twice a day on top of that. We haven't had a failure in months!

    The auditors decide to take a random check, and find that may of the tests look like this:

      public void testMethod1() {
        Xyz xyz = new Xyz();
        xyz.setString("Hello");
        assertEquals("Hello",xyz.getString());
      }
    

    The remainder (over 9,000) look like this:

      public void testXyz() {
        try {
            // do test stuff
        } catch (Throwable t) {
          log.info("Bad thing happened");
        }
      }
    

    They did not pass the audit.

    Since our system passed the audit the first time out, they came to my boss and asked him if we could fix the test cases of the other system to see what state the thing is actually in. He asked me to do it for the other system.

    Everything I touched would be reviewed by auditing so there'd be no chance to let them fix stuff before I reviewed it. 

    Don't get me wrong, it's lots of billable time, but who wants to piss off their coworkers, even stupid ones, like that?



  • Not to mention how boring it would be...



  • @snoofle said:

    public void testMethod1() {
    Xyz xyz = new Xyz();
    xyz.setString("Hello");
    assertEquals("Hello",xyz.getString());
    }

    This is the kind of bullshit so many Java developers propagate. Getters/setters for every instance variable; lots of wasted effort testing shit like that getFoo() returns the same thing setFoo() took.. This is half the reason I despise Java. It's like people start writing Java and they just turn off all critical thinking. The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas". It's probably why so many of the managers of Java developers that I've talked to have felt that all of their Java devs were interchangeable cogs.



  • @morbiuswilters said:

    The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas".

    But surely that's the difference between a Programmer and a Software Engineer - code written by Java programmers lacking design and engineering theory seems to be Java Kata. I don't think snoofle's been taken on purely because he can code Java but more that he's matured into design (and thus consultancy than contracting).

    I don't believe big enterprise houses can get away with this kind of immature Java hackery - there's got to be some underlying principles that guide effective and efficient designs for thecoder to realise and implement. OTOH, a few tales on here about the quality of some enterprisey systems suggest otherwise...



  • @Cassidy said:

    I don't believe big enterprise houses can get away with this kind of immature Java hackery - there's got to be some underlying principles that guide effective and efficient designs for thecoder to realise and implement. OTOH, a few tales on here about the quality of some enterprisey systems suggest otherwise...

    There's only so much that a few clueful people can do, though. And once enough stuff accretes, it's even more difficult to refactor it all into submission. I think that the bottom line is that the demand for programming is greater than the actual supply of people who actually know what they're doing.

    So you really can't avoid having these guys around dragging everyone else down in a big shop. Eventually, they sneak in, no matter how careful you are, and it's often more difficult to get rid of people in a large enterprise than a small shop.



  • 10,000 test cases you say? Hmm, that reminds me of a guy I used to work with who created an automated test case generator... in EXCEL.

    See, he had this big long Excel spreadsheet given to him by the client with amortization tables or something on it, so to make sure that his program worked properly, he created a VBA macro which scanned through the tables and generated a ton of JUnit test code.

    I think he said there were something like 2,000 test cases altogether... all in one huge Java file that made Eclipse slow to a crawl while loading it!



  • @snoofle said:

    Since our system passed the audit the first time out, they came to my boss and asked him if we could fix the test cases of the other system to see what state the thing is actually in. He asked me to do it for the other system.

    Everything I touched would be reviewed by auditing so there'd be no chance to let them fix stuff before I reviewed it. 

    Don't get me wrong, it's lots of billable time, but who wants to piss off their coworkers, even stupid ones, like that?

    Everything you touched would get reviewed by auditing.  When?  If you're able to look at a block of code, tell the other group your findings, and they can fix them before you commit your test, I don't see an issue with the setup from that perspective.

    On the other hand...  In every audit situation I've encountered, there's an audit period.  If the group fails the audit, there's a corrections period, during which changes can be made without the detailed scrutiny of a full audit.  While the followup audit that happens tends to be more careful than it would have been without the failed audit, they generally don't have time to look at *every* change.  That corrections period is very important, because there are frequently problems so bad that one would worry one could lose ones job if it was ever discovered.  Without a corrections period, one would never want to even go near fixing that bug.

    On the gripping hand, someone wrote their actual test cases.  That individual, if still available, could probably handle fixing up their test cases, too.  If the group dynamic is anything like the ones where I've tried inserting automated tests despite extreme coworker resistance, that individual is already hated by all of his coworkers, so he doesn't really have the same risk.  Of course, if that individual already fled to saner pastures...



  • @morbiuswilters said:

    This is the kind of bullshit so many Java developers propagate. Getters/setters for every instance variable; lots of wasted effort testing shit like that getFoo() returns the same thing setFoo() took.. This is half the reason I despise Java. It's like people start writing Java and they just turn off all critical thinking. The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas". It's probably why so many of the managers of Java developers that I've talked to have felt that all of their Java devs were interchangeable cogs.

    I was under the impression that this was actually the main selling point of Java in enterprise.

     



  • @morbiuswilters said:

    This is half the reason I despise Java. It's like people start writing Java and they just turn off all critical thinking. The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas". It's probably why so many of the managers of Java developers that I've talked to have felt that all of their Java devs were interchangeable cogs.

    It's probably the 10/80/10 rule: 10% of programmers are very very good, 10% are very very bad, and 80% are mediocre. That should be independent of language, although market forces tend to select certain types. 

    [soapbox] I like Java. But what I hate about Java is that the developers looked at all the ways to do something, decided what was best, and made all the other ways illegal. PHP lets you shoot youself in the food; Java won't let you near a gun.[/soapbox]

     



  • @ais523 said:

    @morbiuswilters said:

    This is the kind of bullshit so many Java developers propagate. Getters/setters for every instance variable; lots of wasted effort testing shit like that getFoo() returns the same thing setFoo() took.. This is half the reason I despise Java. It's like people start writing Java and they just turn off all critical thinking. The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas". It's probably why so many of the managers of Java developers that I've talked to have felt that all of their Java devs were interchangeable cogs.

    I was under the impression that this was actually the main selling point of Java in enterprise.

     

    It is, which is my point. The mindset that process and tools will make up for shitty developers is idiotic.



  • @morbiuswilters said:

    It is, which is my point. The mindset that process and tools will make up for shitty developers is idiotic.

    Possibly even counter-productive, because it scares away the good developers.



  • @morbiuswilters said:

    @snoofle said:

    public void testMethod1() {
    Xyz xyz = new Xyz();
    xyz.setString("Hello");
    assertEquals("Hello",xyz.getString());
    }

    This is the kind of bullshit so many Java developers propagate. Getters/setters for every instance variable; lots of wasted effort testing shit like that getFoo() returns the same thing setFoo() took.. This is half the reason I despise Java. It's like people start writing Java and they just turn off all critical thinking. The guiding theory behind Java development seems to be "you don't need to use your brain (or rely on the flawed brains of your employees) if you just follow all of these mechanical formulas". It's probably why so many of the managers of Java developers that I've talked to have felt that all of their Java devs were interchangeable cogs.

     

    While i almoste certainly recommend my team to use getters / setters, i explicitly mandate that simple getters / setter never be tested. That would be a waste of time. If the getters / setter fail, you wil discover it when higher level tests on the program logic will fail because datas are inconsistent. So that would better be

    public void testMethod1() {
        SomeDictionnary dictionnary = loadTestDictionnary();
    Xyz xyz = new Xyz();
    xyz.setString("Hello");
    assertEquals(xyz,dictionnary.findByIndex(dictionnary.getIndex(xyz)));
    }
     
    <font face="arial,helvetica,sans-serif">On the fun side, i got a code sample at an interview from someone, the zip contained a unit test of about 200 lines that looked like this</font>
    try{
    // lots of code without asserts
    } catch (Exception e){
    System.err.println("Something went wrong with test xyz",e.getMessage());
    // fail();
    }

     



  • @tchize said:

    While i almoste certainly recommend my team to use getters / setters, i explicitly mandate that simple getters / setter never be tested.

    I think Morbs' point is that not every instance variable needs a getter/setter - firstly, some private variables will be for helper functions and not accessible outside, and secondly some classes will have some mandatory attributes set during object creation.... it doesn't make sense to have public setters because it's unlikely you'll be setting/modifying that attribute in isolation.

    Also... if you don't perform testing upon these methods... how do you know they work? Or do you just have a unit sign-off by the dev? (not saying this is insufficient, but small cog in a big machine and all that...)

    @AndyCanfield said:

    PHP lets you shoot youself in the food

    Damn, that sounds painful. I'd better drop PHP development for the sake of my "meat n two veg".

    ObReRail: TRWTF is someone confusing quantity for quality, right? Clearly their assurance process... needs quality-assuring.

     

     



  • Hey back off, I created an Excel test case system -)

    Well.. actually it was a security matrix in Excel, and I then wrote a unit test case to hit every element in the matrix using the security code.

    It worked so well that I then wrote some more code to generate the security code from the Excel worksheet.

    Now the tests will always pass, provided the sheet and the code are both in sync!



  • @snoofle said:

    Don't get me wrong, it's lots of billable time, but who wants to piss off their coworkers, even stupid ones, like that?

    pfff... just imagine when your rightly developed unit tests fail because their code is as shitty as their testing abilities



  • Oh yes... White box testing. Completely meaningless in most cases and the "test cases" are created only to tick the box and please the ignorant idiots at QA.

    I have only done meaningful white box testing/component testing in safety critical systems.

    In the vast majority of software systems test cases should test business logic, business functionality and requirements.



  • That's because Java has told us not to make instance variables public/protected, i.e., always expose it through appropriate get/set/is methods.  Therefore, it's a method, and needs to be tested.  Frankly, the test in the example is appropriate to test these methods, (although it really isn't fine grained enough to isolate a potential error.  Is the error in get or set?)

    This is where I prefer the C# model of properties.

    public String myString {get; set;}


    This doesn't require testing.

    But, If I needed something more complex -- I can still use the java idiom.

    public String setMyString(String value)

    { if (value != null && value.Equals("snoofle") myString=value;

     else myString="Invalid Sentinel";

    }

     

    Now this can be tested, quite easily, and we can find out where the error is easily by running assertEquals(myString, "morbius"); and finding out that our setter is not allowing a valid input.

     



  • @mightybaldking said:

    Therefore, it's a method, and needs to be tested.

    Equivalently, "Things that are measured get done." Method / LOC level test coverage metrics are easy to collect and inspect. Of course, they aren't useless, but when you get evaluated on it, that's what you focus on.

    This is more of a problem with large enterprise environments that use metrics (CMMI, anyone?). Of course, there are lots of tools available for Java, which makes it appropriate for that sort of environment. Does, say, PHP have similar things as easily available (honest question)? Personally, I view coverage as necessary, but not sufficient to believe in a suite of tests, but it's hard to get an automated measure of how much of the problem space you've actually tested, and almost no customers are willing to pay for the human intensive effort required to ensure that you get this.



  • > That's because Java has told us not to make instance variables public/protected

    No, some blokes at Sun conjured that up more than a decade ago when people were also very into writing code in a dozen layers and people were still under the illusion that you could reuse classes and even sell them as components. Java is only a tool waiting to be used by capable hands, controlled by a brain that can produce solid reasoning.

     > Therefore, it's a method, and needs to be tested.

    I rebel. No I don't. And I don't. Lo and behold, stuff I make tends to "just work" anyway, even when I cherry pick for which code I create unit and/or system tests in stead of providing 120% code coverage. Sure in every project there are always a few tests that I miss, especially in failure paths. Something goes wrong, I fix what is wrong, I create a unit test to prove that what I did is correct and everyone is happy. I don't have 100% code coverage, but all my tests do make perfect sense at least.



  •  The insistance on using getters/setters stems from the OO principal of data abstraction, interpreted thus: Don't let anybody see our data (instance variables) directly; instead make all members private and only allow access through getters and setters. This allows us to change the implementation without having to change the contract (if we want to move some instance variables to some sub-container then we only need to change the getters and setters in one place rather than going through, finding and replacing all of the places where those fields are referenced directly - of course how often do we ever refactor the structure of the data after it has been well-established, aside from expected things like introducing new fields or deprecating old ones).  

    Granted this makes things really obnoxious - a data class which doesn't contain any real logic takes 4-8 times as many lines with private fields and getters and setters than if it were just implemented with public (final) fields, and then instead of accessing foo.bar, you have to call foo.getBar() (which as I understand it, the JVM optimizes trivial getters and setters to direct accesses, so at least there's no performance penalty when running the code).  But then IDE's make it trivially easy to add all of the getters and setters, write the constructors, etc. and that's why most alternate JVM languages map a failed access of foo.bar to foo.getBar()/setBar(...).

     Of course there's no reason why you couldn't have the main data class have all of the getters and setters, but use (private) local sub-containers with all "public" fields accessed directly by the main class's getters/setters, or even go as far as to restrict the namespace visibility (package private?) of the main data class and use direct access within that namespace and only expose publicly the higher-level functionality of the whole package.

    As for Unit testing, I see no point in unit testing a trivial getter or setter; however as soon as it is changed in any way it then any variations in behavior should be unit tested.  Of course this means testing each getter and setter in the main data class.



  • @erikal said:

    > That's because Java has told us not to make instance variables public/protected

    No, some blokes at Sun conjured that up more than a decade ago when people were also very into writing code in a dozen layers and people were still under the illusion that you could reuse classes and even sell them as components.

     

    That "illusion" is working just fine for Delphi, which was released at the same time as Java.  The problem is that Java implemented it horribly.  Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.

     



  • @airdrik said:

    ...

    Granted this makes things really obnoxious - a data class which doesn't contain any real logic takes 4-8 times as many lines with private fields and getters and setters than if it were just implemented with public (final) fields, and then instead of accessing foo.bar, you have to call foo.getBar() (which as I understand it, the JVM optimizes trivial getters and setters to direct accesses, so at least there's no performance penalty when running the code).  But then IDE's make it trivially easy to add all of the getters and setters, write the constructors, etc. and that's why most alternate JVM languages map a failed access of foo.bar to foo.getBar()/setBar(...).

     ...

    This is one of the things I love about C#.  The get and set for variables if done properly makes the code look like a regular variable to the outside world while internally using the get or set.  So converting a variable to a private variable with a get set is relatively easy and far more seamless.  For an example of what it looks like:



  • @Anketam said:

    This is one of the things I love about C#.  The get and set for variables if done properly makes the code look like a regular variable to the outside world while internally using the get or set.  So converting a variable to a private variable with a get set is relatively easy and far more seamless.  For an example of what it looks like:

    Or just use auto properties (http://msdn.microsoft.com/en-us/library/bb384054.aspx).  It's the best of both worlds.


  • @snoofle said:

    who wants to piss off their coworkers, even stupid ones, like that?

    I do! It's a great job!



  • @snoofle said:

    who wants to piss on their coworkers, even stupid ones, like that?

    People have weird hobbies



  • @Mason Wheeler said:

    Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.
     

    This is generally spectacularly difficult to do.



  • @mightybaldking said:

    This is where I prefer the C# model of properties.

    public String myString {get; set;}


    This doesn't require testing.

    But, If I needed something more complex -- I can still use the java idiom.

    public String setMyString(String value)

    { if (value != null && value.Equals("snoofle") myString=value;

     else myString="Invalid Sentinel";

    }

    What??...

    I really hope you meant this (but somehow I don't think you did):

    public String myString

    {

      set

      {

        if(conditions) myString = value;

        else myString = "Invalid"

      }

    }



  • @Sutherlands said:

    @mightybaldking said:

    This is where I prefer the C# model of properties.

    public String myString {get; set;}


    This doesn't require testing.

    But, If I needed something more complex -- I can still use the java idiom.

    public String setMyString(String value)

    { if (value != null && value.Equals("snoofle") myString=value;

     else myString="Invalid Sentinel";

    }

    What??...

    I really hope you meant this (but somehow I don't think you did):

    public String myString

    {

      set

      {

        if(conditions) myString = value;

        else myString = "Invalid"

      }

    }

    Why are you setting the string to "Invalid"? What if the string is legitimately allowed to be "Invalid"? How does calling code know that an error has occurred?



  •  No.  I didn't mean that. 

    I meant, that if you have a property that can't be simply assigned, then you should create an explicit setProperty(value) method, and make the property set private.

    so in the calling code, it becomes 

    MyClassInstance.SetMyString("somevalue") instead of MyClassInstance.MyString = "someValue";

    Granted, my example was a bit too trivial, and a simple guard condition might not warrant this approach.  But if you need to do real work, then you should create an explicit setter. 

    Then, blindly applying the "All methods must have test cases" rule works in our favour, and we are testing something meaningful.

     

     

    Also, your example will go into an infinite recursion.

     

     

     



  • @boomzilla said:

    Equivalently, "Things that are measured get done." Method / LOC level test coverage metrics are easy to collect and inspect. Of course, they aren't useless, but when you get evaluated on it, that's what you focus on.

    I'm curious if anyone ever tried to perform a stunt like this to improve his code coverage reports :-)

    It was fun to write as a POC, but I'd never commit it as a test case for a real life project.



  • @morbiuswilters said:

    Why are you setting the string to "Invalid"? What if the string is legitimately allowed to be "Invalid"? How does calling code know that an error has occurred?

    @mightybaldking said:

    Also, your example will go into an infinite recursion.

    The point of my post is that you can use properties to implement logic, such as bounds checking.  If you're saying that you were trying to make an example of where the function is fairly complex and might not respond right away, then that could be a valid time to use a method instead of just using the set; on the property.  Just because you're implementing some logic in a getter or setter doesn't mean you shouldn't use properties.



  • @Sutherlands said:

    @morbiuswilters said:

    Why are you setting the string to "Invalid"? What if the string is legitimately allowed to be "Invalid"? How does calling code know that an error has occurred?

    @mightybaldking said:

    Also, your example will go into an infinite recursion.

    The point of my post is that you can use properties to implement logic, such as bounds checking.  If you're saying that you were trying to make an example of where the function is fairly complex and might not respond right away, then that could be a valid time to use a method instead of just using the set; on the property.  Just because you're implementing some logic in a getter or setter doesn't mean you shouldn't use properties.

    For simple values, I just use public variables. If there is some invariant to be enforced, I would use a method, but that's not a common occurrence. This only leaves the case where the assignment logic changes; in Java I would just change the calling code (it's really not that difficult and often it's necessary anyway to take into account the new invariant); in PHP I would just "hide" the variable and then implement __set() and __get() code for it. C# properties sound nice and basically I've just implemented them in PHP since it lacks such a feature natively.



  • @morbiuswilters said:

    Just because you're implementing some logic in a getter or setter doesn't mean you shouldn't use properties.
     

    Actually, the operative word was "trivial".  You can certainly make the case that a simple guard condition or a toUpper or other simple enhancement over plain assignment is trivial.

    What I'm getting at is the concept that we can use the framework to our advantage and keep the bean counters happy.

    Perhaps what I should have said is:

    If the way you access instance variables contains logic that needs to be tested, then make explicit get / set methods. 

    If the access is trivial (or nearly so) then use C# properties or a reasonable facsimile thereof in your language of choice.

    Like the Java Swing rule that says "Never do real work in an event listener", I go by the rule: "Never do real work in a property block."

    And it works.  A java alternative would be a @TrivialMethod annotation that would allow test coverage rules to ignore such methods.  Then we can relentlessly mock those who abuse it.

     

     

     

     

     

     



  • @mightybaldking said:

    @morbiuswilters said:

    Just because you're implementing some logic in a getter or setter doesn't mean you shouldn't use properties.
     

    Quoting fail.

    @mightybaldking said:

    Perhaps what I should have said is:

    If the way you access instance variables contains logic that needs to be tested, then make explicit get / set methods. 

    If the access is trivial (or nearly so) then use C# properties or a reasonable facsimile thereof in your language of choice.

    Yes, you should have said that :P


  • @mightybaldking said:

    Actually, the operative word was "trivial".  You can certainly make the case that a simple guard condition or a toUpper or other simple enhancement over plain assignment is trivial.
     

    This is my take on it as well.  If it truly is just a data store, then don't put it behind a function call.  If there is certain semantic information associated with the parameter, though, then it does make sense to have some functionality associated with the "set."  For the life of me, though, I can't understand why you would ever need any logic on a "get" unless the thing you're getting isn't really a value but an interpretation of a value.

    I have a hard time with languages that have getters and setters, or even the way C#.Net does the properties, because it wrecks the semantic distinction between a simple data primitive and a parameter with semantics.  I can see how in some cases this is valuable, but I'm not sure I'm familiar with the cases where you really want a get or a set.

    Then again, I don't really like the try/catch paradigm either.  I think it's because I hold the philosophy that it should be impossible for a line like

    var_a = var_b;

    to fail.  If you have a world where that assignment operator actually has more semantics behind it than pure assignment, then you have the whole can of worms that comes up - not the least of which that when you have a catch block you are "handling" the error in a different place from where the error occurred.  I guess I'm too used to situations where it's better to force people to think about possible failures on each line rather than all lumped together in some catch block.



  • @too_many_usernames said:

    This is my take on it as well.  If it truly is just a data store, then don't put it behind a function call.  If there is certain semantic information associated with the parameter, though, then it does make sense to have some functionality associated with the "set."  For the life of me, though, I can't understand why you would ever need any logic on a "get" unless the thing you're getting isn't really a value but an interpretation of a value.

    Are you people serious? As too_many_usernames has danced around, sometimes you have a stored value, and sometimes a calculated value. Over time, you may want to change from one to the other. Now, if you used a getter instead of direct access, you can easily change the implementation without changing the way it's used.

    This is called "encapsulation," or "information hiding." I'm not familiar enough with the C# auto properties or whatever, which is probably why they make me feel uncomfortable looking at them. I'm sure if I used them more, they'd probably seem as similar to me as using actual methods.

    I expect PHP retards to not understand this stuff, but I thought .Net people had a clue.



  • @boomzilla said:

    Now, if you used a getter instead of direct access, you can easily change the implementation without changing the way it's used.

    You can do this with properties, too.

    @boomzilla said:

    This is called "encapsulation," or "information hiding."

    I would like a reasonable example of where you think this applies to reading/writing simple variables and what benefits you get from using accessors/mutators. I believe the "Let's wrap everything in getters/setters" is an asinine paradigm which creates more problems than it supposedly solves. Prove me wrong.



  • @morbiuswilters said:

    I would like a reasonable example of where you think this applies to reading/writing simple variables and what benefits you get from using accessors/mutators. I believe the "Let's wrap everything in getters/setters" is an asinine paradigm which creates more problems than it supposedly solves. Prove me wrong.
    Caching and sparse values.  This doesn't justify always using getters/setters, but does justify their existence.  Also, in .Net, a property is different from a public variable (technically called a field in .Net); some things that work with properties don't work with fields, like data binding.  If I recall correctly, in Java you have to explicitly call setters and getters.  If I'm right then implementing them this way right off the bat makes it easy to add things like caching without changing calling code.



  • @dhromed said:

    @Mason Wheeler said:

    Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.
     

    This is generally spectacularly difficult to do.

    And yet it still happens: many a botched implementation or failed project tends to give people the impression that the change itself was a bad idea, rather than a good idea badly released. 

    @boomzilla said:

    Equivalently, "Things that are measured get done." Method / LOC level
    test coverage metrics are easy to collect and inspect. Of course, they
    aren't useless, but when you get evaluated on it, that's what you focus
    on.

    "if you manage by metrics alone, then metrics are all you manage" - Demming



  • @morbiuswilters said:

    @boomzilla said:
    This is called "encapsulation," or "information hiding."

    I would like a reasonable example of where you think this applies to reading/writing simple variables and what benefits you get from using accessors/mutators. I believe the "Let's wrap everything in getters/setters" is an asinine paradigm which creates more problems than it supposedly solves. Prove me wrong.

    No, I agree that you believe this. Of course, if your language has some sort of syntactic sugar that hides methods the way C# does, then it would seem to accomplish the same thing. If you can't understand why it's better to simply change the implementation and leave the interface alone, then you probably write your own crypto. Jaime already mentioned caching and sparse values.

    I suppose if you're talking about people writing stupid tests, then I'd say there is an additional benefit, which is that you don't want the sort of person who will write those tests doing other stuff, because they'll just fuck it up. I don't know what other problems you're thinking of. My telepathy is on the blink. Prove yourself right.



  • @Jaime said:

    Caching and sparse values.  This doesn't justify always using getters/setters, but does justify their existence.

    I'm not saying they shouldn't exist (for non-simple uses like computed values) but that they shouldn't be used for every single value without reason.



  • @boomzilla said:

    Are you people serious? As too_many_usernames has danced around, sometimes you have a stored value, and sometimes a calculated value. Over time, you may want to change from one to the other. Now, if you used a getter instead of direct access, you can easily change the implementation without changing the way it's used.

    As the person who has been talking mostly about C#, I dare you to find one thing I said that goes against this.

    @boomzilla said:

    I'm not familiar enough with the C# auto properties or whatever
    @boomzilla said:
    but I thought .Net people had a clue.
    Indeed... usually you seem smarter to me than you did in this post. 

    Auto properties - "When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors."  Properties are simply getters and setters that you don't have to type "getVarName" to use.  They look like variables, but function like methods. (But are inlined when they're simple access to remove the function call)

     

    On a different note, a reason why you might want logic in the getter lazy initialization:

    get

    {

       if(var == null)

        var = new Object();

      return var;

    }



  • @boomzilla said:

    If you can't understand why it's better to simply change the implementation and leave the interface alone, then you probably write your own crypto.

    Right, what I'm asking for is an example where a simple get/set would need a change of implementation but not interface. I'm certainly not saying that every member should be public. It really depends on how it's going to be used, but I do frequently use public members for simple values.



  • @Sutherlands said:

    @boomzilla said:

    Are you people serious? As too_many_usernames has danced around, sometimes you have a stored value, and sometimes a calculated value. Over time, you may want to change from one to the other. Now, if you used a getter instead of direct access, you can easily change the implementation without changing the way it's used.


    As the person who has been talking mostly about C#, I dare you to find one thing I said that goes against this.

    I'm not even going to try, because I wasn't talking to you. I can see how you might have taken offense, though, and would advise you to look at the tags more closely.

    @Sutherlands said:

    @boomzilla said:
    but I thought .Net people had a clue.

    Indeed... usually you seem smarter to me than you did in this post.

    Yeah, that was mostly directed at too_many_usernames, who appeared to possibly be a .Net person, who was worried about "[wrecking] the semantic distinction between a simple data primitive and a parameter with semantics." Which is kinda the point of abstraction. Not that it isn't possible to get carried away, etc., but one goal of OOP is to abstract the requirement of external modules from having to know this sort of thing. But maybe he's not one of you.

    Of course, the number of times that you end up changing implementation from a simple getter/setter is probably really small. Still, it helps when that does occur, and it makes things more consistent, in the sense that you always access things in the same way. That starts getting into personal preferences, and there's no accounting for that.



  • @morbiuswilters said:

    @boomzilla said:
    If you can't understand why it's better to simply change the implementation and leave the interface alone, then you probably write your own crypto.

    Right, what I'm asking for is an example where a simple get/set would need a change of implementation but not interface. I'm certainly not saying that every member should be public. It really depends on how it's going to be used, but I do frequently use public members for simple values.

    Sure. You start out with an object that stores a boolean. Later on, you get an enhancement request to be more specific about whatever that flag was representing, such that you have to decompose it. So, maybe you stop storing that boolean altogether and just return a simple test based on the other values.



  • @boomzilla said:

    Yeah, that was mostly directed at too_many_usernames,
    @boomzilla said:
    I'm not even going to try, because I wasn't talking to you. I can see how you might have taken offense, though, and would advise you to look at the tags more closely.

    Ok.  I saw the trolling tag but missed how it was being applied.  Apologies.



  • @boomzilla said:

    Yeah, that was mostly directed at too_many_usernames, who appeared to possibly be a .Net person, who was worried about "[wrecking] the semantic distinction between a simple data primitive and a parameter with semantics." Which is kinda the point of abstraction.

    I've been called many things in my day, but never a .Net programmer (never wrote a line of code in it, actually).

    What I was meaning was more in line with what Morbs is saying: what kind of problem statements do people envision where there is a meaningful reason to convert something that was a simple scalar into something that would later require semantics.

    Also, I'm not sure I understand the benefit of hiding the semantics associated with a complex data store behind something that looks like a simple variable. If it's a cache or something like sparse data, why would you hide the "current" value in something that looks like a variable when it's not really a variable?

    While I fully understand the point of encapsulation, I don't understand the concept of being able to make a non-deterministic function look like a variable.



  •  Well, one use of them is in Interfaces, as you can't specify member variables in interface declarations.  



  • @too_many_usernames said:

    While I fully understand the point of encapsulation, I don't understand the concept of being able to make a non-deterministic function look like a variable.

    I think you've got it backwards. You're simply telling the world that some sort of information is available for the asking. The world doesn't have to worry it's little head about how the information is stored.



  • @DescentJS said:

     Well, one use of them is in Interfaces, as you can't specify member variables in interface declarations.  

    Yes, but I said nothing about interfaces. And I rarely encounter well-designed interfaces that manage a bunch of simple values, which is what we're talking about here; using get/set methods for every single value. Once again, I never said all variables should be public.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.