8 ms·

I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far b

I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc http://www.youtube.com/watch?v=4F72VULWFvc

ErrantX 16y ago
One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"
- jonsen 16y ago
  In some sense that's what the second O says, isn't it? It's not called Object Programming, but Object-Oriented Programming.
  - bediger 16y ago
    But isn't that where it goes astray? If we all called it "Class Oriented Programming" we'd come closer to an accurate name. "Class Oriented Programming" as a name might take away the emphasis on instances, and put emphasis on designing classes. Or not. There appears to be no bottom to human stupidity.
    - stcredzero 16y ago
      If we apply a design pattern from Smalltalk, we have Concepts. Every Concept has another concept which is its Misconception. This gives us an infinite regress of misconceptions, unless we can come up with a Metamisconception, which is a concept which is its own erroneous misconception. Then we can implement unbounded stupidity in a system of finite size.
- edanm 16y ago
  Tell that to Java developers :)
- stcredzero 16y ago
  Really, it depends on your environment. In Smalltalk, most things are objects. Not surprisingly, it turns out to be easiest to make most things objects. I find that Smalltalk is best when a program is mostly objects, there's a sprinkling of short-ish procedural methods whose workings are hidden by encapsulation, and perhaps a handful of long optimized algorithmic methods. I suspect that in Self, it's easier to make more things objects. (jk - everything is an object in Self.) Objects aren't quite as easy to use in C++ and Java. The cost is higher, so the opportunities to use objects with a good cost/benefit payoff are fewer. That's all there is to it. Does this generalize? In most Functional languages, functions are really easy to use, and can be used in flexible and powerful ways. What's the best way to program in them? Why, using functions! Yup, seems to work. Fancy that!
  - infinite8s 16y ago
    Also, functions + closures = objects
  - ErrantX 16y ago
    A lot of stuff can work as objects; in fact in many cases an object can be the smallest (or simplest, or most logical etc.) piece of code. But not everything must be abstracted :)
  - hboon 16y ago
    In Smalltalk, everything is an object.
arethuza 16y ago
So what's wrong with using a switch statement if all you have are 3 operations? Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.
- jedbrown 16y ago
  Depends whether it's in a library where extensibility is a feature.
- jemfinch 16y ago
  > So what's wrong with using a switch statement if all you have are 3 operations? Because you won't always have only three operations. What about division? Exponentiation? Square root? Factorial? Arbitrary user-defined functions? What if you didn't anticipate an operation one of your clients needs? If you use standard OO principles, your client can rectify that problem; if you use a switch statement, they can't. > Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it. Why not just do it right from the start? It's extremely simple, it's a pattern every OO programmer is familiar with, it's more computationally efficient and has other advantages as well. It's also not nearly as complicated as the linked Strategy code. The appropriate analogue to the author's switch statement (in Python, since I'm not a Java programmer): class Op(object): def eval(self, a, b): raise NotImplementedError class Add(Op): def eval(self, a, b): return a + b class Subtract(Op): def eval(self, a, b): return a - b class Multiply(Op): def eval(self, a, b): return a * b It's twelve non-blank lines, more than half of them boilerplate; translated into Java it would probably gain a few keywords and a couple lines of ending braces, but would not grow significantly. Compare this to almost that many lines for the switch version (note that the OP left out the declaration of the enum, the function boilerplate, etc.) for something less maintainable, less extensible, less idiomatic, and with lower performance.
  - arethuza 16y ago

ErrantX 16y ago

One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"

jonsen 16y ago
In some sense that's what the second O says, isn't it? It's not called Object Programming, but Object-Oriented Programming.
- bediger 16y ago
  But isn't that where it goes astray? If we all called it "Class Oriented Programming" we'd come closer to an accurate name. "Class Oriented Programming" as a name might take away the emphasis on instances, and put emphasis on designing classes. Or not. There appears to be no bottom to human stupidity.
  - stcredzero 16y ago
    If we apply a design pattern from Smalltalk, we have Concepts. Every Concept has another concept which is its Misconception. This gives us an infinite regress of misconceptions, unless we can come up with a Metamisconception, which is a concept which is its own erroneous misconception. Then we can implement unbounded stupidity in a system of finite size.
edanm 16y ago
Tell that to Java developers :)
stcredzero 16y ago
Really, it depends on your environment. In Smalltalk, most things are objects. Not surprisingly, it turns out to be easiest to make most things objects. I find that Smalltalk is best when a program is mostly objects, there's a sprinkling of short-ish procedural methods whose workings are hidden by encapsulation, and perhaps a handful of long optimized algorithmic methods. I suspect that in Self, it's easier to make more things objects. (jk - everything is an object in Self.) Objects aren't quite as easy to use in C++ and Java. The cost is higher, so the opportunities to use objects with a good cost/benefit payoff are fewer. That's all there is to it. Does this generalize? In most Functional languages, functions are really easy to use, and can be used in flexible and powerful ways. What's the best way to program in them? Why, using functions! Yup, seems to work. Fancy that!
- infinite8s 16y ago
  Also, functions + closures = objects
- ErrantX 16y ago
  A lot of stuff can work as objects; in fact in many cases an object can be the smallest (or simplest, or most logical etc.) piece of code. But not everything must be abstracted :)
- hboon 16y ago
  In Smalltalk, everything is an object.

arethuza 16y ago

So what's wrong with using a switch statement if all you have are 3 operations? Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.

jedbrown 16y ago
Depends whether it's in a library where extensibility is a feature.
jemfinch 16y ago
> So what's wrong with using a switch statement if all you have are 3 operations? Because you won't always have only three operations. What about division? Exponentiation? Square root? Factorial? Arbitrary user-defined functions? What if you didn't anticipate an operation one of your clients needs? If you use standard OO principles, your client can rectify that problem; if you use a switch statement, they can't. > Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it. Why not just do it right from the start? It's extremely simple, it's a pattern every OO programmer is familiar with, it's more computationally efficient and has other advantages as well. It's also not nearly as complicated as the linked Strategy code. The appropriate analogue to the author's switch statement (in Python, since I'm not a Java programmer): class Op(object): def eval(self, a, b): raise NotImplementedError class Add(Op): def eval(self, a, b): return a + b class Subtract(Op): def eval(self, a, b): return a - b class Multiply(Op): def eval(self, a, b): return a * b It's twelve non-blank lines, more than half of them boilerplate; translated into Java it would probably gain a few keywords and a couple lines of ending braces, but would not grow significantly. Compare this to almost that many lines for the switch version (note that the OP left out the declaration of the enum, the function boilerplate, etc.) for something less maintainable, less extensible, less idiomatic, and with lower performance.
- arethuza 16y ago