CODEWITHSUNDEEP
classcoding-stylerefactoringstructurecode-cleanup
Charlie S
Charlie S

Reputation: 4604

Private methods in amongst Public methods

Suffering insomnia at 5am & so reading Clean Code (by Robert Martin). This book is often seen as a Bible for coding structure and so I was interested to see he suggests the 'Newspaper' analogy when it comes to ordering methods/functions within classes. The book suggests you order functions by first public method, then related private methods, then second public method, then related private methods (and so on). So a class structure might look like this:

public func openAccount()  {
    completeNameDetails()
    completeAddressDetails()
}

private func completeNameDetails() {
    ...
}

private func completeAddressDetails() {
    ...
}

public func closeAccount() {
    deleteNameDetails()
    deleteAddressDetails()
}

private func deleteNameDetails() {
    ...
}

private func deleteAddressDetails() {
    ...
}

From hunting stackoverflow this morning, it seems there is strong support for this method:

Best practice: ordering of public/protected/private within the class definition?

The issue I have with this suggestion, however, is the public methods of the class are scattered throughout the class. Would it not be better to have all the public methods at the top of the class and then the privates below it. Certainly this view also has a strong support from this community:

Order of items in classes: Fields, Properties, Constructors, Methods

So in summary, should public methods all be grouped together above private methods or should public methods be followed by their respective private methods (meaning public and private methods are mixed)?

Upvotes: 0

Views: 879

Answers (1)

Marcel De Villiers
Marcel De Villiers

Reputation: 1822

I too have read Clean Code and the value in reading the book is indeed immense. There are however edge cases with which I do not agree. The step down function method as described by Mr Martin is one of them.

Ideally, a class should only have 1 to 3 public methods, otherwise it is very likely doing too much. I prefer my public methods to be grouped together. When you do have very small classes, what Mr Martin suggests can work nicely, but in the realistic software world, you will have classes with more than one or two public methods.

To myself, when I look at a class, the public methods tells me the functionality should I wish to consume them. It is fair that a good IDE will still tell you when consuming, but if I do want to look into the class, it is just easier to read and grog it. Good IDE will let you navigate the lower level private functions easy enough.

Another disagreement I have with clean code is the "I" prefix for interfaces. I prefer my interfaces to be prefixed with an "I". This is however a separate discussion.

The most important takeaway is to be consistent. The strategy that you choose to name matters a lot less as apposed to consistency. If you use different strategies to your team, it will be hard for everyone to understand. As a team, choose a strategy and stick to it.

Upvotes: 3

Related Questions