3 ms·

UML was bound to OO design methodologies that really didn't work that well (any time you have a vaguely specified component with "manager" in its name it is lik

UML was bound to OO design methodologies that really didn't work that well (any time you have a vaguely specified component with "manager" in its name it is likely someone was following one of them and, usually, an example of Conway's law). It was also bound to CASE tools that few could afford, fewer could master, and that I've never seen used well, so I couldn't say if they worked or not. And then, of course, Agile happened and designing anything became uncool and unpopular. I hadn't thought to critique the visual design of UML but it is just about impossible to pick up a UML diagram after a year of doing other things and remember the particular semantics of them above the whiteboard box-and-arrow level. So I think you're right and there's probably opportunity for someone who loves that kind of thing there. Also I thought I was the only one who thought use-case diagrams were absolutely absurd. At the employer where I saw UML and got actually pretty good but brief training on it, we had a VB plug-in for Rose that would extract the text from them into... a Word document. That said, UML statecharts are pretty great, the tools for them look OK though I've never done statechart design that way, and I appreciate seeing a sequence diagram for nontrivial protocols/exchanges/calling conventions.

0x445442 4y ago
> any time you have a vaguely specified component with "manager" in its name This seems to be a limitation of class based OOD and the absence of free standing functions. There needs to be a place for code to exist which operates on disparate data types and structures. I’ve found that creating singletons that replace the word Manager/Utility with Lib doesn’t offend the sensibilities as much.
- buescher 4y ago
  Yes - to be clear, the limitation is the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it. Should it be this object? No, it should be a different object. What should we call it? Yes, I was making a funny about Conway's law, but that's the point you shrug and say "call it pointAToPointBConnectionManager".
  - zozbot234 4y ago
    > the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it. That's not necessarily a bad notion, though. It's pretty much the definition of a capability, which is an important concept when designing for modularity.

0x445442 4y ago

> any time you have a vaguely specified component with "manager" in its name This seems to be a limitation of class based OOD and the absence of free standing functions. There needs to be a place for code to exist which operates on disparate data types and structures. I’ve found that creating singletons that replace the word Manager/Utility with Lib doesn’t offend the sensibilities as much.

buescher 4y ago
Yes - to be clear, the limitation is the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it. Should it be this object? No, it should be a different object. What should we call it? Yes, I was making a funny about Conway's law, but that's the point you shrug and say "call it pointAToPointBConnectionManager".
- zozbot234 4y ago
  > the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it. That's not necessarily a bad notion, though. It's pretty much the definition of a capability, which is an important concept when designing for modularity.