text:
Submission process
Write. Words are powerful. Use up to 800 and no less than 400. Please note: Longer submissions in excess of 200 words will be edited for brevity; anything longer than that will be sent back to you for a revision. If you are submitting a video post, please provide us with a short introduction to the video that is up to 200 and no less than 100 words.
Submit. Fill out our simple submission form and click the submit button. Whew! You're done with the hard part!
Connect. You'll hear from us within 24 hours acknowledging that we've got your submission.
Get edits. Your story will be reviewed by our staff within a week, sometimes more depending on the number of submissions we are dealing with. (See basic guidelines below.) They will do one of three things: 1) Accept it. 2) Reject it if it is in violation of our terms and mission. 3) Send it back to you with suggested tweaks to either keep it in compliance with the rules or to help you connect with and empower our community.
Go live. Once your story has been accepted, it will be queued for posting. Depending on how many stories have been submitted, it may be a couple of weeks before you see it. Don't worry! We will let you know as soon as it goes live so that you can tell your friends and share it on social media.
Join us. You're now part of our tribe—with access to the private FB group and a special welcome gift.
Wf1 guidelines
Your submission can be about anything you've been through, seen, done, or learned from. It can be cathartic and deep, something you never dared share before. Or it can be what you learned from eating granola with Grandma. From the utterly f'd up to the totally mundane, we want your story. That said:
We publish personal stories, not promotional pieces. However, we offer our community members the chance to share the stuff they're up to via special sponsored posts to be featured on our homepage. Click here to learn more about sponsored posts.
Keep it PG-13! We don't accept stories with obscene sexual content, or intolerant or hateful speech.
Keep it religiously neutral and respectful. We do not, nor will we ever, represent or promote a single religion out of respect for the world's diversity. We have nothing against religion, but we are also not the forum for praise and worship.
Even though we would much prefer that your writing for Wf1 be original, you may submit previously published work—if the website allows it—but please include all appropriate credits and links back to the original site.
If you include images, you must have permissions or the rights to use them.
We use the Oxford, or serial, comma. That means we use commas here, here, and follow with a period. We also follow Chicago style, for anyone who, like our editor, spends lots of time thinking about those kinds of things.
If you are interested in a few writing and editing tips, we have created a guide that you can download here.
Don't use other people's work. If you quote someone, attribute it. If you use someone's photo(s), give them credit. It's the nice thing to do, and it's also the legal thing to do.
Be inclusive and open-minded. Remember that our community is beautifully diverse. Not everyone has the same rules and values that you do, but that doesn't make them wrong.
Please remember that although we publish hundreds of stories a year, Wf1 staff is tiny and we wear a lot of hats. We have one editor who, when she isn't busy creating content with the team, is pouring lots of time and attention into making our community's stories pop with awesomeness and truth. That said, be patient and respectful. We do our best to respond to all emails and concerns about your story, but our time is limited.
Now that you've read through this, click here to share your story.


text:
This Sunday's Once Upon a Time has two provocative story threads to pick up — and we've got a sneak peek from each.
RELATED | May Sweeps Scorecard: Deaths, Weddings, Births, Sex, Resurrections, Firings and More!
In "Welcome to Storybrooke," as the episode title suggests, the ABC drama will flash back to 1983, just as the Evil Queen's Dark Curse plucked scores of fairytale land VIPs out of the Enchanted Forest to populate a sleepy town in Maine. In this first clip, we see Regina seemingly "test" Snow White (now known as mild-mannered schoolmarm Mary Margaret) to see what, if anything, she remembers — in part by gauging her reaction to a certain "John Doe" in the hospital.
PHOTOS | Once Upon a Time: Storybrooke's First Days Bring Romance and a Mystery Visitor
In the present day, meanwhile, Regina vows to make Mary Margaret pay — with her life — for her role in Cora's death. Rumplestilstkin thus visits the Charmings to share that grim news, to which David has a pretty spot-on retort à la You owe us, imp!
RELATED | Once Upon a Time Post Mortem: Who Has Cora's Death Changed 'Forever'? And Lots More Burning Questions Answered
Want more scoop on Once Upon a Time, or any other show? Email email@example.com and your question may be answered via Matt's Inside Line.

subset: commoncrawl


text:
We are committed to offering you the best traditional medicine has to offer with an integrative medicine approach. Make us one of the first stops in your healthcare.
Traditional medicine uses many tools to treat a wide variety of conditions.
Drum Acupuncture
Welcome to Drum Acupuncture. We value the trust you put in us. Let us help empower you to your best health!


text:
Kim: Kris Humphries Finally Understands What It Means To Be A Kardashian!
Kim Kardashian says her husband Kris Humphries is realizing her life isn't just glitz and glamour — she's working 24/7!
Kim Kardashian may be famous simply for being pretty and…famous, but her life isn't always a walk in the park (or on the red carpet). Now the 30-year-old reality star says her new husband, Kris Humphries, is just coming to the realization how hard she actually works!
On Ryan Seacrest's radio show on 102.7 KIIS FM Oct. 7, Kim dished about life as a newlywed and said there hasn't been a dull moment yet.
"It's been work non-stop!" she admitted. "I think [Kris] appreciates all the hard work that we do, while I run off here to go and do this and there is so much going on, that I think he finally gets it. He is like, 'Wow, they are busy non stop!'"
She also said she has no clue where they are going to end up settling down, since Kris, 25, isn't sure for what NBA team he'll be playing.
"I think we want to figure out where he is going to play and where we are going to live, we haven't even thought of any of that…" Kim explained. "We are staying in New York right now and when we are done…I travel a little bit for work and then when I get back we are going to figure it out. Hopefully the lockout will be done and we will know where he is playing, but I really have no idea where we are going to live."
She added, "So I would say a year, give us a year!"
Kim even said she'd move to a state like Oklahoma if that's where Kris gets drafted. Just like her sister Khloe, she wants to stick close to her man.
Kim and Kris' "fairy tale" wedding airs this Sunday on E!. Do YOU think Kim and Kris's marriage will last? Sound off below!


