CODEWITHSUNDEEP
c#.netcoding-style
Brans Ds
Brans Ds

Reputation: 4117

When should we use public and when private?

Should the Access Modifier be Public or Private when we are implementing method that is for now not using by other classes in our team solution? I believe that "A public member says this member represents the key, documented functionality provided by this object.". We make private only "implementation details" methods and all methods that can be useful in future we should make public even for now there is no consumers of our methods in others classes. But my opponent says that such methods should be private. How do you think?

Added: Let's be more specific. For example there is a class SqlHelper. In it there is useful functionality for operation with the SQL Server. In particular there is used connection to the SQL server. But not only in that class.

And for example I need to implement the public static HandleSqlExeption method(now only for class SqlHelper) which will process SqlExeptions. But I want that in all classes where there is operations with SQL connection in exception handling will be used this method (instead of it is simple, for example: catch (Exception) { MsgBox {"SqlError"}; as somewhere happens now. So i consider that public access modifier will say to other colleagues that they can use this method. And private will hide that method. And i will need ti change code and rebuid assembly if some one will ask to use tsuch method. Why? There is only negatives.

Upvotes: 1

Views: 1878

Answers (5)

David Schwartz
David Schwartz

Reputation: 182753

This is a judgment call. Generally speaking, if it's logically a part of the interface the class is presenting to get the functionality it provides, it should be public even if it has no current users. That will reduce the chances that the class will need to be modified every time you want to use it for substantially the same things you're already using it for.

However, this has a cost. Each function you expose is a capability you are committing to provide. If, in the future, you decide to remove it from the public interface, you may break callers.

For example, consider a map class. Say you currently don't have any callers that need to know the number of items in the map, and your current implementation has a size variable you could easily return. You could add a getSize function that returns the size of the map. It's logically part of the function the map class exposes. So one can argue it should be public even if no current callers need to know the size.

However, it's entirely possible a future implementation might wish to get rid of the size variable. Perhaps the overhead of incrementing and decrementing the size is significant and implementation is changed to not need to know the size. If you exposed getSize function and it was called, you would either have to keep tracking the size even though you didn't need it or make the function very expensive, having to actually count the size.

Say lots of code needs to know if the table is empty and you provide an isEmpty function for this purpose. Experience shows that if you also provide a getCount function, people will do getCount() == 0 instead of isEmpty. That may not make any difference today, but it may constrain your future implementation choices to keep getCount as cheap as isEmpty.

Where possible, I would strongly suggest making it public if you can easily imagine a non-broken user of the class that would benefit from having access to that functionality and it forms a logical part of the functionality the class provides. Otherwise, you can easily add it later anyway. So don't stress over it too much. It is largely a style issue mixed with trying to predict the future.

Upvotes: 1

Oded
Oded

Reputation: 498942

In general, you should code using the least possible permissive access modifier.

  • If the method is not used outside the class, make it private.
  • If the method needs to be used by inheriting types, make it protected.
  • If the method will only be used within the assembly, make it internal.
  • Only if the method is to be used outside the assembly should it be public.

This helps with information hiding and lets you change the implementation at will.

I have heard this described as protecting your privates.

In terms of API design, you should have a complete API, exposing all logical functionality as public - this is why you should use interfaces in .NET for API design, as all interface members must be public. In implementing classes, use the above rules of thumb for any members that are not part of the interface - unless they form a logical part of the interface, as far as its consumers are concerned.

So, if you have a Read method being used today, you should have a complementary Write method that has the same accessibility. That's a good design (symmetric and expected), but how you read or write should be hidden behind private methods, if the public ones use them.

Upvotes: 11

D J
D J

Reputation: 7028

if a class has some thing to expose to outside world then make it public else private. it depends on the functionality and purpose of class not the current or future requirement.

Upvotes: 1

Matt
Matt

Reputation: 1678

A basic principle of object oriented development; an instance of a class should only expose what needs to be accessed by it's clients. See link and search for "encapsulation".

Upvotes: 0

sr01853
sr01853

Reputation: 6121

Use public and private depending on the nature of the method as name describes.

public when the method can be exposed to other objects and

private when the method should not be accessed by other objects.

If your object needs to be more secure, use private access specifier. You should also know about protected access specifier which is different in that, those methods can be accessed only by the objects that inherit them.

Upvotes: 1

Related Questions