Hacker News Reader

Comment by phpthrowaway99 | Hacker News Reader

I like to think I'm a decently intelligent person. UC Berkeley Mechanical Engineering. I self taught a few years ago and wrote an entire project management SaaS for a certain industry in PHP and jQuery front end. 34 small companies use it.

Even though I once took a highschool C++ course long ago that talked about OOP and made us do a few things with it.....

I still have no idea what OOP really is, and why I need it. Unless I'm using it without knowing, I have a feeling I'm either dumber than I think or people have lost their minds. I can't tell.

View on HN

Self-taught programmers have an easier time thinking in a simple, direct, solution-oriented way. CS-educated programmers tend to think too much about whether this project gives them an excuse to use fancy things they learned in courses (how can I cram algebraic types into my recipe management program?).

The downside of being self-taught is well-known - you might end up convincing yourself that for loops don't work, strings with more than 10 characters are unreliable, numbers can only reliably be added using BigDecimal, etc.

Self-taught programmer checking in: OOP is about isolating private implementation details, akin to using local variables inside a function. Seems pretty direct to me.

Totally, "isolating private implementation details" sounds super clear and useful. /s

The general answer seems to be that OOP starts really helping when many people/teams are involved.

Being self taught and a one person team I suppose hasn't forced me into it yet.

At some point in time "the other people" are going to end up being different versions of Future You :-P . So if you take the "other people" argument, then it's definitely worth learning just for that reason. OO is pretty handy for the You Of Today too though.

The basic low down is that this is all about encapsulation (tidying things away in boxes).

You hopefully already know a bit about that.

Say you just have all globals through all your files, you probably know you end up with a big mess of spaghetti.

To help with that, you've probably already learned about tidying away code and variables into functions. And you might know that if you have a local variable, it is only visible inside the scope of your function. If you're doing it right, then nothing outside your function will ever directly touch the local variables inside the function, or vice versa.

This makes it really really easy to reason about what happens inside the function, since -with the exception of your parameters and your return- what happens in vegas... uhh... your function, stays in your function. And the inputs and outputs to the function are well defined.

This saves hours and hours of hunting out every last spot that some global was used, just in case it is interfering with something 1000 lines away. If you've done a lot of programming, you've probably been there a hundred times, cursing the laziness of Past You as you went.

Maybe you also separate your program out into different files. Model.php, View.php, Controller.php DoImportantThing.php ... maybe something like that?

So you probably already realize that tidying things away in boxes is a good idea. Everything you can tidy or organize away inside some box is something you don't need to worry about elsewhere at least. Out of sight is out of mind.

Wouldn't it be great if there were more ways to help you tidy things away into boxes? Well, we're in luck. PHP has classes and objects. These are a further way to organize functions and data together into a next-size box.

The idea is to tightly control what gets in and what gets out of these boxes again. And if you do, that's an additional level of things you don't need to worry about constantly. This frees up that part of your mind for other things.

Of course if you're a PHP programmer you don't NEED to use classes and objects. You don't NEED to use anything. But they're a very powerful tool to help you keep your code squared away. And since they're built right in to the language already, right at hand, why wouldn't you use them?

Classes and objects make most non-trivial projects easier and quicker to write (especially if you can reuse old classes, which you often can!) , and they make medium to large projects rather more manageable and tractable.

If you poke me, I could find some time to show you how you can make classes and objects work for you?

[disclaimer: Classes and Objects are definitely not the first/last/only/best/worst tools to organize code. Different languages have different tools sometimes. PHP just happens to provide Classes and Objects, so that's what you've got to work with there.]

I really appreciate your offer regarding PM, and the time you took to write that post. As you figured, I have learned those easier parts of not making things global, writing functions, separating files, all that. The way you explained it does make it clear that OOP could be the next step in helping me keep my sanity and my code clean. Since writing this post I looked up a few explainer videos regarding OOP and somewhat get it now. I somehow get the feeling that if you do a good job with functions, it's almost working the same way. But I'm sure there's still parts I'm missing. I appreciate your offer but I don't think it's fair to use your time when I haven't personally tried to use the countless resources explaining OOP that are available online. I'll look into them so I know what the possibilities are when I work on my next project. Thank you for the response.

> I somehow get the feeling that if you do a good job with functions, it's almost working the same way.

Yes. A lot of what people profess about the "clean" ways to write OOP is essentially just the same as using Functions with Namespaces

Which you can do with modules in Python, so the particular utility of classes gets increasingly hard to tease out.

One neat use of classes is model objects in scikit-learn. But R manages to do the same thing with a much more basic system called S3. In this system, you have "generic" functions which dispatch to different methods based on the data type of the first argument. This is used to endow the programming environment with predict and plot functions that behave differently depending on what kind of model you feed into them. This is essentially the same as how two different OOP classes can have two different methods with the same name. But S3 has none of the other trappings of object-oriented programming whatsoever: no encapsulation, no inheritance, no polymorphism.

