In OOP coding, there is a long standing naming convention to name accessor/mutator methods getThing and setThing. These directly manipulate the properties, which are often private.

Should these naming conventions be 'reserved' solely for manipulating the object properties? or can they be used in other methods - getFileContents ?

I think readFileContents is much clearer as it implies the objects property in this case isn't being accessed, but rather a files contents are being read. However, it is a little ambiguous in that it doesn't imply the results are being returned like getFileContents would.

closed as primarily opinion-based by ratchet freak, gnat, Thomas Owens Jul 15 '15 at 16:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I would point out that many tools and frameworks in the Java world expect the Java Beans specification. If you aren't interacting with those or passing the information to/from them as a Java Bean, then its probably a non-issue. However, this is a convention for one segment of the OOP world. – user40980 Jul 15 '15 at 14:06

Naming conventions are simply suggestions. There are no set rules for anything.

The only guideline you need to follow is to name your function according to what it does. If your function readFileContents both reads and returns parts of the file, consider splitting it up into two functions, readFileContents and getFileContents, for example. readFileContents can peruse the file for interesting data and then send it to getFileContents when it wishes to return something. This will separate the concerns so that each function is only doing one thing.

  • So in this case, readFileContents could save something to the fileContents property and then you would use the getFileContents function to access it? – myol Jul 15 '15 at 14:23
  • 1
    Right. That separates the concerns so if you have a problem with reading or writing, they are in two separate functions. – Lawrence Aiello Jul 15 '15 at 14:27

As opposite examples, in Objective-C or Swift you won't see any setThing anymore, and there never was a getThing. In modern use, you have properties in Objective-C and variables in Swift, which are used exactly as if they were plain old member variables that you can read and write. What's going on behind the scenes is then something entirely different. Your getter and setter may just read or write a value, it might do lazy evaluation, it can get notifications just before and just after a setter is called, it can implement getter, setter or both in code. The user of a class sees nothing but a variable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.