Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fifty Shades of OOP

lesleylai.info

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Fifty Shades of OOP

#101

Post by fmjrey »

austin-cheney wrote: post #77

> OOP-bashing seems fashionable nowadays. Yes, and for just cause. OOP was invented in Simula76 (1976) and popularized in C++ (1982). OOP solved a very real problem of allowing applications to logically scale in memory constrained systems by allowing logic to grow independently and yet retain access to memory already claimed by a parent structure. Amazing. Now fast forward and you get languages like Java, Go, and Jav…

OOP certainly has some early roots in trying to be more efficient with code reuse, organization, and clarity of intent. Later on Java tried to alleviate serious productivity and security issues with garbage collection and cross platform portability. It certainly increased the distance between the hardware and the developer because there are more levels of indirection that can now degrade performance.

However with hardware progress, performance is not the only critical criteria when systems grow in size, in variety of hardware, with internet volumes, in the number of moving parts, and of people working on them. Equally if not more important are: maintainability, expressivity so less lines of code are written, and overall the ability to focus on essential complexity rather than the accidental one introduced by the langage, framework, and platform. In the world of enterprise software Java was welcomed with so much cheers that indeed a "code culture" started that grew to an unprecedented scale, internet scale really, on which OO rode as well.

However not all control is lost as you say. The JVM that also runs more advanced langages with a JIT that alleviates some of the loss of performance due to the levels of indirections. GC are increasingly effective and tunable. Also off-heap data structures such as ring buffers exist to achieve performance comparable to C when needed. See Martin Thompson video talks on mechanical sympathy, which he gave after working on high frequency trading on the JVM, and check his later work on Aeron (https://aeron.io/). As usual it's all about trade-offs.

Re: Fifty Shades of OOP

#102

Post by d0mine »

nr378 wrote: post #56
vbezhenar wrote: post #43

Earlier quoted context omitted.

So Python is not OOP language? You can't hide fields.

You can hide fields in Python with a little bit of gymnastics: class EncapsulatedCounter: def __init__(self, initial_value): _count = initial_value def increment(): nonlocal _count _count += 1 return _count self.increment = increment counter = EncapsulatedCounter(100) new_value = counter.increment() print(f"New value is: {new_value}")

Usually, a simple function is enough:

    def make_counter(start=0):
      count = start
      def incr():
        nonlocal count
        count += 1
        return count
      return incr
Example:

    >>> c = make_counter()
    >>> c()
    1
    >>> c()
    2
But it hides nothing:

    >>> c.__closure__[0].cell_contents
    2
    >>> c.__closure__[0].cell_contents = -1
    >>> c()
    0
"private" in Python is cultural, not enforced. (you can access `self.__private` from outside too if you want).

Re: Fifty Shades of OOP

#103

Post by o_nate »

LukeShu wrote: post #17
Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

Inheritance is just the unnecessary coupling of composition and polymorphism.

Inheritance is not necessary, but then very few programming constructs are absolutely necessary. The question is does it help program clarity or not. I think that in some cases, used sparingly, it can. The main danger of inheritance is not that it is OO, but that it is not OO enough. It breaks encapsulation by mixing properties and methods between base classes and derived classes without clear boundaries. Composition is safer because it preserves encapsulation. In general, I think that protected abstract methods are a code smell, because they usually indicate close coupling of details that should be kept separate between the base and derived classes. But used correctly, inheritance can be more succinct and convenient.

Re: Fifty Shades of OOP

#104

Post by taberiand »

vips7L wrote: post #94
taberiand wrote: post #72

Earlier quoted context omitted.

I would say specifically encapsulation of mutable data

Lots of modern OO uses immutable data.

What's a good example? What comes to my mind is modern C# which I would say is a multi-paradigm language that encourages things like immutable records and interfaces and composition over inheritance as alternatives to the now less favoured OOP styles that it also supports

Re: Fifty Shades of OOP

#105

Post by elric »

morshu9001 wrote: post #86
elric wrote: post #40

Earlier quoted context omitted.

Why did you create an anemic domain model? Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient. record User(String name){} Records are great when doing more "data oriented programming".

That's not object oriented though

Does it have to be? Java is a hybrid paradigm language. It's perfectly fine to write data-oriented code. And if you're using an anemic model, there's no point paying the overhead price of fully fledged classes.

Re: Fifty Shades of OOP

#106

Post by elric »

vips7L wrote: post #96
elric wrote: post #40

Earlier quoted context omitted.

Why did you create an anemic domain model? Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient. record User(String name){} Records are great when doing more "data oriented programming".

I don't think anyone sets out to make an anemic domain model, it just happens. Lots of developers start with POJO's for JPA models and then never advance them into being full fledged objects when the requirements develop.

Surely that's a conscious design decision? Deciding to create data-carrying POJOs with JPA annotations is a valid strategy. Mixing in a bunch of logic and non-JPA state with them is a recipe for disaster. If you want your classes to Do Stuff, you have to design them to Do Stuff.

I dislike the term "anemic domain model", it casts a value judgment which I think is unwarranted. There's a spectrum from anemic to obese (for want of a better word). There are tradeoffs all along that spectrum. Finding a sweet spot will depend heavily on what you're doing, why you're doing it, what your team is comfortable with etc.

Re: Fifty Shades of OOP

#107

Post by morshu9001 »

elric wrote: post #105
morshu9001 wrote: post #86

Earlier quoted context omitted.

That's not object oriented though

Does it have to be? Java is a hybrid paradigm language. It's perfectly fine to write data-oriented code. And if you're using an anemic model, there's no point paying the overhead price of fully fledged classes.

I meant, if you want to evaluate OOP by itself, you can't use things that break the paradigm. Java broke that probably because they realized OOP isn't always a good idea, after sticking to it up through v7.

Re: Fifty Shades of OOP

#108

Post by lukan »

bccdee wrote: post #97
lukan wrote: post #63

Earlier quoted context omitted.

That would be way, way more verbose for everything. Every display object has a x y width and height for example. And there is basic validating for every object. Now a validate method can be conposited. But variables? Also the validating, there is some base validating every object share (called wih super) and the specific validating (or rendering) is done down in the subclasses. And even for simple things, you can com…

> Every display object has a x y width and height for example. Intuitively¹, I feel like this is something that should be separated out into a BoundingBox object. Every component that needs a bounding box satisfies a small `HasBoundingBox { getBoundingBox(self) -> BoundingBox }` interface. Maybe there's a larger `Resizeable` interface which (given a type that satisfies `HasBoundingBox`) specifies an additional `setBo…

"You don't end up with a tidy hierarchy this way, but I'm not sure you'd end up with a tidy hierarchy using inheritance, either."

Well, I am sure, that all the graphic libaries I ever used, had this inheritance model. (The graphics libary I build, as well.)

The libaries I have seen, that used a different model, I did not really like and they were also rather exotic, than in wide use. But I am willing to take a look at better designed succesful inheritance free ones, to see how it can be done,.if you happen to know one ..

Re: Fifty Shades of OOP

#109

Post by twintwinetwolf »

llbbdd wrote: post #25
twintwinetwolf wrote: post #24

[flagged]

HN doesn't allow image replies, but if you were to image search "smug meme" you would find any of them to be an appropriate response to this useless post of yours, and imagine I put it here for your convenience

Hilarious that you're literally trying to outsmug me, and failing. THe irony. It burns. lol

Re: Fifty Shades of OOP

#110

Post by bccdee »

lukan wrote: post #108
bccdee wrote: post #97

Earlier quoted context omitted.

> Every display object has a x y width and height for example. Intuitively¹, I feel like this is something that should be separated out into a BoundingBox object. Every component that needs a bounding box satisfies a small `HasBoundingBox { getBoundingBox(self) -> BoundingBox }` interface. Maybe there's a larger `Resizeable` interface which (given a type that satisfies `HasBoundingBox`) specifies an additional `setBo…

"You don't end up with a tidy hierarchy this way, but I'm not sure you'd end up with a tidy hierarchy using inheritance, either." Well, I am sure, that all the graphic libaries I ever used, had this inheritance model. (The graphics libary I build, as well.) The libaries I have seen, that used a different model, I did not really like and they were also rather exotic, than in wide use. But I am willing to take a look a…

None of the graphics libraries you've ever used were built with mixins, decorators, or multiple inheritance? I confess I never went too deep with GUI toolkit programming, but Swing, for instance, definitely uses decorators (e.g. JLayer).

Neither Go nor Rust have inheritance, so any graphic library implemented in those languages will be inheritance-free; ditto anything in a functional language, for the most part. In general, these tend to be very declarative toolkits, being post-React, but they should illustrate the point. For something more widely used in industry, I know Imgui is a popular immediate-mode library.

Post reply on HN