Live data from Hacker News

One of the Best Bits of Programming Advice I ever Got

objology.blogspot.com

31–40 of 94 posts

Re: One of the Best Bits of Programming Advice I ever Got

#31

I disagree with this advice and the reason I disagree with it because it completely disregards the human tendency to name objects (not OOP objects, but real-life objects) based on their functionality. Guess what a photocopier does? Or a scanner? An eraser? An elevator? I don't think these are particularly bad names; quite the contrary, their meaning is very clear. Why would it be any different for OOP objects? If the…

> Guess what a photocopier does? Or a scanner? An eraser? An elevator?

Or a Coffee-Maker... Instant factory pattern.

Re: One of the Best Bits of Programming Advice I ever Got

#33

Earlier quoted context omitted.

Object oriented programming is the sweet spot solution to many problems. For example, if you have a UI with several text fields, it's natural to think of them as objects that have methods like setText(), setEnabled() and such. These methods often have side effects and that's their whole point. Of course functional programming also has use cases for which it is the sweet spot solution, e.g. writing compilers.

These methods often have side effects and that's their whole point. You don't need state and mutations, GUIs can also be programmed nicely using functional reactive programming (FRP). A nice description of FRP: http://stackoverflow.com/questions/1028250/what-is-functiona... Some examples of FRP in GUIs: http://www.haskell.org/haskellwiki/Reactive-banana/Examples

A simple counter that can be manipulated with two buttons "Up" or "Down": https://github.com/HeinrichApfelmus/reactive-banana/blob/mas...

    main = start $ do
        f        counter]
    
        actuate network
This doesn't look like good UI code to me. It seems to use too many advanced FP concepts that have nothing to do with the task at hand. Are you sure this is better than the OO approach? Why?

Re: One of the Best Bits of Programming Advice I ever Got

#34
What do you do if you need a higher level interface to a bunch of classes that are already fairly complex in their own right? Seems to me "plain" nouns (since really these are all nouns) are good for simple concepts and things with real world analogs, but in projects of any complexity you quickly end up with complex logic whose only succinct description is what it does.

My experience tells me the key aspect of software quality is the interfaces. The simpler and less leaky the interfaces, the more understandable, maintainable and correct the software will tend to be. Part of this is inherent to the problem itself, but a big chunk of it—especially in the middleware—is the ability of a software architect to have a sense of the whole project and figure out the best places to carve the interfaces. Doing so correctly is the difference between a maintainable million-line project and spaghetti. Truly brilliant engineers will figure out interfaces that make code 100x more reusable and elegant, maybe spawning open source extractions, etc.

If something is named well is an orthogonal concern, and highly contingent on what the actual object is. The best code in the world might be impossible to name intuitively if there is no real world analog.

Re: One of the Best Bits of Programming Advice I ever Got

#35

I disagree with this advice and the reason I disagree with it because it completely disregards the human tendency to name objects (not OOP objects, but real-life objects) based on their functionality. Guess what a photocopier does? Or a scanner? An eraser? An elevator? I don't think these are particularly bad names; quite the contrary, their meaning is very clear. Why would it be any different for OOP objects? If the…

I think in the author’s ideal world, we would not have Photocopier, Scanner, and Eraser objects, but rather a Paper object that can copy, scan, and erase itself.

Re: One of the Best Bits of Programming Advice I ever Got

#36
post #6

I generally accept the point made in the article, but what should I use in place of "Controller"? If using MVC I generally call it "ApplicationController" or "SimpleController". Should it be "Application", "ApplicationControl"...?

what do the controllers actually do? Synchronize state? Verify that constraints are met?

I believe the OA's intended question is what are the controllers? Well, what are they? Yes, I know they control things, but what is the actual thing that they are?

Re: One of the Best Bits of Programming Advice I ever Got

#38
post #35

I disagree with this advice and the reason I disagree with it because it completely disregards the human tendency to name objects (not OOP objects, but real-life objects) based on their functionality. Guess what a photocopier does? Or a scanner? An eraser? An elevator? I don't think these are particularly bad names; quite the contrary, their meaning is very clear. Why would it be any different for OOP objects? If the…

I think in the author’s ideal world, we would not have Photocopier, Scanner, and Eraser objects, but rather a Paper object that can copy, scan, and erase itself.

Yeah, but good luck trying to reuse the same basic instructions to scan non-paper objects without multiple inheritance.

Re: One of the Best Bits of Programming Advice I ever Got

#39
post #19

Earlier quoted context omitted.

He does say, at the end of the piece, that nouns that happen to end in -er are an exception.

Aren't all words which end in -er, and used as class names, nouns ?

Sorry. Meant to upvote you, but downvoted by mistake.

Re: One of the Best Bits of Programming Advice I ever Got

#40
post #15

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess. But Travis is…

I think there is a more fundamental misunderstanding in OO than bad naming convention. You are right about the usefulness of -er named objects -- but then again, are they really objects, or just functionality wrapped into a wrongly chosen language construct?

Following your example, you could have implemented the strategy pattern into DatabaseConnection to freely inject functionality into the object when X happens. Assuming these functions do not have additional data members other than the parent object, they easily can be simple functions or even lambdas.

(Of course it's easier to restrict to classes, because you can validate against interfaces in case a function signature doesn't cut it.)

What Travis is suggesting, when you have an object that defines both data and behavior, the object context should be determined by the data, not the behavior. If done properly, you end up with less names that end in -er.

Post reply on HN