|
Someone's stalking your ideas[^] in the forums.
This space for rent
|
|
|
|
|
|
If the method does something that is useful to an external consumer, leaves the class in a fully consistent state (i.e. it doesn't only do part of the work), and doesn't expose implementation details that are likely to change, I'm a fan of public.
Otherwise, if it's possible that I may want to later derive from the class and it doesn't expose implementation details that are likely to change, I consider protected (especially if there are also some virtual methods present).
For everything else, I'm a fan of private.
I seldom use internal. I use it only when I can't find an alternative. In the rare circumstance I do use it, I also very carefully re-consider how I've modeled the object. Its "necessity" is often a red flag for a poorly modeled object.
|
|
|
|
|
My 2c:
Even if I don't implement an interface to a class, I think about what the interface would specify. This guides me on what methods should be public.
I hardly ever use private, preferring protected if for some reason that class would need a derived implementation. The only exception is if I would never want a derived class to call the base class' method.
Ideally, I really dislike properties / fields. Properties == state, and stateful data is one of the major sources of bugs and adds complexity to testing. I prefer to pass everything that a method needs into the method and have it return everything that the caller needs. But this is an ideal to which I frequently fail.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I think keeping an interface perspective on Public is the right approach. But I differ on: Quote: Ideally, I really dislike properties / fields. Properties == state
I do see Fields as state, and (more then dislike) think public fields are pure evil  . So by extension public int Foo {get; set;} supports your view on Properties. I view Properties (setters specifically) more as requests for "conditions" (i.e., a collection of states) => "put yourself in this condition". I see methods as requests for actions => "do this thing", (your condition becomes a side effect). So I don't think it is the tool (Property) that has issues - directly changing state, either through Property or Method, raises flags - the problem is the idea of directly changing individual state parameters. Like you said, Quote: pass everything that a method needs into the method and have it return everything that the caller needs
Though if the intent of the method is to change the condition of an object only (with void return), expressing that as a Property can, IMHO, add additional context to your intent.
I think the common 1:1 use of properties and fields has tainted the real value of properties, and obscured that they are really just another method syntax. Great Threads article BTW.
|
|
|
|
|
When I first leaned OO (early 80's), the general school of thought was behavior before structure. It was almost a functional approach, in that you defined a small set of public "action" methods that essentially defined the object. Exposing data (including using simple set;set;) was generally frowned on. Data belonged in structures. Back then though, Structures were basically classes without methods. The idea was that data represents state, and you should only change state through actions, not directly. These days things are different (e.g., in many languages Structures can have methods, and the difference is usually stack v heap), and we have been living in a Data-Driven world, so for many, classes have become collections of data properties (e.g., Models).
I still keep the structure v behavior mindset, and generally (though not formally) divide my classes into those camps. If a class is structural, it will have a lot of public stuff, so you can easily manipulate the structure. If it is behavioral, only the actions that define it through its capabilities are public. Think of a Stoplight class. It has three (bool) lights - Red, Yellow, and Green. A "public" data-driven mindset might expose these as three public properties. A user could turn on Red and Green at the same time though. You make the user do more work to use your class. A behavioral mindset would expose a single public property (or method). light.Flow = GO, light.Flow = Stop. (Ignoring things like flashing Yellow). The Yellow state between Go and Stop is internal, and not exposed directly, but through a protected/internal "yellowDuration" accessor. Extend this to an intersection. It could encapsulate four stoplights, and expose a single public property - Allow: Allow = Direction.NorthSouth, Allow = Direction.EastWest, Allow = Direction.None. By inspecting the public methods/properties, it is clear what this does. It makes the class easy to use, and it protects conditions. A "public" mindset might expose 12 individual lights on Intersection - is it clear what this class does by inspecting the public properties? What is the value of exposing everything (YAGNI). And what prevents (without extra coding) all lights being Green?
Utility classes are a another thing all together. They are less classes than collections of methods. (i.e., they have no self-identity).
Encapsulation and data-hiding are a core foundation of OO concepts. Public/Private are key to both. If you want to make everything public, why not just make everything static global while you are at it?
|
|
|
|
|
Suppose you had a class containing a public member email. If that member were assigned a bogus value someplace, and then that value was read/used someplace else, a problem would surface. In this instance, your class should be in charge of its members: make email private, and use getter/setter methods. In your setter method, the email address could be validated, and rejected if found to be incorrect. The places that then call the getter method would not have to worry about bogus email addresses.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
If they have access to the code, then make them private. This gives that object better encapsulation, allowing it to more easily be extended, refactored or completely rewritten without affecting the rest of the code. Your coworkers can always increase the interface to the object by making them public if they need to, but more likely they will consider exactly what access is actually needed instead of just making internal implementation public.
|
|
|
|
|
The down side to having a lot of members public is that not only do the users have those buttons and knobs to turn, they may think they have to. Every public member is a decision for the user: do I have to set this, or does it default? Is the default what I want? When do I have to set it?
You need to decide if your typical use case needs the flexibility. If it doesn't, then I'd argue that those members should be private.
Software Zen: delete this;
|
|
|
|
|
It's all about compression.
Private members are zipped, and public members are unzipped.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Kidney stone used to study continuous change (8)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Calculus!
[EDIT]
Kidney stones calculi =>
Kidney stone calculus
study continuous change calculus
Google? What! Who? Me?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Quick and correct, just what we like to see.
You are up tomorrow! 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
CLUELESS - Not an answer, just me with this again. 
|
|
|
|
|
It's a fairly simple one really - honest!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options.
I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice.
It's about DTO, constructors with zillion of parameters and all private properties.
code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
public class FooDto
{
public T1 Property1 { get; set; }
public T24 Property24 { get; set; }
}
class MyFooClass
{
private T1 property1;
private T24 property24;
public FooDto ToDto()
{
return new FooDto()
{
Property1 = property1,
Property24 = property24,
};
}
}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 , T24 value24)
{
Property1 = value1;
Property24 = value24;
}
public T1 Property1 { get; }
public T24 Property24 { get; }
}
class MyFooClass
{
private T1 property1;
private T24 property24;
public FooDto ToDto()
{
return new FooDto(property1 , property24);
}
}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values.
Though one could counter argument that we got unit test for just that.
At any rate, which of those 2 is your favourite code style?
|
|
|
|
|
Option 1, but I do see the argument for option 2, especially if the properties are mandatory.
|
|
|
|
|
Of course, using reasonable defaults would prevent you from having runaway parameter lists for your constructors, and all you have to do is set the properties that need to be changed.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
To be honest I'd probably have a separate mapper to do the conversion, but of the 2 I'd go 1, once you're over a handful of parameters in a constructor it gets messy.
|
|
|
|
|
When a method has more than, say, four arguments, I strongly dislike it, its author, and the Italian governement.
|
|
|
|
|
CPallini wrote: dislike ... the Italian governement.
I thought that was mandatory in Italy, regardless.
|
|
|
|
|
|
I would go for option 1.
I would also look at having some sort of mapping functionality so that the values can be populated 'automatically' by passing the DTO to some form of orchestrator together with the data source to populate it.
The following in option 2 is a huge code smell:
public FooDto(T1 value1 , T24 value24)
I have done this myself in the past but it is generally accepted nowadays that a large number of parameters in a signature is a bad idea.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 30-Oct-18 4:35am.
|
|
|
|
|
I fail to see what the big deal is about, but if I get to choose I prefer 1.
I don't like huge constructors, they are slightly more error prone.
|
|
|
|
|
Option 1 because it is cleaner, more understandable and more extensible of the two options.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
