2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- October 14, 2015
- Bits and Pieces
What’s a private method, why use them? Their purpose is to hide implementation details, the way we accomplish a task. We generally don’t want to share these details so we limit its scope and who can call it.
Use private methods to share common implementations so a service can have different APIs for different client’s needs. But also use private methods whenever there’s any bit of functionality that you can name but don’t need to expose to the outside.
When I mark something as private I’m saying the world doesn’t need to know or care. I’m telling other developers they don’t have to worry about what’s inside. Of course, private methods don’t bloat an object’s interface and can provide an extra measure of security as private methods can’t be called from outside the object that contains it. Keep as much as you can private and only expose what is required to use your service.
Try not to expose implementation details so that you’re free to change them later without impacting the system. Do this by following the advice from the Gang of Four (GoF): design to interfaces, prefer aggregation, and encapsulate variation.
Offer your services through an interface based on the callers’ needs then adapt it. Present what you want, not how to get it. Code to abstractions rather than concrete classes. As you do these things, classes get defined responsibilities and the domain model remains crisp.
But don’t tell me how you’ll do something, don’t even imply it. That forces you to commit to a particular implementation. Keep those details private instead.
How do you test private methods? The short answer is you don’t, at least not directly. If you can exercise the behavior of a private method by calling its public interface then your private method will have code coverage and you can consider it tested. If you feel that the private method does so much that it really needs its own test then it probably shouldn’t be private. In those cases, you can put the behavior in a public method in its own class that’s held privately. This gives you testability and potential reusability of the behavior without bloating the interface of the client.
Previous Post: « The REAL Difference between Agile and Waterfall Development
Next Post: Is Priority Best for Ordering a Backlog? »