Samstag, 15. Februar 2014

Reorganizing class internals

A lot of code I looked at has the private stuff of a class on top (I'll say private in the following, meaning everything invisible from the outside like protected, internal...). The code starts basically with a section of the member variables, followed by private functions. In many cases then starting to mix public and private members. I dont know if that's really universal, but a lot of my collegues seem to do it that way.
I did, too.
I guess thats something we learned from older languages like Delphi where everything needs to be defined before it can be used; and as the public members will most likely call or use the private ones, the private stuff has to come first. More modern languages like Java and C# do not require that any more, be we stick to old habits. But... Is that good?
I now tend to say NO, because the most important thing of a class is its public interface. So THAT should come first. Private members are just details of the implementantion, and only need to be looked at when you want to find out HOW the class is doing what it's doing. But that's usually interesting after you know WHAT the class is supposed to do (which the public interface should tell).
After a few experiments in smaller projects this actually seems to work for me. Now I'll try to use that in bigger ones.
I'll keep you updated if it keeps working for me.
What do you think?

Keine Kommentare:

Kommentar veröffentlichen