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

31–40 of 99 posts

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

#31

Post by ratww »

Zababa wrote: post #22
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...

Records seems very nice! What I wonder is if people are going to use them, considering Java is a bit old at this point and lots of code already exists. Refactoring to use object would be a heavy cost. Maybe some new framework and ecosystems will appear based on new features of Java?

Refactoring to use them is not really hard, as they are easily interchangeable with regular classes. They are pretty much syntax sugar for this class pattern here: https://stackoverflow.com/a/63615514

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

#32

Post by sam0x17 »

deltasixeight wrote: post #30
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.

No hacking code to pieces makes it more complex. The trade off here is that the code becomes more modular. Whether you want your code to be more modular is an opinionated decision but most people don't realize the benefits of high modularity. Almost all major design mistakes that necessitate code rewrites come from lack of modularity.

There are also a lot of cases where people "modularize" code without actually modularizing it --- they extract certain functions into separate modules or files just to break up the current file, but that new module they've created can't function or do anything on its own outside of the context it was extracted from. So in these cases they've really obfuscated the code in the name of "modularization", but the code is no more modular than it was before -- it's just more obfuscated.

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

#33

Post by ratww »

Zababa wrote: post #27
gnabgib wrote: post #23

Earlier quoted context omitted.

C# too, a very handy types https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

What are the tradeoffs between records and structs?

The biggest difference is that Records are Immutable.

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

#34

Post by felipemnoa »

josephg wrote: post #5

This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…

>>In Java it would be a nest of SortComparator interfaces and SortAlgorithm implementors, which would act to hide the algorithm itself.

Java developer here, no such thing. I guess it varies based on who is doing the coding. Although, I did start out as a C developer.

I would only write code like that if the use-case called for it. Otherwise, no.

Writing code is more of an art form, some times you may need to do crazy stuff like that, but a lot of times not.

KISS

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

#35

Post by neutronicus »

dgb23 wrote: post #9
josephg wrote: post #5

This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…

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

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

#36

Post by n0w »

josephg wrote: post #5

This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…

Personally, I don't think it has anything to do with being embarrassed about dense logic. I think it's about a love of abstractions.

Many developers get trapped trying to recognize patterns and come up with perfect mental models for whatever problem they're trying to solve when the straight forward dense function is probably the simpler and more maintainable solution. I often fall for this trap myself and am constantly trying to be wary of it.

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

#37

Post by theteapot »

Zababa wrote: post #26
theteapot wrote: post #25

Earlier quoted context omitted.

Article's stated motivation: > I'm looking to gain more confidence in my criticism and understanding of OOP. In the past, I have published multiple posts criticizing Object Oriented Programming ... I always feel this anxiety that... maybe there is such a thing as “good OOP”, maybe all the OOP code I wrote, and the OOP code I keep seeing here and there is just “incorrect OOP”. To that I'm saying read DP and critique t…

Again, I'm saying that I think DP isn't a good idea because DP is about how to solve problems using OOP and not why OOP is a good idea in the first place.

I don't think you can separate the two. To understand whether OOP is a good idea you need to understand how it's used to solve software problems.

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

#38

Post by Zababa »

theteapot wrote: post #37
Zababa wrote: post #26

Earlier quoted context omitted.

Again, I'm saying that I think DP isn't a good idea because DP is about how to solve problems using OOP and not why OOP is a good idea in the first place.

I don't think you can separate the two. To understand whether OOP is a good idea you need to understand how it's used to solve software problems.

I don't think those are the same "problems". "Design patterns" is about code, not solving business problems. To stay in the well known books in OOP, DDD would be about solving business problems.

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

#39

Post by Zababa »

ratww wrote: post #31
Zababa wrote: post #22

Earlier quoted context omitted.

Records seems very nice! What I wonder is if people are going to use them, considering Java is a bit old at this point and lots of code already exists. Refactoring to use object would be a heavy cost. Maybe some new framework and ecosystems will appear based on new features of Java?

Refactoring to use them is not really hard, as they are easily interchangeable with regular classes. They are pretty much syntax sugar for this class pattern here: https://stackoverflow.com/a/63615514

That's true, but that's still a large refactoring to do, especially with going from mutability to immutability. The community might also just not like them.

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

#40

Post by lostcolony »

sam0x17 wrote: post #32
deltasixeight wrote: post #30

Earlier quoted context omitted.

No hacking code to pieces makes it more complex. The trade off here is that the code becomes more modular. Whether you want your code to be more modular is an opinionated decision but most people don't realize the benefits of high modularity. Almost all major design mistakes that necessitate code rewrites come from lack of modularity.

There are also a lot of cases where people "modularize" code without actually modularizing it --- they extract certain functions into separate modules or files just to break up the current file, but that new module they've created can't function or do anything on its own outside of the context it was extracted from. So in these cases they've really obfuscated the code in the name of "modularization", but the code is…

Right; breaking it up doesn't necessarily make it more modular, it just necessarily spreads it around. This is -a bad thing-, with no other context. The hope is that it modularizes the code enough to enable better understanding/reuse/extension (thus being a necessary evil).
Post reply on HN