I found it a fascinating revelation. It's hard to point to anything that R's object system makes unnecessarily difficult, any killer app that proves how pure OOP is better. I would guess that traditional OOP excels in GUI systems, but outside that context, people seem to increasingly find it wanting as a paradigm. We are seeing an evolution away from unipolar OOP ideology and towards a more multipolar exploration of different paradigms and their comparative advantages.

The idea that OOP is the natural next step in making a system more "scalable" and "better engineered" is... controversial.

http://harmful.cat-v.org/software/OO_programming/

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." – John Carmack

Unfortunately, many college-educated programmers have been taught OOP design ideology and profess it uncritically.

Many content on that website is straight up ridiculous claiming shit like gcc, any format, everything more complex than a rock basically is harmful, so I’m not sure it helps your case.

But I can agree with the Carmack quote, but that in itself doesn’t contradict OOP’s supposed benefits.

Object oriented programming is quite simple in theory.

Say you want to draw a window, it's one of many windows in your program. You could either write out the code to draw a window each and every time you want to draw a window, but that's probably inefficient at best and a nightmare to maintain at worst.

So you instead write a generalized class to draw a window. You then invoke that class as a new object when you want to draw a window, and pass to it any information unique to this particular window (eg: dimensions, contents).

This means the code to draw a window only exists once in your program. If you need to change how windows are drawn, you only need to change the one class instead of thousands of instances of drawing windows.

In essence, any action that you are likely to repeat many times in a program benefits from object oriented programming because it centralizes the code in one place and is abstracted away when the time comes to use it.

By contrast, if a given action is something a program would only do once or at most very seldomly, object oriented programming starts to lose importance because there's little value in centralizing and abstracting away a piece of code that will only ever execute once anyway.

> In essence, any action that you are likely to repeat many times in a program benefits from object oriented programming because it centralizes the code in one place and is abstracted away when the time comes to use it.

This isn't really the unique benefit of OOP. Plain functions also centralize code in one place and allow you to avoid writing repetitive code.

> So you instead write a generalized class to draw a window

Using Classes when you should be using functions is one of my biggest peeves with OOP and the programmers who write it.

Especially those who wind up writing a "Window" Class with one function "draw" and nothing else

To make it more OOPy you would probably give a few instance variables to the window like width, height, title, etc. That way, a simple drawWindow function would not be a better replacement anymore.

I think this is why some people call software development software engineering. If you don't take into account a lot of different things and engineer for stability and maintainability it can become a headache in the future. It may be simple and direct, but I wouldn't feel comfortable crossing a bridge made of 2x4s and plywood that was slapped together in a weekend and it would just make more work for someone else down the line because it probably wouldn't last very long.

I imagine it all depends on what the use case it. If your bridge is for hikers and mountain bikers, that seems fine and the best use of the local resources for trail maintenance. You could definitely hire some professionals to build a bridge that a tank or 18wheeler could cross over, but it might be a bit overkill. Would be impressive though!

I'm in the same boat, but not self-taught. I used to knew OOP. It was so obvious, you just made classes of things with methods to do actions. Then the things could be inherited from to create sub-category objects to be acted upon.

Then I read some articles. And I read forum posts. And I read comments. And I read OOP doesn't need this or that. I read multiple people define OOP in many different ways. Now I don't know how to define OOP.

I thought I could "know OOP if I saw it". And then I wrote code. I wrote in procedural languages. I wrote in functional languages. I wrote in declarative languages. I wrote in languages that like to blur the lines between them. And now I don't really know where the lines are. It all is just "programming".

Answering the question: "What is Object-Oriented Programming" used to be so easy. Now I don't know.

As mostly self-taught, I found that OOP makes more sense when you're working with many people and to simplify organization boundaries you deal with interfaces on abstract objects. Your team owns a window which calls click() on something owned by another team that implements IWindowControl. That IWindowControl interface is something you agree upon, but the internals of each object are invisible to each of you.

PHP (and JavaScript for that matter) historically did not have a good implementation of OOP, nor a culture around it. As far as I know, things have changed on that front, but it certainly does not surprise me that you were able to deliver a PHP product without touching it.

Doesn't mean that you're dumb or that other people lost their minds. My guess is you haven't given it a serious go, which is fine if you don't have a need for it. I personally find OOP fantastic for large codebases with multiple people working on them. Makes code a lot more maintainable and easier to reason about. The downside is that folks without a strong sense of architecture can get carried away with enterprise patterns and end up with abstractions on top of unnecessary abstractions. The basic tenets of OOP should be easy to understand if you just spend some time on it, though benefits can be hard to see if you haven't experienced procedural spaghetti code.

I think JS had a perfectly reasonable and workable OOP implementation, actually pretty elegant, but so different from the C++/Java class paradigm that almost nobody used it the way it was supposed to be. Instead, JS Objects were treated like broken Java classes, which led to all sorts of problems.

It's still hard to get the name of an object and use instanceof on it though. Ruby has the class and is_a? methods.

Uncle Bob argues that the point of OOP is dependency inversion. That is, your core logic doesn't know exactly some of the methods that will be called and some of the data structures that will be involved at execution time. Instead, those can be provided externally, which will make the logic resilient to code rot. Sounds like polymorphism, interfaces and method signatures.

Reply on news.ycombinator.com