|
Simon Lee Shugar wrote: what do you do for your Lunch
Well normally I bring my lunch to the office. However, the other day I went out to a local restaurant and sat at the bar as is my habit. Just so happened that the bartender that particular day was a rather attractive exchange student from that land down under. Gave serious consideration about not coming back to work. There is something about I love about that accent. Could have sat and listened to her talk all day long.
|
|
|
|
|
I eat the leftovers from home. Oldest first that way if anyone else in the house wants more of what we had last night they can but no one else will eat it after a couple of days.
If nothing is leftover then it becomes a peanut butter sandwich and a bag of microwave popcorn.
I only go out to lunch if the company is paying.
|
|
|
|
|
Since you are having trouble deciding what to do for lunch, here is a Q&A about things to have for lunch.
Q: What is black; white; green and bumpy?
A: A pickle wearing a tuxedo.
Q: What's the best thing to put into a pie?
A: Your teeth!
Q: Why do the French like to eat snails?
A: Because they don't like fast food!
Q: Why did the fisherman put peanut butter into the sea?
A: To go with the jellyfish!
Q: What did the baby corn say to it's mom?
A: Where is pop corn?
Q: What do you call candy that was stolen?
A: Hot chocolate!
Q: Waiter, will my pizza be long?
A: No sir, it will be round!
Q: Why did the banana go to the doctor?
A: Because it wasn't peeling well!
Q: What is white, has a horn, and gives milk?
A: A dairy truck!
Q: Why don't you starve in a desert?
A: Because of all the 'sand which is' there.
Q: Why shouldn't you tell a secret on a farm?
A: Because the potatoes have eyes and the corn has ears.
Q: What is a pretzel's favorite dance?
A: The Twist!
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
I'm pretty lazy and there's a filled baguette vendor who comes around our business park with a van, so I usually buy one from him. It's more expensive than making it myself but not massively and I earn enough that 5 lunches a week isn't going to do any damage.
If I have bread in the house then I'll make sandwiches with whatever I have (usually some kind of cheese and pickle variant), but I usually don't because I'm rarely in at lunchtime and that's the only time I really eat it.
|
|
|
|
|
Out once a week for a sit down; usually Mexican or Pho or similar. Subway a couple of times (it is about 50 yards up the road) or eat in as they provide food once or twice a week, usually. Now and again I might bring something in if I can remember to do it in a sleepy haze.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
My wife packs my lunch. It's always quite edible, sometimes a surprise, and I know better than to say anything about it other than "Thank you, my love."
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
My wife makes me a delicious sandwich every day... Well, most days... Some days... Occasionally... Actually just the once this year so far so I go to BK across the road from my office or the market down the street where there is a variety of healthy salad stuff... which I ignore and get the Pretzel hot-dogs or the turkey-burger with fried onions, or the chinese buffet stuff or a deli-style sandwich with too much meat.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
In our office we dine together every day. We either send one of the staff out to pick up orders we phone in, or we cook something onsite. My office has a full kitchen, and we hire for cooking skill as much as business abilities. The last time we had a round of interviews, we selected a girl who makes a mean chicken fried steak over a girl who had her own business making personalized cupcakes. It was a good choice, as the one we hired has been expanding her culinary talents, and has mastered Mexican sauces and entrees, and various types of soup. I do Cajun dishes, smoked meats and prime rib, the GM does spaghetti and lasagna, the accountant makes excellent tacos, and all of us are handy with the grill.
None of us is good at losing weight, however. 
Will Rogers never met me.
|
|
|
|
|
While reading theDailyWTF the other day a contributor mentioned a pattern that he thought was a WTF and that was requiring object in constructors over id values.
Sorry, my example was too specific for people
ie
<br />
public List<Bar> GetLineItemsForOrder(Order order);<br />
public static void DoSomeAction(Foo foo);<br />
vs
<br />
public List<LineItem> GetLineItemsByOrderId(Int64 orderId);<br />
public static void DoSomeActionById(Int64 fooId);<br />
Hopefully, my clarification will help focus people to addressing the specific question. But then, I have been here long enough to know; asking a question on this forum really never ends well.
To be honest I nearly universally prefer the former (requiring fully hydrated objects) In the 99% of cases where I write code, where absolute performance isn't critical, the first method is so much more reliable and easier for Junior developers to work with. (Less mistakes, more compiler errors, etc)
So, what say you? Remember, if you disagree you are wrong, also remember I do both depending on my mood so not only am I Intransigent but I am a hypocrite.
modified 27-Mar-14 9:45am.
|
|
|
|
|
But shouldn't the Order instance already have its line items attached?
How about Order.GetLineItems()?
And... the first one should be in a higher layer, the second one in a lower layer.
After your edit:
Now there isn't enough context.
Does DoSomeAction really need the whole Foo? Probably not, so why pass it?
DoSomeActionById may be more reusable.
I think I'd invoke "Do The Simplest Thing That Could Possibly Work" and choose the latter.
You'll never get very far if all you do is follow instructions.
modified 27-Mar-14 10:00am.
|
|
|
|
|
|
|
I'd go a step farther and suggest you should probably be able to iterate through order directly without goofy "get/set" artifacts.
|
|
|
|
|
It depends whether line items are part of the data model that are naturally under orders, or whether this is going to invoke a query which requires significant logic. In the latter case I'd write a service class with a method like GetLineItems(Order o) because data classes shouldn't have complex logic, and (addressing the other answer here) properties shouldn't involve significant processing.
|
|
|
|
|
If you have a fully constructed Order object, then I'd probably prefer to hand that over - as in your first example.
The method then has the option of what it wants to use to find the appropriate items - which may be a List contained within the Order object already rather than a DB access requiring the ID
And given that these are public methods, why expose what type an Id is if you don't have to? Makes it a lot harder to change later to a GUID for example.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
But Shirley, the items are part of the order. so:
List items = order.getItems();
items = new Order(id).getItems();
|
|
|
|
|
Depends which class the GetLineItemsForOrder method is part of.
If it's part of the Customer or Supplier class, then you would be fetching only those relevant to that class instance, and for a specific order.
If it was part of the Order class, then I'd expect it to be parameterless and use this
And I'd hope that it did call the Order class method to get the items!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Sometimes, for brevity sake, when posting online I do not take the time to design fully complete examples that cover every edge case and condition. I do this in order to ask a simple question in as few lines as possible.
|
|
|
|
|
OriginalGriff wrote: why expose what type an Id is if you don't have to?
Excellent point.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
The second reveals too much about the underlying implementation.
|
|
|
|
|
Both method can be valid depending on the usage of the parameter inside the method. If it's hard to get the whole Foo object then will work only using id else I'll lean to use DoSomeAction(Foo foo) method.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: where absolute performance isn't critical
Passing a pointer is not very expensive; you're not copying the object, just passing an integer that holds it's address in memory.
Ennis Ray Lynch, Jr. wrote: the first method is so much more reliable and easier for Junior developers to work with.
One does not pass a Form if one is merely changing the caption.
There is no discussion, as far as I can see.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I would always write the first unless there is a very good reason not to. Sometimes it may not be an object type, it may be an interface, if you only want to deal with a particular facet of your model – sometimes model classes need to implement several interfaces if they cover an object that is used in a lot of places, but that's okay (although it should lead you to question whether your data model is the best).
The only time I'd write code with IDs is in low level database or external API access classes. Anywhere else I'll define an interface for the actions I want to perform on an object, and if necessary a GetXxx(int id) method which looks up enough of an object to populate the interface.
If we're talking about object mapping frameworks then you should be able to construct an object over a query and have it load things on demand at which point you might as well just use the domain objects directly; only the relevant parts will need to be populated.
|
|
|
|
|
You're passing an object by value? That's pretty disgusting.
|
|
|
|
|
0. You're wrong.
1. It depends.
The massive danger (especially to those, whom you call "junior developers" and the rest of us call "noobs") is that they then think they require a complete object, so when displaying (say) a list of Foo in a grid, rather than just bringing back from the Db the few columns required, gathered in a nice piece of minimalistic Sql using only the required joins, they end up bringing back the whole kit and caboodle, probably via some "it's OK I don't have to look at the 437 SQL statements it generates so I can pretend this is still OK" ORM.
And it all looks great on their test database with three customers and half a dozen orders, but once you put it in a real environment the client-pc needs 6Gb Ram just to hold the customer collection, and crashes when you try to open the order history because WCF can't handle the traffic.
So, if you already have an object, pass it to the method. If you don't, pass its Id.
Of course, if the method in question might make changes to the object passed, we're in a different territory - but again it all comes down to 'it depends'
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
