51–60 of 119 posts
Earlier quoted context omitted.
Inheritance is just the unnecessary coupling of composition and polymorphism.
Delegation is a very useful part of composition. Almost all OOP languages have two techniques to delegate some methods to another object: - manually write a bunch of forwarding methods and remember to keep them updated, or - inheritance.
Earlier quoted context omitted.
Service classes are the thing I hate most. They’re just namespaces for functions. They’re a product of Java not being able to have top level functions.
Not being able to have top level functions is a feature, not a bug. You can declare static methods on interfaces in Java, which means you could call things like Users.create("Foobar") if you wanted to.
Users.create(...) is the easy case. Try transfer_permissions(user1, user2, entity) while retaining transactionality and the ability of either user to cancel the transfer.
Earlier quoted context omitted.
Not being able to have top level functions is a feature, not a bug. You can declare static methods on interfaces in Java, which means you could call things like Users.create("Foobar") if you wanted to.
Not everything can be associated to a single entity. Many operations work on two or more entities where none of them are the "master". Otherwise you end up with "coordinators". Users.create(...) is the easy case. Try transfer_permissions(user1, user2, entity) while retaining transactionality and the ability of either user to cancel the transfer.
I'm not sure why having a global function by the same would make this any easier or harder to implement. But it would pollute the global namespace with highly specific operations.
Earlier quoted context omitted.
Not being able to have top level functions is a feature, not a bug. You can declare static methods on interfaces in Java, which means you could call things like Users.create("Foobar") if you wanted to.
It is not a feature. Every programming language since has decided this was a mistake.
Earlier quoted context omitted.
Object orientism is just encapsulation. It’s the only thing that is required. You can have objects without inheritance and virtual dispatch.
So Python is not OOP language? You can't hide fields.
class EncapsulatedCounter:
def __init__(self, initial_value):
_count = initial_value
def increment():
nonlocal _count
_count += 1
return _count
self.increment = increment
counter = EncapsulatedCounter(100)
new_value = counter.increment()
print(f"New value is: {new_value}")Earlier quoted context omitted.
Not everything can be associated to a single entity. Many operations work on two or more entities where none of them are the "master". Otherwise you end up with "coordinators". Users.create(...) is the easy case. Try transfer_permissions(user1, user2, entity) while retaining transactionality and the ability of either user to cancel the transfer.
Permissions.transfer(x, y, z) I'm not sure why having a global function by the same would make this any easier or harder to implement. But it would pollute the global namespace with highly specific operations.
There has been different terms and meaning to it - but we all know the "OOP" thrown about since the mid-to-late 90s is the Java way.
A typical Java book back then would have 900 pages.. half of which is explaining OOP. While not focusing fully on Java, it does help transition that knowledge over to Delphi or C++ or.. eventually.. C#, etc.
Overall -- we all knew what "Must have good OOP skills" means on a job advert! Nobody was confused thinking "Oh.. I wonder which OOP they mean?"
I have a love/hate relationship with OOP. If I have to use a language that is OOP by default then I use it reasonably. While the built in classes will have theor own inheritence -- I tend to follow a basic rule of no higher that 2. Most of the time it is from an interface. I prefer composition over inheritence.
In C#, I use static classes a fair bit. In this case, classes are helpful to organise my methods. However, I could do this at a namespace level if I could just create simple functions -- not wrapped inside a class.
OOP has its place. I prefer to break down my work with interfaces. Being able to use to correct implementation is better than if/switch statements all over the place. However, this can be achieved in non OOP languages as well.
I guess my point is that OOP was shoved heavily back in the day. It was shutup and follow the crowd. It still has it's place in certain scenarios - like GUI interfaces.
Earlier quoted context omitted.
Even before I got to the point where I decided I didn't like inheritance, I distinctly recall having conversations about how I felt that using inheritance for anything other than polymorphism didn't usually end up with particularly clean code. I can remember a conversation about this at least as far back as the summer after my freshman year of college, and I don't think I was aware of the idea of "composition" yet, b…
Out of curiosity, when you say you don't like inheritance, does that mean you never use it at all, or you only use it rarely? Because even though inheritance often is used in a wrong way, there are definitely cases, where it is the clearest pattern in my opinion. Like graphic libary things. E.g. everything on the screen is a DisplayObject. Simple Textfields and Images inherit directly from DisplayObject. Layoutcontai…
What value does the inheritance provide here?
Can't you just use a flat interface per usecase without inheritance and it will work simpler with less mental overhead keeping the hierarchy in mind?
Explicitly your graphic library sounds should be fine to have the interface DisplayObject which you can then add default implementations on. (That's a form of composition)
Earlier quoted context omitted.
It is not a feature. Every programming language since has decided this was a mistake.
Can you provide an example of that?
OO conflates many different aspects that are often orthogonal but have been conflated together opportunistically rather than by sound rigor. Clearly most languages allow for functions outside classes. It's clearly the case today especially with FP gaining momentum, but it's also clear back then when Java and the JVM were created. I think smalltalk was the only other language that had this limitation.
Like others in this thread, I can only recommend the big OOPS video: https://youtu.be/wo84LFzx5nI