Is FROOP a thing? Cos that’s what I’m doing it seems.
OOP Is Dead, Long Live OOP
61–70 of 357 posts
Re: OOP Is Dead, Long Live OOP
#62If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.
I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…
Frankly, having User inherit from DBMapper is way more egregious in my eyes than Sword inheriting from Weapon.
It doesn't really matter because both of these things can be better solved using composition + traits/interfaces anyways.
Re: OOP Is Dead, Long Live OOP
#63I think OOP is fine as long as it's the only thing you are doing and as long as it is single-threaded.
Problems will occur if you need to convert the innards of your objects to data (i.e. JSON etc.), if you need to materialize objects from data (i.e. ORM) or if you need to write multi-threading safe code.
If you expose things as data, just be honest about it and treat it as such. It's already out in the open, why hide it in objects again?
Re: OOP Is Dead, Long Live OOP
#64Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it. Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. H…
DI is bad, what? So how are you writing tests then.
Re: OOP Is Dead, Long Live OOP
#65I’d be very wary of hiring an ”OO” dev who can’t reasonably formulate what the SOLID principles are and why they exist.
Depends on what this dev would be building, if you have to build framework or you build a library then I agree. If you build next off the mill "business" system then... Single responsibility principle, yes nice but we have deadlines and no time to argue if that one function should be somewhere else, fix it when we have some slack. Open closed principle, you don't have to think about if you use DI and have interfaces.…
> Liskov substitution is useless, you should not use inheritance but composition.
Liskov substitution is more about interface inheritance than implementation inheritance, really. LSP basically says that the implementer of an interface must obey the contract the interface specifies. As a real-world example, throwing UnsupportedOperationException in a method implementation is an LSP violation. Of course, this makes it vital to get the interfaces themselves right, carving the solution space at its joints.
Re: OOP Is Dead, Long Live OOP
#66If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.
I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…
"adds nothing over mixins otherwise."
The funny thing is that languages like C# and Java abandoned mixins but kept deep inheritance hierarchies. When I did C++ more we used multiple inheritance a lot but with only one or two layers deep. This worked extremely well and now that that I am doing more in C# I miss it a lot.
Re: OOP Is Dead, Long Live OOP
#67Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it. Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. H…
The thing I love about OOA/D/P is that it is a useful and productive way of thinking about things. It's probably even the most natural and intuitive way of thinking about them. Plato wasn't a C++ programmer, but classes and interfaces are direct descendants of his work 2k+ years ago.
When I first fell in love with OO there was a time that I felt that there wasn't a problem in the world I couldn't solve using it. That moment it finally "clicked", and all the lights came on? Wow! One of the best intellectual experiences of my life. It changed everything.
I was right about being able to do anything with it. What I was wrong about was how some things are more difficult than others. Rules-based systems, for instance, get abstracted away into a sort of gobbledygook in OO. Scripting is uglier than it should be.
Then I had a similar realization about FP. It took much, much longer and there was no dramatic moment, but the impact was just as huge. It was a new way of thinking about and solving problems. It has it's own edge cases and antipatterns, of course, just like OO.
I wonder what the next A-Ha! change will be? TLA+? Is there a system of thinking around morals and values as it applies to problem solving, as Kant and others thought? Beats me. I hope I get to find out.
Re: OOP Is Dead, Long Live OOP
#68I’d be very wary of hiring an ”OO” dev who can’t reasonably formulate what the SOLID principles are and why they exist.
Do they have to agree with them, or just be able to name them?
Well, it's definitely a plus if they can convincingly argue against any of them. They're tools, not dogma.
Re: OOP Is Dead, Long Live OOP
#69Earlier quoted context omitted.
It refers to Entity-Component-System, an architectural design pattern (like Model-View-Controller) that uses composition instead of inheritance to define the behavior of entities in a simulation.
> that uses composition instead of inheritance What they are referring to as ECS is more than just composition over inheritance. There are entity component architectures that are just that--Unity's existing class based component architecture for example. But the ECS in this case refers to Data Oriented Design--basically laying out data like normalized database tables. Every component system has a table, and each row…
The confusing thing about the name “Entity Component System” is that “System” is thing in ECS. It’s not a system of Entities and Components, it’s a pattern thay has three parts; Entities, Components, and Systems.
Re: OOP Is Dead, Long Live OOP
#70Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it. Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. H…
DI is an essential feature of functional programming, and it's incredibly simple to understand. You're real issue is that OOP is a terrible, broken model that can only model a pattern like DI with a high degree of complexity.