I was taught that an object should know how to do everything with itself. So I've built an application trying to keep fields private and have a lot of methods like these:DisplayGraphically()DisplayAsText()WriteToFile()Apply()Edit() (shows a dialog box to edit it)ErrorCheck()Now I want to save the data to another file format whose structure doesn't closely correspond to my object structure. It would feel easy if all the data was public. Then a single method could collect all the various bits of data from the objects and reorganize it to suit the file format. But this means exposing private fields (through getters). On the other hand, that's what an API would provide and surely doing this job through an API would be quite clean.To sum up, which is better in what cases?Fields are private. Objects have lots of methods to deal with many different uses.Fields have public getters and setters which maintain correct internal state. New functionality that involves many objects can be encapsulated in its own class and doesn't require any modification of the existing code.
Should fields still be private when you need to restructure the data?
object oriented
You need to separate your data objects clearly from other application's classes, following the single responsibility principle. Most of the methods from your example should not belong to your data objects, they should belong to controller classes or other application classes, because the responsibility of your data objects should only be, well, to hold or manage their data, and not to interact with the file system or the user interface. If you start to restructure your application that way, your data objects (and only the data objects) will have most of their fields public accessible already.For example, a method like DisplayAsText() which actually displays your object on screen does clearly not belong into any of your data objects. Instead, a method like ToString() could be part of your data objects, which is called from a method DisplayAsText() beeing part of a completely different class somewhere else in your application. A method like ErrorCheck could call a lot of small validation methods of your data objects telling if some state is right or wrong, and display the error, which means, the small validation methods should be part of your data objects, and ErrorCheck itself clearly not. And a method like Edit() will typically need complete read/write access to every data field of your data objects, so you should already have this available when starting to implement your SaveToNewFormat method.