Hacker News Reader

Comment by dheera | Hacker News Reader

OOP is nice when it is used concisely and when objects correspond 1:1 to real things.

This is painful use of OOP (actual code from an Android app):

    Camera.Parameters params = mCamera.getParameters();
    params.setRotation(90);
    mCamera.setParameters(params);

This would be NICE use of OOP:

    mCamera.setRotation(90);

    mCamera.setParameters({"rotation": 90});

This is painful use of OOP:

    BitmapFactory.Options opts = new BitmapFactory.Options();
    opts.inSampleSize = 4;
    Bitmap bmp = BitmapFactory.decodeByteArray(data, 0, data.length, opts);
    mImageView.setImageBitmap(bmp);

This would be nice use of OOP:

    mImageView.setImage(new Bitmap(data = data, sampleSize = 4));

View on HN

For the camera example, I would rather do:

    Camera camera = createCamera({"rotation": 90});

If you need another camera with different parameters then create a new one. You can build the options before the creating the cameras to avoid duplication.

    Bitmap bitmap = createBitmap({data: data, samepleSize: 4});
    ImageView imageView = createImageView(bitmap);

In the case where you are mutating image view, it's an optimization to reuse the same memory that could be handled by your language/framework so you don't have to think about it. For example, like with react it could create an internal representation of what is rendered and then diff it with the new rendering and reuse the internal representation of image view and mutate it for you so you don't have to think about doing the optimization yourself.

As a Python programmer, all I see is heaps of very similar and the same words. It looks like mess, I'm sorry.

That's because you're telling the compiler what the type of the variables is ahead of time so the compiler knows whether you're using the type correctly. As opposed to in Python constructing an object and adding functions to it one by one at run-time, and only checking that the type is used correctly when the type is used.

There's a trade-off being made between conciseness on one hand and fast feedback on the other. Python leans toward conciseness and Java/C++ lean toward fast feedback. In Python you can express complicated ideas quickly, but you can't necessarily express correct ideas quickly. Whereas in C++ you can express correct ideas quickly but you can't express complicated ideas quickly.

If it's costly for you to correct defects in deployed software then you might prefer the fast feedback of C++ or Java rather than the flexibility of Python.

That part is fine, but Java idioms seem to routinely think that

    String string = new String("string");

isn't enough repetition, and so they take it a step further:

    StringFactory mStringFactory = new StringFactory(StringFactory.FOO || StringFactory.BAR);
    StringOptions stringOptions = new StringOptions();
    try {
        String string = mStringFactory.createString(StringFactory.STRING, "string", stringOptions);
    } catch (java.lang.string.StringException e) {
        runOnUIThread(
            new Runnable() {
                 try {
                     // facepalm

I'm exaggerating ;) but as a Python programmer myself, this is what comes to my mind whenever someone says the word "Java" to me. Obviously not for strings, but for more advanced constructs (e.g. Bluetooth) I often do see this much repetition in Java code. It's almost like someone designed this language to prank engineers.

That a reasonably parody of a lot of Java code - but I don't think it's really a property of Java the language but some odd principles that seem to be popular (or used to be popular) in the Java community.

BTW You missed:

   public static final String STRING_STRING_CONSTANT = "string";

Thank this is a very nice answer and it makes sense to me. Indeed I once sat down to try Kotlin for a day. The amount of code I had to write to get a json from an api into a dict that I could address by key was baffling to me. In python it took met 2 imported modules and then 2 lines (something like

    some_dict = module.scrape_api()
    value_I_want = some_dict['my_value']

I gave up after a day, when I just wrote down exactly what I expected to pull down and what types were in the values and keys. I can understand it helps you prevent errors but man is there a learning curve... BTW, I could write those checks in Python as well, but they are optional.

> I could write those checks in Python as well, but they are optional

You're probably going to need to check `value_I_want` though. So maybe the checks aren't quite as optional as they look.

Checks in Python are pretty concise. If you just want to have a default value if the key my_value doesn't exist, this is all you need:

    value_I_want = some_dict.get('my_value', default_value)

If you want a more strict check including type checking:

    value_I_want = some_dict.get('my_value')
    if type(value_I_want) is not str:
        do_something()

In Java the real problem is nested JSON objects -- it's a real PITA to read those. You can't do something like this (Python):

    value = some_dict.get("foo", {}).get("bar", {}).get("blah", default_value)

I believe one can even do:

    value_I_want = some_dict.get('my_value':str)

and

    value = some_dict["foo"]["bar"]["blah"]

A Python background explains that, as y'all tend to worry less about memory usage and re-use. This can have its upsides, but it probably creates a bit of a blind spot here, because it's referencing the sort of thing one probably wouldn't do in python.

I was just using the same type of typing syntax as the OP. I could have left that out.

That works until you want to let the user rotate the phone without interrupting the stream. And, creating a new camera probably means freeing the resources from the old camera, which, for some cameras, can mean power cycling.

A rotation is a gravity based human concept that results in the transformation of stream data before being displayed, not anything related to the actual camera.

> OOP is nice when it is used concisely and when objects correspond 1:1 to real things.

These sorts of objects provide a nice API, but they don't contribute to good internal designs. I have seen many systems were there is an attempt to map objects to physical things (like on a modem, you might have a "demux" object). Invariably, software ends up having to bend to the design of the hardware, and you end up with very leaky abstractions. Why have a "demux" object, when all you are trying to do is write some registers depending on user configuration? Why not design your software around what it is actually doing, rather than what the system's overall purpose is?

Interfaces are a different question. High level interfaces that reflect what the system actually does are very useful. I think this is born out in some modern OOP-ish languages like Go or Rust where interfaces are everywhere, but full scale OOP is mostly absent.

Although I have only a very superficial understanding of modems, I'd say demux() should be a function library, not an instantiated object. But even if it is an object for various reasons such as caching, that's quite fine with me; a Demultiplexer can be thought of as an conceptual component that a Modem "has" inside it.

What I don't like is when things like options, parameters, and intermediate representations of data that aren't actually intuitive are represented as instantiated objects of their own. In some sense I expect every instantiated object to "do" something useful of its own, and represent a functional block in a flowchart. Objects should, to the greatest extent possible, represent "is" and "has" relationships in a system, IMO.

Also, class hierarchy should be well designed. For example, an Exception called ConnectionError (that inherits from Exception) is great. It can be parametrized from there. What sucks is if there is SomeFooConnectionError, SomeBarConnectionError, SomeBlahConnectionError that all inherit directly from Exception and don't inherit from a common ConnectionError, because that makes the try/catch block super verbose and easy to miss a possibility.

I would argue that it’s very rarely useful to mutate like this at all, and this is one of my grievances with OOP in practice. In particular, I don’t need to mutate via methods—this kind of encapsulation is rarely useful; it’s not like one day I’m going to be able to swizzle the implementation for a network-backed implementation without introducing a breaking change (and a whole host of performance problems when iterating over a collection of objects).

In addition, there are things that just don't need to be separate classes, they should be static methods or constructor options of an existing class.

I very much like the Pythonic paradigm of conciseness, e.g. PIL.Image.open() or cv2.imread() with optional arguments which is light-years more pleasant to code with than the BitmapFactories and BitmapFactory.Options and AbstractSingletonProxyFactoryBeans.

It's also really nice that Python and JavaScript classes/objects can have arbitrary attributes stuck onto them, e.g. someObject.__source = "foo" or set and that sticks to someObject wherever it goes. It's a very intuitive way to implement a lot of things; one can liken it to sticking a post-it note on a box.

Or just plain procedural

    camera_set_rotation(camera, 90);

Reply on news.ycombinator.com