text:
A part of Joel on Software
The Design of Software (CLOSED)
A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.
The archives will remain online indefinitely.
Dear Amateur Programmers,
It is wonderful to see so many people playing in the field of software development. An English teacher once remarked that people should only be allowed to use three exclamation marks in their entire life. I am about to use my second in the following request ...
You know who you are; you write (Java) code like this:
public class Person {
// A class-scope variable.
private int age;
public Person( int age ) {
// Directly modifying the class-scope variable:
this.age = age;
public void print() {
// Directly using the class-scope variable:
System.out.println( "My age = " + age );
public void birthday() {
// Direct usage and modification:
I beg you to stop writing code like the above, and to smack it down wherever it roams. Especially if written by so-called senior (or professional) software developers and engineers. It is not correct. It is not good. It leads to bug-ridden, brittle, unmaintainable, spaghetti-esque software.
Always use accessors. Always. Always. Always. Like this:
public class Person {
private int age;
public Person( int age ) {
setAge( age );
public void print() {
System.out.println( "My age = " + getAge() );
public void birthday() {
setAge( getAge() + 1 );
private int getAge() {
return this.age;
private void setAge( int age ) {
this.age = age;
When you consistently use accessors source code gains the following advantages:
1. Can place a breakpoint (or debug statement) in the set method. This tells you exactly when the value changes, and to what value the variable is being changed.
2. Can constrain the variable to specific values. Since the value is being set in a single location throughout the entire class, you can place limits on acceptable values.
3. Lazy initialization (which can significantly improve application start-up time). For example:
public class LazyInitializationExample {
private Object lazyInit;
public Object getLazyInit() {
if( this.lazyInit == null ) {
this.lazyInit = createLazyInit();
return this.lazyInit;
// This allows subclasses to return a different subclass
// of Object. Very powerful mechanism. Thank me later.
protected Object createLazyInit() {
return new Object();
4. It reduces coupling between sub-classes and super-classes. When subclasses access inherited variables through accessors, the underlying implementation of those variables can change without adversely affecting its subclasses. This helps eliminate the problem where a change in the superclass causes an undesired ripple effect throughout subclasses.
I don't really understand this point, either, but trust me that it's a good thing. ;-)
5. Like adding constraints, you can: add validation code, assert for specific values, readily apply unit testing, and so forth.
6. Can add undo and redo functionality. Since the only place the value changes sits in a single location, its easy to track those changes in a history.
7. Reap the rewards of Aspect Oriented Programming (accessors as insertion points).
8. Encapsulation. If the business rules for a variable change, you can update the accessors to provide the same capability as before the change, making it easier for you to respond to the new business rules.
See also: http://www.ibm.com/developerworks/java/library/ws-tip-why.html
Regarding optimization:
(1) Let the compiler do it.
(2) Modern compilers might inline the accessor call.
(3) Modern Just-In-Time compilers will inline the call.
(4) Run a profiler to find your bottlenecks.
(5) Research optimization techniques that do not involve eliminating accessor methods.
Dave Jarvis
Thursday, April 10, 2008
Thursday, April 10, 2008
Can't say I agree with you, Dave. Does that make me an amateur programmer? :-)
Your explanation is good but it reeks of "consistency over everything else". Better simply to acknowledge that this a topic debated by many very experienced Java programmers without agreement.
Steve McLeod
Thursday, April 10, 2008
I heartily disagree with this entire thesis. Not for reasons of performance, but for the reason that simple code is easier to maintain. It is simply easier to use this.x than getX() accessor for simple variables.
This is not difficult to change later. If we want to add variable constraints, lazy initialization, validation, undo/redo functionality, or AOP accessor hooks, we can always change the accesses to getters and setters, at that point. Since the class variables are of course private, the only code that has access to them is in that class, so it will be easy to change it to use accessors. That is the idea behind private variable accessibility. There is no reason to add this functionality before it is necessary, since it usually doesn't need to be added. Once again, this is encapsulation at the class level, rather than at the variable level.
As to setting breakpoints, modern IDEs can set breakpoints at variable and field access.
Reducing coupling. If you don't understand this point, I certainly don't ;-). A private field isn't accessible to subclasses, so presumably the coupling is already reduced.
In short, I don't see the need to continue to advocate using getters and setters on private fields. This is part of the reason Java code ends up as cumbersome and hard to work with.
getters and setters on non externally visible stuff is just codebloat.
And frankly, I'm starting to think that getters and setters and anything is a waste of effort -- if you later on need to impose constraints you can usually do it by dropping proxies in to replace the actual variables.
Classes end up being one of two types; a data storage system (in which case everything ends up playing with the members anyway -- so it might as well have them public) or an actual entity, in which case it's going to have a teeny number of clearly responsibilities and all the members are internal.
In the latter case, faffing with getters and setters is just going to make the verbs more obfuscated.
Katie Lucas
Thursday, April 10, 2008
I am a big fan of best practices, but I'm going to have to disagree with you on this one. It's not that the individual points you mention are wrong but rather that I am not aware of any best practice that is meant to be applied blindly. You're supposed to use your judgment to decide whether they're appropriate for your specific case and there are always exceptions to the rule.
A similar best practice that becomes harmful when applied excessively is "comment your code" :)
Applying best practices blindly leads to chronic over-engineering. Specifically, many Java programmers have been blamed for using Design Patterns or building frameworks for use-cases did not actually warrant it (just for the sake of trying them out). Einstein said it best: "Make everything as simple as possible, but not simpler"
I believe the book Refactoring by Martin Fowler actually strikes a perfect balance in this regard. To paraphrase: "Design software as simple as possible and refactor as new requirements warrant added complexity." There is a cost to any design paradigm (not necessarily performance-wise) and you should avoid paying it as long as humanly possible.
That's the general answer. On a more specific level I would say the following:
1) You should abstract access to class fields the user needs to access. Think long and hard whether the user really needs to access them :) If you're designing a library you can add these methods on-demand as use-cases warrant them.
2) Abstracting access to class fields does not necessarily mean using accessors/mutators. On a certain level these actually defeat class encapsulation.
Ideally you want to introduce use-case driven methods instead of exposing the data directly. For example, if you're designing a car navigation system, you would prefer "car.eta(destination)" to "car.getSpeed()", "car.getLocation()" and calculating the ETA externally. The former lets you modify the underlying data far more easily and leads to code which is easier to read.
4) This ties in to an excellent saying by Joshua Bloch: "When in doubt, leave it out".
You should minimize the amount "conceptual weight" you introduce into your designs.
PS: I believe points 4 and 8, 2 and 5 amount to the same thing.
Thursday, April 10, 2008
I confess this is one practice I've never quite seen the payoff from.
Thursday, April 10, 2008
+1 for Avi.
I like my code simple as long as possible. The use of accessors is certainly not stupid, but I would do it when it has become necessary.
A nice alternative is provided by Ada, where one can redefine the assignment routine. This provides the tight control of accessors and the simplicity of direct access. Ada was an improvement over later languages 8-).
Karel Thönissen
Thursday, April 10, 2008
>> It is wonderful to see so many people playing in the field of software development. <<
I am glad that you also enjoy playing in this field. As you grow and mature, you will learn that there is no such thing as a "best practice" independent of context.
You will also learn that discussing your technical biases with the Internet is a very peculiar form of masochism.
You ever notice how someone new to patterns over uses them ... everything has to match one and you end up with ugly cases where they're crammed into odd corners of the program.
This post looks like the textbook description of why encapsulation is good (which I agree with), but encapsulation at the class level is "good enough" in every case I've ever seen.
In any case, your one valid point is that it's useful to have the debugger stop when a variable changes ... that's called a watchpoint and is available in any modern debugger. Even an amateur should know that;)
Leave optimization to the compiler?
Cop out.
Things go wrong with compiler optimization. Stealthily. And when you realize something's broken, the only solution is... turn off compiler optimization!
And I'll use as many exclamation points as I feel are called for, whenever I feel they're called for.
The hallmark of a seasoned professional is he knows the difference between theory and reality. I take best practices under advisement. But I submit to empirical knowledge without question.
Thursday, April 10, 2008
Another point.
If the compiler inlines your assignment method you will have a hard time inserting a breakpoint therein.
Thursday, April 10, 2008
Having a bad day, are we? ;)
A better advice IMHO, is to avoid mutable objects completely. If you need value objects (Such as representations of database records), make them immutable and have "accessors" return a clone instead of altering state. Yes, there is a slight performance overhead, but for most applications it's a drop in the ocean.
I have to agree with everyone else. If this is the biggest worry you have to deal with then you are very lucky indeed. Encapsulation at the class level is enough. You have enough people arguing that getters/setters are a waste of time in general and opt for using public fields instead. Don't give them fuel for their fire by insisting that they use setters for internal class access as well.
Go have a beer and take a rest. You are clearly under too much pressure.
dood mcdoogle
Thursday, April 10, 2008
Dear Dave Jarvis, please give us more posts
about programming "best" practices.
I am going to call this one "Exhibit A".
Object Hater
Thursday, April 10, 2008
I think the OP has misunderstood the idea of accessor methods as a means of enforcing encapsulation. The referenced developerworks article is advocating the use of accessor methods as opposed to direct access to member variables from _other_ classes.
IMO, the important thing from an OO perspective is to ensure that member variables are private and not accessible from subclasses. This ensures that subclasses do not directly access superclass member variables which introduces strong coupling.
Thursday, April 10, 2008
I think what the OP was basically saying amounted to 'if you only change a private field state via an accessor method, you can put a breakpoint on that method and get a break whenever it is accessed and the field value will change'. In which case my answer is, why not just put a watch (or whatever the Eclipse equivalent is) on the variable?
Now if your accessor has a side-effect that you want to take advantage of in private code, then just call the public accessor. Why have unnecessary duplication?
In short - accessors for public use = good, accessors for private use = lard.
There are rare cases when I wish I could mark off a variable,
int x;
...or something like that. This is typically in cases where some sort of pre- or post-processing is critical and you don't even want the *possibility* of direct access. Thus:
setX(int p_x)
if (p_x == bad)
throw FatalException()
...of course, that happens one instance out of a thousand. I've noticed management-types like to take those 1-in-a-1000 cases where XYZ practice is important and apply it system-wide. Please don't do that. It just rots code.
my name is here
Thursday, April 10, 2008
Dear Dave,
// A class-scope variable.
private int age;
This is actually an instance variable. A class-scope variable would look like this:
private static int age;
Also, as others have said, I don't see why my classes shouldn't be free to mess around with their own guts. I've never been bitten by any problems with this in six years of miserable Java programming!
John Topley
Thursday, April 10, 2008
I do have a case to support the OP. Recently I had a class with a money value with getter/setter's which were used in some places, in other places the value was accessed directly.
Had to apply a complex formula to the value, only wanted to do this in one place. I put it in the getter and had to chase down and change all the direct access points.
Overall, I agree with most posters here, but there are cases to support the OP.
Hi, folks.
Show me the code.
Not a single person who replied provided a source code example where directly accessing an instance variable provides a benefit that outweighs any of the advantages listed.
Dave Jarvis
Thursday, April 10, 2008
The advantage is in simplicity. No need for any code example to understand that, methinks...
If you're unsure about the benefits of simplicity, just read Joel's rants on architecture astronauts. Good times... :)
Don't Fix What Ain't Broke
Thursday, April 10, 2008
"Not a single person who replied provided a source code example"
I guess the complexity reduction from directly accessing our fields resulting in code that was too small to see!!!
(I wanted to waste my quota all at once ... now I don't have to worry about it, but I wonder if I'm using too many ellipsii and octothorpes).
YAGNI for almost all of your points - sure if I need to do those things then use the pattern you recommend but most of the time I don't so why write the more complex code just in case I *might* need one of these things one day?
"When subclasses access inherited variables through accessors"
So why not just make your fields private? As the field age in your example so AFAIK it *can't* be accessed by subclasses anyway.
Thursday, April 10, 2008
Dave, when it's you against the whole world, guess who's going to win?
Given the opportunity cost, there are battles you should fight and battles you shouldn't. This falls into the latter category.
>> So why not just make your fields private? As the field age in your example so AFAIK it *can't* be accessed by subclasses anyway. <<
In C# this is true. You need to specify "protected" if you want subtype visibility.
Dave Jarvis: "Show me the code.
Not a single person who replied provided a source code example where directly accessing an instance variable provides a benefit that outweighs any of the advantages listed."
Brice? Is that you?
Sorry. Got confused. Brice Richard is usually the one who posts something totally wrong, has dozens of people tell him so and explain why, and then calls them all idiots because they don't agree with his originally wrong ideas.
Are you a cousin or something?
"Sorry. Got confused. Brice Richard is usually the one who posts something totally wrong..."
I think that's a bit harsh. The consensus seems to be that what Dave is proposing is usually unnecessary, which is some stretch from totally wrong. It the very worst it's harmless.
John Topley
Thursday, April 10, 2008
And because this discussion hasn't deteriorated sufficiently, I'd just like to add that in C#, you'd write:
public class Person
public int Age { get; set; }
and then use this.Age or Age interchangeably within the class, foo.Age outside the class, and never worry about directly accessing the underlying variable, because it's not exposed.
And when, in the fullness of time, it turns out that you need to implement something like bounds-checking, you refactor the property:
private int _Age;
public int Age
get { return _Age; }
if (value < 0)
throw new AgeException(...);
_Age = value;
which doesn't change the interface to the class. Of course, at that point you start being able to reference _Age inside the class and bypassing your shiny new bounds-checking logic. Hammers do occasionally smash thumbs.
Robert Rossney
Thursday, April 10, 2008
1. Disagree, setters for private scope is noise and makes the code significantly less readable.
2. Code written to support debugging is a poor use of time. Debugging is not an effective activity. Debugging is not what makes you a professional programmer. The ability to automate your unit testing and ensure every line of code of your application has been executed prior to handing it to your customer is what separates an amateur from a professional programmer.
Hear, hear. Make them public access so that everyone can have a go ;)
Jussi Jumppanen
Thursday, April 10, 2008
"Debugging is not an effective activity"
Didn't have that thread last week?
Friday, April 11, 2008
>> The ability to automate your unit testing and ensure every line of code of your application has been executed prior to handing it to your customer is what separates an amateur from a professional programmer. <<
Significant amounts of my code have never seen a unit test. For example, all of the code I wrote between 1979 and 2000 wasn't unit-tested. Yet somehow it works perfectly well.
You're making the same mistake as the OP in not understanding that every "best practice" is context-dependent. You can be a fanatic about unit testing or whatever. But don't expect the world to agree with you.
Mark Pearce
Friday, April 11, 2008
> The ability to automate your unit testing ... is what separates an amateur from a professional programmer.
Knowing how to do so is one thing, actually doing it is another. I'd argue that where you are on the effort/coverage curve, and the extent to which testing is automated, is a decision for and reflects on the employer and the product, more than the developer.
"I'd argue that where you are on the effort/coverage curve, and the extent to which testing is automated, is a decision for and reflects on the employer and the product, more than the developer."
SDTimes just had an article on automated Java testing that included some of the top tool vendors warning that there should be a common-sense balance between automated testing and manual testing. See:
and here for their "best practices" sidebar:
And I want to pile-in some more on comprehensive unit testing as a "best practice".
Designing your initial unit test suite to achieve 100% coverage is a dodgy idea. It's a sure way of creating a test suite weak at finding faults of omission. Also the coverage tool can no longer tell you where your test suite is weak - because it's uniformly weak in precisely the way that coverage can't directly detect. So be careful about code coverage in unit test design. The return on your testing $/£ (in terms of bugs found) is too low.
Suppose you have a manager like Brian who requires some level of code coverage, perhaps 90%, as a "shipping gate". The product isn't done - and you can't ship - until you have 90% coverage. The problem with this approach is that people optimise their performance according to how they're measured. You can get 90% coverage by looking at the coverage conditions, picking the ones that seem easiest to satisfy, writing quick tests for them, and iterating until done. That's faster than thinking of coverage conditions as clues pointing to weaknesses in the test design. It's especially faster because thinking about test design might lead to 'redundant' tests that don't increase coverage at all. They only find bugs.
Mark Pearce
Friday, April 11, 2008
C. Wells ...
I suspect that she's referring to the Rational Unified Process (RUP), where you never code to features, but to requirements. Then you test to the same requirements and provide traceability both forward and backward.
That's a pretty pathetic description (considering they have a whole book describing it), but it is essentially describes the idea that you perform different testing against different types of requirements (unit testing against software requirements, integration testing against system requirements, etc.).
So it's essentially the waterfall method with extra mechanisms added for requirement traceability and test coverage.
> RUP, where you never code to features, but to requirements.
Ah, got it, thank you.
> unit testing against software requirements, integration testing against system requirements
... and, eventually, acceptance testing against the functional specification.
I didn't understand why it seemed to be saying that you shouldn't do acceptance testing; I thought they were implying that the mapping from functional specification to software requirements is perfect, and/or is "proven" by using traceability instead of (not as well as) by running the software ... but more likely it's that such "proving" is meta-testing that's outside the scope of automated testing.
If someone working for me wrote all their code like this, I would fire them.
Senior Amateur
Saturday, April 12, 2008
Senior Amateur's attitude is even worse... Fire someone over their code style? Maybe have a talk with them and have them change it, but fire them? Sometimes I find it ridiculous how passionate people in the software industry get over things that in the larger scheme of things are meaningless. I've seen two people argue over what a local variable should be named for several hours. Just call it blub and be done with it.
Yes, I know that the above post was likely not serious.
Saturday, April 12, 2008
One important exception to this is where the entire interface to the class is through the member variables, as in:
class Complex
public double X;
public double Y;
You could throw in copy constructors and toString() members, but for accessing, what's the point of getX()/setX(), getY()/setY()?
Sunday, April 13, 2008
Doesn't Java have some kind of implicit getter/setter construct? Like this in ECMAscript:
private var x:int = 0;
public function get x():int {
return _x;
public function set x( i:int ):void {
// validation here
_x = i;
It's tremendously useful.
1. Gives most of the benefits of using accessors
2. Allows the rest of the code to use simple language like "x+=5"
3. You can start with a normal variable, and add the accessor functionality later without needing to change places where the variable is being accessed.
I'm not a Java person, but I'd hate to be without this kind of construct.
"Doesn't Java have some kind of implicit getter/setter construct?"
John Topley
Monday, April 14, 2008
If it's important why can't accessors be implemented automatically? For example, the compilers should create the get__X and set__X whenever you have a variable X, and when they're used and there is no method of the same name defined in the code. The coders can choose to ignore the accessor until they really need it - and it'd always be there, to be inherited or modified.
Monday, April 14, 2008
Dear Amateur Programmers,
never listen to people who want to sell you a silver bullet that you should "Always. Always. Always." use.
Oh, and never listen to people who want you to "never" listen to other people. :-)
Trust me: Never trust someone who says "trust me".
Tuesday, April 15, 2008
What the OP is suggesting has in fact some interesting points. While I do not agree that every instance variable should be wrapped in getter/setters - for the many reasons all the others here already mentioned - I do see the advantages for this practice for special cases.
The example of the OP might not be the best for this, but if I need to check boundaries or other constraints on a instance variable, chances are already high that this variable is already representing a more complex concept than "just a value". In the example, the variable "age" might be replaces by an instance of an "Age"-Class(!) -(or maybe even better a variable "DateOfBirth" of a "Date"-class! but thats beyond the point i try to make here).
So one would be able to correctly add something to that "age" by using the appropriate methods. There would be no confusing what "age = age+1" would mean - is it now one year older? or one day? is it allowed to substract from an "age"? with "age.addYears(1)" there would be no such confusion anymore.
So my point is: think throughoughly(sp?) the way you want to implement your class attriutes. Then think again. And only _then_ implement then. :-)
That is a really good point. I would call my self a mid level programmer and I have always implemented my code in that manner. I have classes and classes full of many functions/methods. It would not be worth it to go and update each and every instance of that, but I will defiantly use this practice in the future. Thanks for your great advice! I found this article very useful!
Random Thoughts
Thursday, April 24, 2008
Dear Dave,
Does the specific languge you use support nested functions inside your methods? Let's assume that it does. Then you could implement getters and setters for your local variables that resides within your methods. Do you? If not, list the arguments why. Then use those argument against your original claim.
My point is that there are no absolute 'good' principles. As many before me already wrote - it's situation dependent.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz


text:
Outdoor Kitchen Ideas - You will surely be enjoying the best time in your life even though there are a few key things. Thorough examination of the condition of the house will be the beginning of the right. Or, if you feel bored with the loo...[Read More]
Recent Posts
Popular Design
Home | About | Contact | Sitemap | Topics | Privacy Policy | Term of Service | Copyright/IP PolicyCopyright © Omborokko.com 2012 – All Rights Reserved.


text:
The GPG program has commissioned Department of Energy National Laboratories to perform real-world measurement and verification of the following technologies in pilot installations in federally-owned buildings. Preliminary technology assessments are available below as PDFs.
Preliminary Technology Assessments
LED Retrofit Kits with ALC [PDF - 247 KB] This evaluation will test five different LED-based lighting systems with integrated advanced lighting controls (ALC). The retrofit kits are designed to upgrade existing recessed fluorescent troffer lighting to LED lighting without requiring a full fixture replacement or work in the ceiling plenum. Findings available in 2018.
The GPG program enables GSA to make sound investment decisions in next generation building technologies based on their real world performance.


text:
Grass, an Environmentally Friendly Biofuel
Jerry Cherney, the E.V. Baker Professor of Agriculture of Cornell University is urging the US to look towards using grass pellets as an energy source, a method well accepted in Europe. The sustainable 70 day cycle (vs. the 70 million year cycle for fossil fuels) can be implemented and consumed locally, producing 90 percent less greenhouse gases than oil, coal and natural gas. So what's stopping grass pellets from taking off? Cherney points out that without a political lobby, there is no way of starting an alternative energy industry. Calling all farmers . . . lobby and grow alternative energy!
[by Che-Wei Wang]


text:
CHRISTMAS came early to Manly Sea Life Sanctuary when Santa dropped in yesterday.
A feeding frenzy erupted as Santa and one of his elves served a mix of seafood to the sharks, penguins and some eager stingrays, while the resident turtles took more of a liking to lettuce.
Sanctuary general manager Kris Lim said the marine animals were feeding more than usual and not just for the festive season.
"Everything feeds more at this time of year because the water is a little bit warmer," Mr Lim said.
"The fish will become more active and they get hungrier."
Mr Lim said Santa would be at the sanctuary for feedings every day until Christmas Eve: "For kids, this time of year, they love seeing Santa. Santa feeding the sharks and the penguins is something they're not going to see anywhere else."
You could enjoy some of Sydney's best attractions, such as Manly Sea Life Sanctuary, with a 2-for-1 entry pass in tomorrow's The Sunday Telegraph.
Simply cut out the coupon inside The Sunday Telegraph, take it to any one of five major attractions and receive one free admission with a full paying adult. The attractions include Sea Life Sydney Aquarium, Manly Sea Life Sanctuary, Madame Tussauds Sydney, Sydney Tower Eye and Wild Life Sydney Zoo.
Originally published as Even sharks love Santa Claus


text:
Propulsion Technology
In propulsion technology and electrical engineering we have a range of sealing solutions to suit systems and components used in conjunction with motors and transmissions. In addition we provide solutions for hydraulic drive systems, vehicle engineering and mechanical engineering. Whether standard products or special solutions are used, our technicians will prescribe a solution to meet the individual requirements of the specific application.
We offer:
- Proficient technical consulting
- Custom-designed solutions
- Long-term partnerships in development and engineering
- Complete logistical implementation
- After-sales service / support
Watch our movie on windpower seals and sealing solutions here.


text:
Status: Opens in 5 minutes
Know more about this business than we do? Cool! Please submit any corrections or missing details you may have.Help us make it right
Be the first NJ.com user to add photos or videos of Avallone Lawn Care
Since 1989 the company has been providing Lawn Care Services.
Avallone Lawn Care can be found at 4 E Emerald Isle Dr . The following is offered: B2B Contractors. The entry is present with us since Sep 9, 2010 and was last updated on Nov 14, 2013. In Dover there are 37 other B2B Contractors. An overview can be found here.


text:
To build a squirrel baffle, perforate a stovepipe cap, insert a stovepipe, screw it in place, slip a pole inside the baffle, attach a clamp, and rest the baffle on it. This one-hour project requires a stovepipe, a pipe cap, a hose clamp, screws, a screwdriver, a drill and pliers.Continue Reading
Clamp a stovepipe cap to your work surface with the open end facing down. Outfit a drill with a metal-cutting bit, and drill a hole in the center top of the cap. Release the clamp, slide the cap over the stovepipe, lay the pipe on your work surface. Clamp it in place, and drill several holes in the side of the cap. The holes must also pierce the underlying pipe. Insert screws in the holes, and tighten them with a screwdriver.
Slide the baffle over the pole, lower it until the top is 4 or 5 feet above the ground, and mark the pole at that location. Lift the baffle off of the pole, and screw a hose clamp over the mark. Secure it tightly so the clamp does not slide under the weight of the baffle.
Slip the baffle over the pole, and rest it on the hose clamp.


text:
- slide 1 of 11
Before getting down to business to make Windows boot faster, we have to understand why Windows boots slower. One reason for the slowdown of Windows is us, the users, and the second reason is Windows itself. Let's start with the first one.
What does a user do? A user install programs on his computer. There is nothing wrong with this; if the user wants his computer to perform a specific task, such as editing spreadsheets, he will install a program to do it. However, the program is not so innocent. Many programs place themselves or some component of themselves, such as the "update checker" to the Windows startup. Some programs have the right to do this, such as device drivers, anti-malware programs, firewalls etc. Although these are logical, it is not acceptable to me for an image viewer to place itself in the start-up; what if I have booted my computer to watch movies but not for viewing images? Why should that program slow down my boot time?
- slide 2 of 11
Removing Unwanted Programs
The first place to visit is Start → All Programs → Startup. Right-click there and delete all the shortcuts there. Then head up to your start menu and select Start → All Programs → Run and type "msconfig" which will open up the System Configuration Utility. Switch to the "Start up" tab where you will see various programs that are started when Windows starts. Check the entries carefully and remove any items you think you don't need. There is an important thing to note here: remove the programs you do not need, not the ones you don't recognize. There are two types of programs that you'd better keep:
- Device Drivers: Your sound card, graphics adapter etc. should be running when Windows starts. Don't disable them.
- Anti-malware programs: Don't disable your anti-virus, anti-spyware and other anti-malware products. The same goes for your firewall.
You can safely remove an entry such as "Adobe Assistant" which does not do anything except check periodically for Adobe updates when you are connected to the Internet. Just check the items and evaluate them: do you really need to have them started with Windows? A quick way to determine this may be to check the installed programs; if the entry is about a program that you have installed, other than the drivers and the anti-malware programs, it is more likely that you can remove the program from the startup.
- slide 3 of 11
Remove Unused Programs and Fonts
Why would you want to spend your computer resources for the programs you have installed once and never used? Remove those programs which you do not need but are pulling down your computer's performance. No, you do not need the cute kitty screensaver that you installed with the expense of some hard disk space and processor cycles. Nor do you need the fancy smiling e-mail management program.
Also, many users do not know that the fonts present in the C:\Windows\Fonts directory are a real resource hog in Windows boot. Yes, Windows reads all the fonts that you placed there every time the system boots. Make yourself another folder, such as Fonts under My Documents and place your unused fonts there.
- slide 4 of 11
Read on for checking Windows XP services, Windows Vista Services and other boot optimizing techniques.
- slide 5 of 11
Make Windows Boot Faster: Windows XP We continue to look at how to make Windows boot faster. Here we continue with shutting down your unnecessary Windows XP services.
- slide 6 of 11
Check Windows Services (Windows XP Professional)
You can't control your operating system as much as you can control your installed programs. One thing that you can do is to disable the Windows services that are not necessary. Go to Control Panel → Administrative Tools → Services. You will see a two-pane window. On the left there are the local services that we're interested in. To change the service, double click on the entry and change the "Startup type" to "Manual" or "Disabled". Following are the list of services to consider to disable:
- Alerter: If your computer is not on a network that requires you to change your password periodically, you can set this to "Disabled."
- Application Layer Gateway Service: If you are not using your computer as a router to have the other computers on the network to connect to the Internet, then you can set this to "Disabled."
- Clipbook: If you are not sharing your clipboard with the computers on the network, you can disable it.
- Distributed Transaction Coordinator: If you are not accessing network filesystems or databases, you can set it to disabled.
- Net Logon: If you are using your computer as a stand-alone device and not in a home/office local domain based network, you can disable it.
- Remote Desktop Help Session Manager: If you are not receiving remote support, or if you do not allow your computer to be controlled remotely, you can disable it.
- Remote Registry: If you don't want somebody to tweak your registry, then disable it. I see this one as a potential security hole.
- Telnet: Enables remote users to connect to your computer with the Telnet protocol. If you do not want this, or you do not connect to your computer remotely with Telnet, you can disable it.
- Terminal Services: Unless you are using your computer to access terminal servers or unless you are using your computer to allow such connections, you can disable it.
- Upload Manager: Unless you are in a local network and sharing data, you can disable it.
- Wireless Zero Configuration: If you do not have a wireless connection from your computer (such as a desktop connected to a modem/router via cable) you can disable it.
- Workstation: Like the upload manager; unless you are in a network sharing data, you can disable it.
Screenshot courtesy of Integ.
- slide 7 of 11
Read on for checking Windows Vista and Windows 7 Services and other boot optimizing techniques.
- slide 8 of 11
Make Windows Boot Faster: Windows Vista We conclude our article on making Windows boot faster by an explanation of shutting down unnecessary Windows Vista services. Then we go on with how to defrag our computer. We first look at why we have to defrag and answer the question "how do I defrag my computer" and mention a wonderful free program, Auslogics disk defrag, as opposed to the utility Microsoft supplied with your computer. At the end we give our recommendations on how to use our tips.
- slide 9 of 11
Check Windows Services (Windows Vista and Windows 7)
To access the services under Windows Vista and Windows 7, go to Start → Run and type services.msc and hit Enter. Click continue in the User Account Control (UAC) dialog box. Following are the services you can disable or set to manual:
- Diagnostic Policy Service: If you know what you are doing on your computer, such as making sure that a program has been installed correctly, you can disable it.
- Distributed Link Tracking Client: You can disable this if you are not on a network.
- IP Helper: It is very unlikely that you are using IPv6. You can set this to "Disabled."
- Network List Service: Unless you are on a network, or unless you are experiencing too many Internet connection problems, you can set this to "Disabled."
- Offline Files: You can disable it if you are not using offline files.
- Print Spooler: You can safely disable it if you don't have a printer.
- Remote Access Connection: If you are not connected to the Internet via a dial-up service or if you are not using Virtual Private Network connection, you can set this to "Disabled."
- Server: If the other computers on the network are not accessing your computer to share files or use the printer, you can disable it.
- Tablet PC Input Service: Is your computer a Tablet PC? If not, you can disable it.
- IKE and AuthIP IPSec Keying Modules: If you do not have a VPN connection that uses Internet Key Exchange or IPSec, you can disable it.
- Network Location Awareness: You can disable it if you are not on a network and you don't plan to share your files and printers.
Screenshot courtesy of Technospot.
- slide 10 of 11
Defragment Your Hard Disk
This is the final point in speeding up our Windows boot. When you are working with Windows, files get scattered over the hard disk over time and the hard disk head requires more time to find the remaining part of the file. You can think about it as reading a book in the following page order 1 – 8 – 15 – 2 – 24 – 3 – 81 – 12 – 9 – 11 – 4 which is confusing. Every one of us prefer to go with the 1- 2 – 3 – 4 – 5 – 6 - … which makes more sense. Defragmentation is the process of putting the "pages" in our book in order,where the pages are the files and the book is the hard disk.
I personally do not find Windows' defragmentation utility, which you access by Programs → Accessories → System Tools → Disk Defragmenter, an effective tool. I would rather recommend Auslogic's Disk Defrag program as very efficient and effective. It is a very small download and does not take up much space.
- slide 11 of 11
Making any Windows system boot faster involves some tweaking the system. I recommend you make one change at a time and see if everything works. That way, if something goes wrong, you can immediately undo your last change and continue where you left off. However, you also have to take into account that undoing your last change may affect the programs that you use and you may have to reconfigure them. It is always a good idea to make a restore point before making changes of this sort to your computer.
How to Make Windows Boot Faster
If your computer is slow to boot up everyday, if your boot time is long enough for grabbing a coffee, then the time has come to roll up your sleeves and start optimizing your system. In this article series we optimize our boot time and optimize our Windows system to work faster.


text:
Erik Estrada knows how to do Miami like a local. The former CHiPs star eschews typical celeb hot spots and heads to places where he knows he can get good, no-flash grub.
"I love Latin dancing," says Estrada, in town to promote his voice work in Planes: Fire & Rescue. "After a night out, I have to go to La Palma Cafeteria and knock out some eggs, tostones, rabo encendido [oxtail] or lo que desea [whatever you want]."
Another must stop: Islas Canarias bakery. "If you don't get there early in the day, forget getting a plate. It's packed. The food is just that good."
The New York native, 65, definitely enjoys his time here. Though he's not retired by a long shot, relaxation is never a bad thing. Which is why Planes suited him so well.
"With animation, you walk into a room, and the dialogue is right in front of you. There's no interaction with costars," Estrada says, adding with a laugh: "You just show up. You don't got to shave or shower or nothing."
In all seriousness, Estrada enjoyed his time working on the Disney sequel, assisting Dusty the cropduster fight fires from the air. Coincidentally (not), the telenovela star plays Nick "Loop'n' Lopez," a macho helicopter cop who used to be on TV's CHoPs.
"It was a beautiful reminder of CHiPs," says Estrada, who played Poncho on the iconic show from 1977 to 1983. "And you gotta have respect for the bravery of the first responders. They're in the front line."
Does the actor catch any of the new cops shows today?
"Nah, I don't," he admits. "I used to try to get those gigs, but they said my persona as Ponch was too big that it would be a distraction. I like my Animal Planet. Morgan Freeman on Through the Wormhole [Science Channel]. National Geographic, Game of Thrones. Gritty stuff. I like gritty."
Rob Lowe is going back to Lifetime, according to The Hollywood Reporter. The actor's last outing on the female friendly network was in 2012 as the lead in Drew Peterson: Untouchable. Lowe goes from convicted murderer to victim in the upcoming Beautiful and Twisted, portraying Ben Novack Jr., the 53-year-old Fontainebleau heir who was brutally slain in a New York hotel room on July 12, 2009. Novack's body was discovered by his wife Narcy ( Paz Vega), who is serving a life sentence for plotting the slaying of her husband and his mother Bernice Novack ( Candice Bergen). Set to air this fall, the film is based on an upcoming book by Miami Herald staff writer Julie Brown.
Also coming from Lifetime, as per THR: With This Ring, about singletons vowing to get hitched. Executive produced by Gabrielle Union, the TV movie starts filming in August, ostensibly after the actress' real life wedding to Dwyane Wade. When's the honeymoon?
Lovely ladies alert at two private events: Venue mag will celebrate its muy VIP July/August cover party with Devious Maids star Roselyn Sánchez at an invitation-only event Wednesday evening at Cavalli Miami Restaurant & Lounge. The evening will kick off with a red carpet set up outside the SoFi spot; former RHOM Alexia Echevarria, Venue's executive editor, will play hostess. On Thursday evening, Ocean Drive's Swim Issue cover girl, Victoria's Secret bombshell Erin Heatherton will be feted by the glossy magazine at Delano South Beach. We predict bikinis; don't pray for rain.
Gimme A Burger is getting its 15 minutes. The restaurant, with locations in Pembroke Pines and Deerfield Beach, competed last year in a culinary contest in Las Vegas and now Fyi, a new network from A&E, is broadcasting an episode of the competition on World Food Championships, hosted by Food Network personality Jeffrey Saad and airing at 10 p.m. Thursday. You can get the Bacon Infused Burger featured on the show along with fries and drink at GAB for $8.95 Thursday through Sunday.
Madeleine Marr