5 ms·

Java doesn't require you to define getFoo() and setFoo(). Some best practice advice suggests you do. But you can leave the vars public and just use the . oper

by dhimes 16y ago

Java doesn't require you to define getFoo() and setFoo(). Some best practice advice suggests you do. But you can leave the vars public and just use the . operator, if you choose. It seems like Java wasn't defined in order to be an efficient for a three-person shop to hack in. It was meant to be efficient for a 40 person shop to build code as a team that they can maintain. That said, I dread going back to my Java projects and updating them, even though I tried to maintain best practices in order that updating be as simple as possible. I've been immersed in php and javascript lately, so we'll see what it's like to go back.

dfox 16y ago
Java certainly was not designed to be this "enterprise language" it is now. It only was similar enough to Smalltalk to replace it. (and Smalltalk has this culture of "if it is repetitive then extend IDE to automate it", which to some extent influenced Java IDEs)
- dhimes 16y ago
  My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it. I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off. On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful. You are correct about the IDE thing. That does ease a large burden in Java.
  - sanderjd 16y ago
    Interesting about objects in javascript. I have actually started feeling that prototype-based object orientation is less tacked on than its class-based cousin. The syntactical implementation is a bit strange (the 'function' keyword for objects, putting functions on the prototype object rather than the object itself), but the mechanism itself seems more generic and flexible. The implementation in Io is better I think, you should check that out before discounting prototype-based object systems outright.
    - dhimes 16y ago
      Oh, I won't discount them (I'm not good enough to be a prima-donna about it), and it's nice to know that I will see how to use it to my advantage as I play with it more.
  - brunoc 16y ago
    >> feel like I'm evolving my own design patterns I think that this is happening to many people who are doing a lot of 'non-trivial' JavaScript. The language is still very young and because the concepts that were chosen when creating the language are powerful and flexible (prototypal inheritance, objects can be accessed like hashes, first-class functions etc) there's always a million ways to code something. OO-wise i think you can divide into those who use the `new` keyword and build objects that are more or less Java-like classes and those who create objects and prototypes on the fly, and probably use a lot more ideas from the functional and LISPy side of things.
    - dhimes 16y ago
      I have somehow settled into the pattern of using new/java-like classes for large objects that store a logical set of data and need to operate on it, and on-the-fly prototypes to groups group just data (or, perhaps, a trivial operation). My worst crime by far (that I am aware of) is that I have no hesitation to use a global variable if it saves me from bending over backwards to get around it. I'm doing animations, and sometimes the algorithm just comes to me a lot faster if I let a var keep a global value and be used by lots of functions between calls to my animate() function (using window.setInterval() ).
donaq 16y ago
Urgh, I learned Java in school and recently had to use Java at work to do some stuff with a bad XML schema (think lots of "<parent><child><grandchild_1 /><grandchild_2 /><grandchild_3 /></child></parent>" wtf is element "child" for??). I used XStream for it, and started off trying to write the objects the "right" way, i.e. with private members for child nodes and getters and setters for them. However, having drank deep of the Python well, I got about 20 minutes into it before I realised that my time was better spent writing the actual logic of the app and did a :s/private/public/g. The pain from my ulcer faded almost immediately. :) *I realise that pro Java coders use Eclipse to generate their getters and setters, but I have also drank deeply of the vim kool-aid and find myself going to ridiculous lengths sometimes to avoid other editors or IDEs. I keep trying to navigate with the wrong keys and trying to save with :w and using :sp to open other files when I use them.
- dhimes 16y ago
  One thing to look out for here is this: if you are writing getters and setters for primitive data types like strings and ints and stuff you're doing it wrong. Instead of public Customer(String name, int custId) do public Customer(CustomerData cd) where CustomerData is an object. In Customer you would have getters and setters for CustomerData rather than each item that identifies your customer. This is for extensibility: As your app grows, some part of it may need other ways to identify the customer. Adding these ways won't break your Customer interface. That's the purpose of the rigor of the design standard. Now what I do, which goes against stated policy, is keep the CustomerData variables (String name, int custId, and so on) public so I can set them easily. The only time I require getters and setters for primitive types (for example, name) is if I were to read in data from a user generated form that needed to be sanitized. My apps are full of these customized data objects, and it's a technique which has saved my ass as I added features etc.
  - sqrt17 16y ago
    ouch. If you encapsulate all the data about a customer in a "CustomerData" object, do you really need a separate "Customer" object? Or do you mean, not the whole customer but larger bundles of information like addresses etc. that don't need any business logic or abstraction but are nice to have as one single bunch of data? (I mean, there's a reason why C++ still has "struct"s even though OO zealots will tell you they come from the devil).

