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

Growing object-oriented software vs. what I would do

dpc.pw

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Growing object-oriented software vs. what I would do

#71

Post by dgb23 »

Zababa wrote: post #15
theteapot wrote: post #7

> I've purchased three OOP books (in the order I've read them): ... If your gonna pick three books on OOP it should include Design Patterns at the top of the list. At least if you want to understand why OO is a thing people still use and talk about.

Isn't "Design Patterns" about how to solve problems through an OOP approach, rather than about the strict benefits of OOP?

Many of the Design Patterns emerge from the fact that a given language does not have first class functions AKA closures AKA objects. So in a way it is working around the limitation of a language not being object oriented enough.

Re: Growing object-oriented software vs. what I would do

#72

Post by ilyash »

neutronicus wrote: post #35
dgb23 wrote: post #9

Earlier quoted context omitted.

In A Philosophy of Software Design the author talks at length about this and proposes that "deeper" modules (classes/methods/functions etc.) provide the most cost/benefit ratio, where the interface of a module is the cost and the functionality is the benefit. Code doesn't magically become less complex by hacking it into pieces.

Hacking code into pieces does give one the opportunity to name the pieces, though Mixed blessing, that

> name the pieces

Solved without splitting into functions.

https://ilya-sher.org/2019/10/21/section-syntax-next-generat...

Re: Growing object-oriented software vs. what I would do

#73

Post by azth »

pjmlp wrote: post #63
josephg wrote: post #57

Earlier quoted context omitted.

The "enterprise" programming culture which has emerged around Java doesn't impinge on all java code. But it is still a real thing. The fact that openjdk authors can rise above it and write clean, reusable Java code is obviously good. The fact that there is something that needs to be risen above is unfortunate. I think the same about Javascript, though the specifics are different. I've been writing JS for years, but I…

The "enterprise" programming culture did not emerge around Java. It was already been there regardless of the language. I am old enough to have done Enterprise C, Enterprise C++, Enterprise VB, Enterprise Delphi, Enterprise xBase, ...

I've seen and worked with enterprise golang code. Ugh.

Re: Growing object-oriented software vs. what I would do

#74

Post by ratww »

gonzo41 wrote: post #46
ratww wrote: post #16

Earlier quoted context omitted.

Java offers Records now, which are pretty much that. Pretty cool feature IMO: https://docs.oracle.com/en/java/javase/14/language/records.h...

Alternatively you could just make a final class with public member variables and no getters/setters and just treat it like a struct.

That's a great point, there's absolutely nothing wrong with public members if you only want a simple struct.

Re: Growing object-oriented software vs. what I would do

#75

Post by PaulDavisThe1st »

smashed wrote: post #59
PaulDavisThe1st wrote: post #54

Earlier quoted context omitted.

That might be true for something where the phrase "business logic" is applicable. But in my niche (realtime audio software), there is underlying data in the system that changes over time independently of events. So there is "something else to it".

Not meant to be pedantic, just playing devil's advocate, but isn't the real time audio bitstream just a continuous source of events that gets blended with the rest of the application state like active filters and what not?

Individual samples do not in any significant sense constitute events. The only thing that really pays them any attention is metering, and the result of that process is only displayed to the user periodically (i.e. something roughly equivalent to the screen refresh rate).

Even higher level objects, such as what are various called "clips" or "regions" or "events" frequently pay no role in any type of event notification system. In some designs, the boundaries of such objects may play a somewhat event-like fole.

Re: Growing object-oriented software vs. what I would do

#76

Post by lostcolony »

deltasixeight wrote: post #65
sam0x17 wrote: post #61

Earlier quoted context omitted.

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could tak…

"it doesn't really matter, you don't lose anything here"

Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder.

You mention "pure functional context", and yet this whole thread exists under a post about OOP, which is all about state management; it's no good trying to create toy examples that are side effect free to try and dismiss the points being made. Yes, of course pure code is fairly trivial to slice and dice, and the cost of doing so tends to be low (not zero, but low), but that's not really what is being talked about.

Otherwise you're kind of "no true Scotsman"ing this; "if you find these problems with your code than the code was never modular in the first place" - yeah, that's the point. Splitting code doesn't by definition make it more modular.

Re: Growing object-oriented software vs. what I would do

#77

Post by rytor718 »

amw-zero wrote: post #12

Here’s another review / critique of this book, but with a full implementation based on the author’s grievances: https://enterprisecraftsmanship.com/posts/growing-object-ori... . The main point of it is to avoid testing via mocks and to also avoid interfaces that are only there for testing purposes. The end design is extremely simple, and because it has command / query separation, the actual logic is trivially testabl…

