Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The methodologies we use fall victim to the same tendency. We build complex, rigid rule sets that are claimed to improve software or development speed or whatever else, without any actual empirical evidence that these claims are true. All you can really do is try to…
OOP Is Dead, Long Live OOP
91–100 of 357 posts
Re: OOP Is Dead, Long Live OOP
#92If 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.
Inheritance is very useful especially in game programming (in context of OP), and hardly ever anywhere else. In games it's useful to be able to pass around references to an object or have systems that manage pools of objects at exactly the hierarchy of inheritance that makes the most sense for the manager of that system. Not many other applications need to pass around objects between various hierarchical management systems as much.
I think inheritance shouldn't be taught in intro-level programming classes. It's presented as "how to do all things in OOP, shove all the things into multi-level child classes" when really it should be "here's an advanced concept for situational architecture optimization". It defeats the purpose when you do multiple levels of inheritance and no longer ever use the parent classes for anything.
Re: OOP Is Dead, Long Live OOP
#93Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The methodologies we use fall victim to the same tendency. We build complex, rigid rule sets that are claimed to improve software or development speed or whatever else, without any actual empirical evidence that these claims are true. All you can really do is try to…
The full quote by Einstein is: “Make things as simple as possible, but not simpler.” I think the second part is important to not overshoot.
Re: OOP Is Dead, Long Live OOP
#94I 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 hid…
Yet, there is a well-known pattern, which is to have objects each running on its own thread. (Incidentally, this gives a new - I'd say, true - meaning to the notion of 'message passing' as the idea of how objects are to communicate.)
Re: OOP Is Dead, Long Live OOP
#95If 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.
But let's be serious for a minute here: even regular inheritance has hardly ever led to the kind of nuclear disaster than most pundits claim.
It makes your code base a bit more unwieldy and a bit harder to evolve, but it's really not the end of the world.
Re: OOP Is Dead, Long Live OOP
#96Earlier quoted context omitted.
DI is bad, what? So how are you writing tests then.
Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.
Re: OOP Is Dead, Long Live OOP
#97OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it ma…
Bits are objects, too...
Re: OOP Is Dead, Long Live OOP
#98If 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…
And in defense of inheritance, the Liskov Substitution Principle is extremely useful and makes a lot of sense.
If a function accepts a `Weapon` as parameter, surely you should be able to pass it a `Sword`.
Re: OOP Is Dead, Long Live OOP
#99OOP provides competing ways of abstracting behavior that in Haskell we can model with type parameters and constraints. Objects are not truly encapsulated in the way Erlang processes are and a poor fit for SMP. Objects also pathologically hide data in attempt to manage mutability, making it impossible to reason about the memory layout of the program.
All in all, OOP is a toolkit for building bad abstractions: abstractions that do not easily model computation, that hide data, and has tended to create overly complex solutions to problems that are often full of errors that a language focused more on type expressivity could catch at compile time.
Re: OOP Is Dead, Long Live OOP
#100Earlier quoted context omitted.
Even Solid, like OOP is one of those concepts that has morphed more into an ideology than it needs to be with blind faith adherents https://speakerdeck.com/tastapod/why-every-element-of-solid-... I'll take someone who writes simple code that can be easily changed 101 out of 100 times over a SOLID, OOP Adherent.
That presentation basically says "write simple code". I'm not sure how is that helpful to anyone.
Stuck in a rut designing your type hierarchies and making sure they are perfectly SOLID? STOP. Write the simplest, most clear and concise thing that works, refactor it once it gets too big to fit in your head.
Not sure if your AbstractFactoryBeanProxyImplImpl is generic enough to cover all use cases? STOP. Write the simplest most clear and concise thing that works, refactor it to adapt to more problems as needed.
Tired of fighting your type system because your stuck in a wheel of is-ha has-a is-a has-a? STOP. If it acts like a duck, and quacks like a duck, it is a duck! Write a duck!