by dhimes 16y ago

dfox 16y ago

Java certainly was not designed to be this "enterprise language" it is now. It only was similar enough to Smalltalk to replace it. (and Smalltalk has this culture of "if it is repetitive then extend IDE to automate it", which to some extent influenced Java IDEs)

dhimes 16y ago
My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it. I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off. On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful. You are correct about the IDE thing. That does ease a large burden in Java.
- sanderjd 16y ago
  Interesting about objects in javascript. I have actually started feeling that prototype-based object orientation is less tacked on than its class-based cousin. The syntactical implementation is a bit strange (the 'function' keyword for objects, putting functions on the prototype object rather than the object itself), but the mechanism itself seems more generic and flexible. The implementation in Io is better I think, you should check that out before discounting prototype-based object systems outright.
  - dhimes 16y ago
    Oh, I won't discount them (I'm not good enough to be a prima-donna about it), and it's nice to know that I will see how to use it to my advantage as I play with it more.
- brunoc 16y ago
  >> feel like I'm evolving my own design patterns I think that this is happening to many people who are doing a lot of 'non-trivial' JavaScript. The language is still very young and because the concepts that were chosen when creating the language are powerful and flexible (prototypal inheritance, objects can be accessed like hashes, first-class functions etc) there's always a million ways to code something. OO-wise i think you can divide into those who use the `new` keyword and build objects that are more or less Java-like classes and those who create objects and prototypes on the fly, and probably use a lot more ideas from the functional and LISPy side of things.
  - dhimes 16y ago
    I have somehow settled into the pattern of using new/java-like classes for large objects that store a logical set of data and need to operate on it, and on-the-fly prototypes to groups group just data (or, perhaps, a trivial operation). My worst crime by far (that I am aware of) is that I have no hesitation to use a global variable if it saves me from bending over backwards to get around it. I'm doing animations, and sometimes the algorithm just comes to me a lot faster if I let a var keep a global value and be used by lots of functions between calls to my animate() function (using window.setInterval() ).

donaq 16y ago

Urgh, I learned Java in school and recently had to use Java at work to do some stuff with a bad XML schema (think lots of "<parent><child><grandchild_1 /><grandchild_2 /><grandchild_3 /></child></parent>" wtf is element "child" for??). I used XStream for it, and started off trying to write the objects the "right" way, i.e. with private members for child nodes and getters and setters for them. However, having drank deep of the Python well, I got about 20 minutes into it before I realised that my time was better spent writing the actual logic of the app and did a :s/private/public/g. The pain from my ulcer faded almost immediately. :) *I realise that pro Java coders use Eclipse to generate their getters and setters, but I have also drank deeply of the vim kool-aid and find myself going to ridiculous lengths sometimes to avoid other editors or IDEs. I keep trying to navigate with the wrong keys and trying to save with :w and using :sp to open other files when I use them.

dhimes 16y ago
One thing to look out for here is this: if you are writing getters and setters for primitive data types like strings and ints and stuff you're doing it wrong. Instead of public Customer(String name, int custId) do public Customer(CustomerData cd) where CustomerData is an object. In Customer you would have getters and setters for CustomerData rather than each item that identifies your customer. This is for extensibility: As your app grows, some part of it may need other ways to identify the customer. Adding these ways won't break your Customer interface. That's the purpose of the rigor of the design standard. Now what I do, which goes against stated policy, is keep the CustomerData variables (String name, int custId, and so on) public so I can set them easily. The only time I require getters and setters for primitive types (for example, name) is if I were to read in data from a user generated form that needed to be sanitized. My apps are full of these customized data objects, and it's a technique which has saved my ass as I added features etc.
- sqrt17 16y ago
  ouch. If you encapsulate all the data about a customer in a "CustomerData" object, do you really need a separate "Customer" object? Or do you mean, not the whole customer but larger bundles of information like addresses etc. that don't need any business logic or abstraction but are nice to have as one single bunch of data? (I mean, there's a reason why C++ still has "struct"s even though OO zealots will tell you they come from the devil).