|
It wouldn't suit him.
He doesn't look good in stockings.
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!
|
|
|
|
|
No, no, no - if you are going sexy - go sexy and triggering with The Sexy Hand Maids Tale costume
(Although Bob probably can't pull this off too well.)
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
Amazing, all this fuss about a little red dress, hard to believe we are living in the 21st century 
|
|
|
|
|
There are quite a few things that were better in the 'good old days', but I wish wish wish wish that the idea of hot slutty costumes for Halloween, an enormous cultural leap forward, had been around when I could have better taken . . .
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I read the thread - didn't have anything to add . . . until . . . until . . .
. . . I realized you never explained how you knew it was Bob. ????
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The Eye's dude, its all in the eyes, or so I am told...
|
|
|
|
|
Because he's got a sheety job?
(Runs away without coat, too damn hot!)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
As I am starting working again on my home project... I sometimes review and rewrite some old class I use. The general theme of most of my rewrite, if not all, is less. Less lines of code, less methods, less parameters....
Now I put that in perspective with how I like to write code and how it impact my coworkers. I like to make as many members of my classes as public.
Why not? That gives everyone more control over my objects at no cost...
But, on the other hand, make my object more complicated to use, I now realise. What are all those public members for, they might wonder? While staring at an object they might need to use...
While, if I make as many members as possible private, that make my object artificial contrived to used (to my eyes at least) but also excessively simple (look this object only has 1 method and 2 readonly properties!)
Remark this post has been brought to you by: Work colleagues complaining about all my public methods and properties. Make them private they say.
What are your thoughts on the topic?
[EDIT] Thanks to your feedback, I found out it's a matter of context
I am too much used to write reusable utility control and library... what the point of a reusable class, say DateTime, if all members are private?
But hey if I am writing things like a MVC Controller, or the DoSomethingFormClass, or DoSomethinService, everything can be private there for all I care. And from now on I should make everything private there by default, so there would be no pointless arguing...
I think I might even go one further and do private utility classes 
modified 30-Oct-18 7:42am.
|
|
|
|
|
Everything that is not called from the outside should be private. Ie, as much possible.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I create a set of simple methods with default behavior but also provide methods that allow greater detail.
I may not be that good looking, or athletic, or funny, or talented, or smart
I forgot where I was going with this but I do know I love bacon!
|
|
|
|
|
To be honest, I've never seen the point of fully private properties : private setters, or private getters yes. But if the property is visible inside the class only, why have it at all - just use a private field instead since the accessibility is the same and you save a bunch of getter and setter calls ...
public /
protected / ... properties protect your fields while making your classes more "generic", more "reusable", more "flexible" to my mind.
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!
|
|
|
|
|
I like private properties for event triggers, and I use them more often than I generally initially expect to.
That said, I pretty much never use a private modifier outside of a sealed class 
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Quote: Now I put that in perspective with how I like to write code and how it impact my coworkers. I like to make as many members of my classes as public.
Why not?
Public interface is (or at least should be) forever. Like old fashioned marriages, you can't break the contract. There are sane OOP principles against making all class members public.
|
|
|
|
|
I guess I am too much used to write reusable utility control and library... what the point of a reusable class, say DateTime, if all members are private?
But if you are writing things like a MVC Controller, or the DoSomethingFormClass, everything can be private for all I care. And most importantly I think it is useless to argue about it so I will just make everything private to avoid wasting time arguing...
|
|
|
|
|
Quote: what the point of a reusable any class, say DateTime, if all members are private?
I fully agree. 
But that's not the point.
|
|
|
|
|
yeah, I only read your post distractedly...
To fully answer your post, I only make public what I think is an here to stay method / property of the thing...
But anyhow, I (just) realised this argument really boils down to the difference between reusable utility/control/whatever and service/task-thing/web-controller-thing
I will maintain that reusable utility member should be as public as reasonable...
But now I will use the opposite logic for service/task-thing/web-controller-thing were everything will be as private as possible...
|
|
|
|
|
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;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
