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

Premature Abstraction

arendjr.nl

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Premature Abstraction

#31

Post by j45 »

temporarely wrote: post #22
j45 wrote: post #16

Earlier quoted context omitted.

The real world definitely isn't OO all the time. Maybe more functional and event based. The oscillation between the two as what's in favour is also humorous. The right thing for the right need for the present and near future, especially the newer the codebase, and the greater the need to learn, is often the way to consider pursuit.

> The real world definitely isn't Ironically, (ime/o!h;) it turns out this the "root of evil" plaguing abstraction : thinking that software architecture must map to "the real world".

For me, software and tech that is for someone, exists to work for people, who are end users.

End users and customers don't exist to serve at the leisure and pleasure of software and it's creators.

Making people work harder than they need to operate software is selfish.

DevOps and DevEx is important, but if no one uses it with those being great, the Customer and their experience are often lost and never gained.

Learning to model something flexible enough for absorbing and quickly implementing the early customer feedback that is relevant is critical to boring things like retention.

Helping customers earn enough to eat every month, helps the tool makers earn enough to eat every month.

Re: Premature Abstraction

#32

Post by mannykannot »

sevensor wrote: post #4

Although I agree with the recommendations, I cringe at the definition of abstraction. In a sane world, abstraction doesn't mean defining classes so much as it means identifying important unifying concepts. DRYing your code by moving a method to a common base class isn't abstraction in any important way, it's just adding a level of indirection. In fact, I'd argue that this example is the opposite of abstraction: it's…

I came to say more-or-less the same thing. The author is making some valid points, but the moral is that premature reification of abstract concepts may be harmful, especially if there is something vague about them.

Re: Premature Abstraction

#33

Post by jprete »

epgui wrote: post #25
recursivedoubts wrote: post #6

My general take (and w/ the caveat that every system is different) is as follows: - procedural code to enter into the system (and perhaps that's all you need) - object oriented code for domain modeling - functional code for data structure transformations & some light custom control flow implementation (but not too much) I like the imperative shell, functional core pattern quite a bit, and focusing on data structures…

If you think OOP is particularly well-suited to domain modelling, you should try the FP approach to domain modelling. You will never be able to unsee the complexity inherent to OOP.

Do you happen to have a link to an example or explanation?

Re: Premature Abstraction

#34

Post by jerf »

recursivedoubts wrote: post #27
sqeaky wrote: post #15

Earlier quoted context omitted.

This is a strong argument against inheritance, but that isn't everything about OOP. Just one well supported advanced abstraction (That I would also argue should be rarely used.) I would argue that just having strong type system and bundling methods with data gets you the vast majority of the usefulness of OOP. Liskov, Open/Closed, Message Passing, and other theoretical abstractions be damned. EDIT - Where are the goo…

Agree 100%: static typing (for code completion) + method/data bundling is the major win in OO, and it rarely gets talked about for whatever reason. It's unfortunate that inheritance became such a major focus of practical OO languages. Would love to see a composition-first OO language. Might have its own problems, but would at least be interesting.

Whether you'd call "composition-first" is probably asking for a big argument about what "composition first" really means, but Go is certainly a language that syntactically privileges a particular type of composition over inheritance. It doesn't even have syntax for inheritance, and frankly even manually implementing it is rather a pain (best I've ever done requires you to pass the "object" as a separate parameter to every method call... and, yes, I said that correctly, to every method call).

I'm not ready to try to stake a position on the top of some "composition first" hill because the syntactic composition it supports is not something I use all the time. It's an occasional convenience more than a fundamental primitive in the language, the way inheritance is in inheritance-based languages. Most of the composition is just done through methods that happen to use in composed-in values, but it is generally not particularly supported by syntax.

Re: Premature Abstraction

#35

Post by sqeaky »

1propionyl wrote: post #29
recursivedoubts wrote: post #27

Earlier quoted context omitted.

Agree 100%: static typing (for code completion) + method/data bundling is the major win in OO, and it rarely gets talked about for whatever reason. It's unfortunate that inheritance became such a major focus of practical OO languages. Would love to see a composition-first OO language. Might have its own problems, but would at least be interesting.

Go, Rust, Zig, etc all support static typing and method/data bundling without any explicit language support for implementation inheritance (interface inheritance in general and especially when structural rather than nominal is not nearly as much of an issue and doesn't create strict tree hierarchies). Rust has support for variance and subtupint so perhaps it's not as pure of an example, but it's pretty heavily restri…

Even in C++ the last time I thought I might need inheritance I made a simple class/struct with a few members that were `std::function` instances. Instead of needing inheritance this worked and I managed to keep type safety checks on all function return and parameter types. Once upon a time this would have been weird function pointers and `void*` with dangerous casts. Last month when I did it, there were just lambdas passed to typesafe constructors.

Re: Premature Abstraction

#36

Post by resters »

A well chosen abstraction dramatically simplifies code and understanding, and a poorly chosen abstraction has the opposite effect.

When building a system some choices about abstractions can be made early, before the problem domain is fully understood. Sometimes they stand the test of time, other times they need to be reworked. Being aware of this and mindful of the importance of good abstractions is key to good system design.

Re: Premature Abstraction

#37

Post by feoren »

I know HN doesn't like quibbles about site design, but I'm literally having difficulty reading the article due to the font size being forced to be at least 1.3vw. Zooming out doesn't decrease the font size! Downvote if this is boring, but (a) I've never seen a site that did that before, so it's just notable from a "Daily WTF" kind of perspective, and (b) just in case the submitter is on HN: it's actually preventing me from reading the content (without changing it in DevTools anyway).

Re: Premature Abstraction

#38

Post by m3kw9 »

Here’s the scenario, hot shot intern comes in, calls a meeting to use generics so things can be done “easier”. He does a good job at presenting it and its value, the dumbass team lead oks it. Fast forward 1 week everyone complains behind on how much pain it is to use

Re: Premature Abstraction

#39

Post by dakiol »

patmorgan23 wrote: post #9
withinboredom wrote: post #7

Earlier quoted context omitted.

I'm currently dealing with a codebase that does this to a ridiculous extent. Like, literally, every change affects the entire project because everything is made of base-classes mixed in weird ways. Every concrete object inherits multiple base classes and no individual behavior. Imagine something like this: class Book extends ShelfableItem, Pagable, Authored, Readable, BaseBook {} It's absolutely insane.

Oof. I know this is an example but all of those look like they would be better served as interfaces.

It depends. Of course we don’t see the whole picture because it’s just an example by OP, but I also find weird that the de facto solution to abstract classes is: interfaces. Sometimes, duplication is better than interfaces.

Re: Premature Abstraction

#40

Post by HdS84 »

commandlinefan wrote: post #28

> The real problem with the class Foo above is that it is utterly and entirely unnecessary I see this sentiment a _lot_ in anti-OO rants, and the problem is that the ranter is missing the point of OO _entirely_. Hard to fault them, since missing the point of OO entirely is pretty common but... if you're creating classes as dumb-data wrappers and reflexively creating getters and setters for all of your private variabl…

As someone who dies a lot of python, TS, dotnet and java - I disagree. The problem of dotnet and java is that everything is a object. And for many cases, I don't need that object at all, it can be a static class - but honestly, the python concept of a module fits a lot better. It's a grouping of functions in a module, not a class holding functions.
Post reply on HN