I really enjoyed reading this one and loved the example. Unwittingly I found that my approach feels similar to what the author did as far as isolating the domain and writing unit tests. I learned some new things as well. Thanks for the link.

Re: Growing object-oriented software vs. what I would do

#78

Post by sam0x17 »

deltasixeight wrote: post #65
sam0x17 wrote: post #61

Earlier quoted context omitted.

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could tak…

> Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular.

It does. If I open up an arbitrary Ruby on Rails app for example, it is going to be easier to navigate for example a super fat model file than it is to navigate one that has been divided up into 10s of helpers and companion modules. There are similar scenarios in every other language. Extracting code and moving it somewhere else can truly be a death by a thousand cuts. My rule of thumb is if there aren't at least two places in the code that need to call My Extracted Thing (tm), then it shouldn't be extracted in the first place. If you're being DRY, it's OK to have a long class/file/method/function/module, and it's probably preferable to obfuscating your codebase and making it more difficult to navigate.

Re: Growing object-oriented software vs. what I would do

#79

Post by deltasixeight »

lostcolony wrote: post #76
deltasixeight wrote: post #65

Earlier quoted context omitted.

Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could tak…

"it doesn't really matter, you don't lose anything here" Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You mention "pure functional context", and yet thi…

>Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder.

You don't lose anything from a hard structural standpoint. Readability and being harder to understand is an opinionated based metric. It can be influenced by how you even name a function. It is a soft metric therefore weaker than the hard one. Additionally I DO mention the qualitative opinionated cost of modularity several times in this thread. So I address it but it is definitively weaker because anyone can have an opposite opinion and say that "in my opinion modular code is more readable"

>You mention "pure functional context", and yet this whole thread exists under a post about OOP,

Did you read the article? The author of the article was not convinced by OOP, he never supported OOP and generally the entire article is critical of OOP. I would say my reply is highly relevant and that you didn't read the article.

>it's no good trying to create toy examples that are side effect free to try and dismiss the points being made.

The examples serve a purpose to illustrate my point not to illustrate a real world example. If you want a real world example look at the react + redux architecture. The gold standard model for all web UIs exactly do what I mention with state management. They completely separate State away from pure functions. The entire web generally follows this model abstracting state management away from even code. Web apps are stateless with the database handling the entire job of state management. Examples of this pattern are EVERYWHERE, the example I gave is a toy example to help you understand not to say "hey this is a real world application." I thought that was obvious, my fault for not being clear on that.

>yeah, that's the point. Splitting code doesn't by definition make it more modular.

Completely and utterly wrong. Splitting code by definition makes it more modular. See: https://en.wikipedia.org/wiki/Modularity

The definition from above says: "Broadly speaking, modularity is the degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use"

If you are "splitting" code then by definition you are separating code which was previously combined. By Definition it is more modular. You really can't argue this point. More likely what's going on here is you have your own personal fuzzy definition of modularity which you are unconciously combining with your opinionated view on what constitutes good code. I am using the english definition not some fuzzy notion of good code so I am definitively right.

Be more exact and formal with your terminology it will lead to much less misunderstandings.

Re: Growing object-oriented software vs. what I would do

#80

Post by deltasixeight »

sam0x17 wrote: post #78
deltasixeight wrote: post #65

Earlier quoted context omitted.

Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could tak…

> Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. It does. If I open up an arbitrary Ruby on Rails app for example, it is going to be easier to navigate for example a super fat model file than it is to navigate one that has been divided up into 10s of helpers and companion modules. There are similar scenarios in every other language. Extracting cod…

>Extracting code and moving it somewhere else can truly be a death by a thousand cuts.

This is not what I mean by modularity. Let me be more specific. The code CAN be seperated and it can be recombined without a structural code rewrite. That is what I mean by modularity. Actually dividing code up and organizing it among different files is an opinionated organization scheme and NOT what I'm talking about.

When you do extract code and move it anywhere it's not exactly "death" it's just harder to read. Structurally the code is still sound. You can meet the requirements without rewriting the code, it's just the code is more complex to understand.

The bad scenario I'm talking about here is when you can't extract code and you can't move it around. When your requirements necessitates logic to be moved around and you can't because code is too coupled with other code. That is more closer to literal death by one cut. You are technically unable to meet requirements with existing code.

The modular primitive that prevents this from happening is the immutable pure function. But it's not a one size fits all solution.

Post reply on HN