6 ms·

My general take (and w/ the caveat that every system is different) is as follows: - procedural code to enter into the system (and perhaps that's all you need)

My general take (and w/ the caveat that every system is different) is as follows: - procedural code to enter into the system (and perhaps that's all you need) - object oriented code for domain modeling - functional code for data structure transformations & some light custom control flow implementation (but not too much) I like the imperative shell, functional core pattern quite a bit, and focusing on data structures is great advice as well. The anti-OO trend in the industry has been richly earned by the OO architecture astronauts[1], but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling. In general I think we are maturing as an industry, recognizing that various approaches have their strengths and weaknesses and a good software engineer can mix and match them when building a successful software project. There is no silver bullet. If only someone had told us that years ago! [1] - https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

kingofthehill98 2y ago
That's the strategy I always take when designing a system. Funny that I never thought about it before, I think most PHP developers will relate to that aswell. - Procedural single point entrance into the system (network -> public/index.php, cli -> bin/console) - OOP core for business logic, heavily borrowed (copied) from Java OOP model - Functional code inside classes/methods whenever possible (callables/closures, array_map/filter/reduce/walk, illuminate/collections, etc.)
bunderbunder 2y ago
OO code for domain modeling might be, to date, the single greatest source of disillusionment in my career. There are absolutely use cases where it works very well. GUI toolkits come to mind. But for general line-of-business domain modeling, I keep noticing two big mismatches between the OO paradigm and the problem at hand. First and foremost, allowing subtyping into your business domain model is a trap. The problem is that your business rules are subject to change, you likely have limited or even no control over how they change, and the people who do get to make those decisions don't know and don't care about the Liskov Substitution Principle. In short, using one of the headline features of OOP for business domain modeling exposes you to outsize risk of being forced to start doing it wrong, regardless of your intentions or skill level. (Incidentally, this phenomenon is just a specific example of premature abstraction being the root of all evil.) And then, second, dynamic dispatch makes it harder for newcomers to figure out the business logic by reading the code. It creates a bit of a catch-22 situation where figuring out which methods will run when - an essential part of understanding how the code behaves - almost requires already knowing how the code works. Not actually, of course, but reading unfamiliar code that uses dynamic dispatch is and advanced skill, and nobody enjoys it. Also, this problem can easily be mitigated with documentation. But that solution is unsatisfying. Just using procedural code and banging out whatever boilerplate you need to get things working using static dispatch creates less additional work than what it takes to write and maintain satisfying documentation for an object-oriented codebase, and comes with the added advantage that it cannot fall out of sync with what the code actually does. Incidentally, Donald Knuth made a similar observation in his interview in the book Coders at Work. He expressed dissatisfaction with OOP on the grounds that, for the purposes of maintainability, he found code reuse to be less valuable than modifiability and readability.
- sqeaky 2y ago
  This is a strong argument against inheritance, but that isn't everything about OOP. Just one well supported advanced abstraction (That I would also argue should be rarely used.) I would argue that just having strong type system and bundling methods with data gets you the vast majority of the usefulness of OOP. Liskov, Open/Closed, Message Passing, and other theoretical abstractions be damned. EDIT - Where are the good places to use inheritance? There are only a few I can think. One is when you are trying to create a system that inverts dependencies by allowing a plugin system or follows some sort of nuanced workflow that others might want to "hook into". But that isn't the only way to do that, maybe other ways would be better like passing in functors. Another situation I have seen recently is when creating a kind of data or messages that differ only by type and maybe a few small pieces of behavior and they are all known up front.
  - moth-fuzz 2y ago
    > One is when you are trying to create a system that inverts dependencies by allowing a plugin system or follows some sort of nuanced workflow that others might want to "hook into". I’m fairly certain that’s the use case of inheritance - at least in the Simula tradition. Classes as a means of lifetime management, moving parts that have well defined steps of operation (methods), and interchangeable parts (subtypes) which you can more or less slot into the larger system (polymorphism). It’s easier to think about classes not as nouns, but as verbs over time (or rather, bounded by time): at a specific moment in the assembly line, call this particular method, at another moment, call that other method… Object oriented programming in the Simula tradition I would even go as far as to say is just best practices in structured/procedural programming taken to their logical extremes.
    - jancsika 2y ago
      > Classes as a means of lifetime management Wrt plugin systems: at least as the class level, are classes really a means of lifetime management in practice? IIRC, audio plugin APIs follow the shell command pattern of memory management for loading new classes-- the user dynamically loads a library into a running instance of an application, and there it stays until the application exits. And even if plugin systems as implemented are actually unloading classes, the user is almost always just restarting the app to make sure it took. :) Edit: clarification
deleted 2y ago
[deleted]
sqeaky 2y ago
I hadn't thought about it explicitly like this before, and I think I agree. My more nebulous thought process was something like: 1. Try to solve the problem purely functionally. 2. If that failed because of data issue, model the data with objects and simple operations in an OOP style or well thought collection of arrays (game devs answer to OOP causing memory and caching problems, but the end result programming is similar to OOP thought process) 3. If that is can't happen because some external restriction is impose use the minimal amount of procedural logic to solve the problem and round off as many sharp corners as is practical until it is unlikely any on the team gets cut. Logically that is very close to inversion of thought process and ordering of operations to what you suggested. But I think we would recognize each others attempts to pick a design paradigm in code. Now I want to think about this more. Is there some underlying principle here? Is this some kind of underlying principle? Where do domain specific languages fit in? Do other paradigms fit in? What are the bounds of this pattern, where does this process fail?
epgui 2y ago
If you think OOP is particularly well-suited to domain modelling, you should try the FP approach to domain modelling. You will never be able to unsee the complexity inherent to OOP.
- jprete 2y ago
  Do you happen to have a link to an example or explanation?
  - arendjr 2y ago
    The keyword to search for is algebraic data types, which are common in functional languages, but for instance Rust also has them. Here is an example comparing C# with F#, where the latter also algebraic data types: https://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-types/ https://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-...
    - neonsunset 2y ago
      The syntax has improved quite substantially since 2016 for pattern matching at C#'s end, and it's very easy to model ADTs with records (and the experience of using them even before that was decent with methods accepting lambdas). Today, you write it in a similar way you would write a match in Rust.
      - nequo 2y ago
        How do you represent sum types in C# today? Can enum members hold records as data, or do you do it differently?
  - epgui 2y ago
    The other commenter is not technically wrong to point at “algebraic data types”, but I don’t think that answer is helpful at all. It’s like saying the answer to data modelling is tuples. I would instead recommend searching for “functional programming and domain driven design”.
  - 2y ago
Dwedit 2y ago
When you write a procedure that has to maintain an internal state between calls, changing it into a class makes sense. As for the name, you change the verb (write) into a noun (writer), and you now have a name for the class. C# will silently create hidden closure classes for you when you use lambdas or yield.
- arendjr 2y ago
  Just know that if you do this, you’re injecting statefulness in the center of wherever it was this procedure was being used. If your entire system already has statefulness everywhere, nobody will bet an eye. But if you want to have any chance at creating a functional core or island, it’s the opposite of what you should be doing.
- alex-robbins 2y ago
  When you write a procedure that has to maintain an internal state between calls, stopping what you're doing and switching to functional programming makes sense.
gwbas1c 2y ago
> These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace. No, Microsoft, computers are not suddenly going to start reading our minds and doing what we want automatically just because everyone in the world has to have a Passport account. Priceless.
dgb23 2y ago
> object oriented code for domain modeling I'm not sure about that. If we're talking about IT (information processing in general), then the domain model is just data representing facts and should probably be treated as that, and not some metaphorical simulation of the world. I've come up with a pretty useful test for when to apply OO: When you need to model a _computational unit_[0] in terms of _operational semantics_, then use OO. [0] Decidedly _not_ a simulation of a metaphor for the "real world". --- Examples: A resizable buffer: You want operations like adding, removing, preemptively resizing etc. on a buffer. It's useless to think of the internal bookkeeping of a buffer that is represented in its data structure when you use it. A database object: It wraps a driver, a connection pool etc. From the outside you want to configure it at the start, then you want to interact with it via operations. A HTTP server: You send messages to it via HTTP methods, you don't care about it's internal state, but only about your current representation of it (HATEOAS) and what you can do with it. A memory allocator: The name gives away that you can _do_ things with it. You first choose the allocator that fits your needs, but then you _operate_ on it via alloc/free etc. --- Some of us wince when we hear "OO", because it has been an overused paradigm. Some advocates of OO have been telling us that it is somehow total (similar to FP advocates) and people have been pushing back on this for a while now. When applied to information processing especially, it becomes ridiculous, complex and distracting. I call this "Kindergarten OO": You to write code as if you explain the problem to a child via metaphors. Computational objects however arise naturally and are very obvious. I don't care if those are encoded as classes, with closures or if we syntactically pretend as if they aren't objects. They are still objects.
mejutoco 2y ago
> but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling. One can do this in a module without OOP. The idea of mixing data and behaviour/state (OOP) instead of keeping data structure and functions transforming those (functional) is IMO the biggest mistake of OOP, together with using inheritance. I believe making part of the program data instead of code (and thus, empty of bugs) is such a big advantage. Already lisp was talking about it. Mixing data with behaviour, without a clear delimitation creates a tight-coupled implementation full of implicit assumptions. Outside the class things are clean, but inside they ossify, and grow in complexity. Pure functions with data in data out are such a big improvement in clarity when possible.
NomDePlum 2y ago
James Gosling, who I'd consider the father of one of the most popular OO languages gave this advice: "You should avoid implementation inheritance whenever possible" My early days of Java where largely building unmaintainable inheritance trees into my code and then regretting it. This quote gave me comfort that it wasn't really that good an idea. Decent discussion on inheritance Vs composition also found here: https://en.m.wikipedia.org/wiki/Composition_over_inheritance https://en.m.wikipedia.org/wiki/Composition_over_inheritance
voidhorse 2y ago
Look, I'm going to catch flak for this but at the end of the day the main problem is that Java and C++, the most popular OOP languages, are just bad programming languages. There are OOP languages out there, most of them older than Java and C++, that actually provide a much better set of knobs and handles for writing sane OO programs. Java is finally getting a bit better thanks to a lot of market pressure and good ideas from Kotlin. C++ will probably be a mess forever.

kingofthehill98 2y ago

That's the strategy I always take when designing a system. Funny that I never thought about it before, I think most PHP developers will relate to that aswell. - Procedural single point entrance into the system (network -> public/index.php, cli -> bin/console) - OOP core for business logic, heavily borrowed (copied) from Java OOP model - Functional code inside classes/methods whenever possible (callables/closures, array_map/filter/reduce/walk, illuminate/collections, etc.)

bunderbunder 2y ago

OO code for domain modeling might be, to date, the single greatest source of disillusionment in my career. There are absolutely use cases where it works very well. GUI toolkits come to mind. But for general line-of-business domain modeling, I keep noticing two big mismatches between the OO paradigm and the problem at hand. First and foremost, allowing subtyping into your business domain model is a trap. The problem is that your business rules are subject to change, you likely have limited or even no control over how they change, and the people who do get to make those decisions don't know and don't care about the Liskov Substitution Principle. In short, using one of the headline features of OOP for business domain modeling exposes you to outsize risk of being forced to start doing it wrong, regardless of your intentions or skill level. (Incidentally, this phenomenon is just a specific example of premature abstraction being the root of all evil.) And then, second, dynamic dispatch makes it harder for newcomers to figure out the business logic by reading the code. It creates a bit of a catch-22 situation where figuring out which methods will run when - an essential part of understanding how the code behaves - almost requires already knowing how the code works. Not actually, of course, but reading unfamiliar code that uses dynamic dispatch is and advanced skill, and nobody enjoys it. Also, this problem can easily be mitigated with documentation. But that solution is unsatisfying. Just using procedural code and banging out whatever boilerplate you need to get things working using static dispatch creates less additional work than what it takes to write and maintain satisfying documentation for an object-oriented codebase, and comes with the added advantage that it cannot fall out of sync with what the code actually does. Incidentally, Donald Knuth made a similar observation in his interview in the book Coders at Work. He expressed dissatisfaction with OOP on the grounds that, for the purposes of maintainability, he found code reuse to be less valuable than modifiability and readability.

sqeaky 2y ago
This is a strong argument against inheritance, but that isn't everything about OOP. Just one well supported advanced abstraction (That I would also argue should be rarely used.) I would argue that just having strong type system and bundling methods with data gets you the vast majority of the usefulness of OOP. Liskov, Open/Closed, Message Passing, and other theoretical abstractions be damned. EDIT - Where are the good places to use inheritance? There are only a few I can think. One is when you are trying to create a system that inverts dependencies by allowing a plugin system or follows some sort of nuanced workflow that others might want to "hook into". But that isn't the only way to do that, maybe other ways would be better like passing in functors. Another situation I have seen recently is when creating a kind of data or messages that differ only by type and maybe a few small pieces of behavior and they are all known up front.
- moth-fuzz 2y ago
  > One is when you are trying to create a system that inverts dependencies by allowing a plugin system or follows some sort of nuanced workflow that others might want to "hook into". I’m fairly certain that’s the use case of inheritance - at least in the Simula tradition. Classes as a means of lifetime management, moving parts that have well defined steps of operation (methods), and interchangeable parts (subtypes) which you can more or less slot into the larger system (polymorphism). It’s easier to think about classes not as nouns, but as verbs over time (or rather, bounded by time): at a specific moment in the assembly line, call this particular method, at another moment, call that other method… Object oriented programming in the Simula tradition I would even go as far as to say is just best practices in structured/procedural programming taken to their logical extremes.
  - jancsika 2y ago
    > Classes as a means of lifetime management Wrt plugin systems: at least as the class level, are classes really a means of lifetime management in practice? IIRC, audio plugin APIs follow the shell command pattern of memory management for loading new classes-- the user dynamically loads a library into a running instance of an application, and there it stays until the application exits. And even if plugin systems as implemented are actually unloading classes, the user is almost always just restarting the app to make sure it took. :) Edit: clarification

deleted 2y ago

[deleted]

sqeaky 2y ago

I hadn't thought about it explicitly like this before, and I think I agree. My more nebulous thought process was something like: 1. Try to solve the problem purely functionally. 2. If that failed because of data issue, model the data with objects and simple operations in an OOP style or well thought collection of arrays (game devs answer to OOP causing memory and caching problems, but the end result programming is similar to OOP thought process) 3. If that is can't happen because some external restriction is impose use the minimal amount of procedural logic to solve the problem and round off as many sharp corners as is practical until it is unlikely any on the team gets cut. Logically that is very close to inversion of thought process and ordering of operations to what you suggested. But I think we would recognize each others attempts to pick a design paradigm in code. Now I want to think about this more. Is there some underlying principle here? Is this some kind of underlying principle? Where do domain specific languages fit in? Do other paradigms fit in? What are the bounds of this pattern, where does this process fail?

epgui 2y ago

If you think OOP is particularly well-suited to domain modelling, you should try the FP approach to domain modelling. You will never be able to unsee the complexity inherent to OOP.

jprete 2y ago
Do you happen to have a link to an example or explanation?
- arendjr 2y ago
  The keyword to search for is algebraic data types, which are common in functional languages, but for instance Rust also has them. Here is an example comparing C# with F#, where the latter also algebraic data types: https://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-types/ https://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-...
  - neonsunset 2y ago
    The syntax has improved quite substantially since 2016 for pattern matching at C#'s end, and it's very easy to model ADTs with records (and the experience of using them even before that was decent with methods accepting lambdas). Today, you write it in a similar way you would write a match in Rust.
    - nequo 2y ago
      How do you represent sum types in C# today? Can enum members hold records as data, or do you do it differently?
- epgui 2y ago
  The other commenter is not technically wrong to point at “algebraic data types”, but I don’t think that answer is helpful at all. It’s like saying the answer to data modelling is tuples. I would instead recommend searching for “functional programming and domain driven design”.
- 2y ago

Dwedit 2y ago

When you write a procedure that has to maintain an internal state between calls, changing it into a class makes sense. As for the name, you change the verb (write) into a noun (writer), and you now have a name for the class. C# will silently create hidden closure classes for you when you use lambdas or yield.

arendjr 2y ago
Just know that if you do this, you’re injecting statefulness in the center of wherever it was this procedure was being used. If your entire system already has statefulness everywhere, nobody will bet an eye. But if you want to have any chance at creating a functional core or island, it’s the opposite of what you should be doing.
alex-robbins 2y ago
When you write a procedure that has to maintain an internal state between calls, stopping what you're doing and switching to functional programming makes sense.

gwbas1c 2y ago

> These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace. No, Microsoft, computers are not suddenly going to start reading our minds and doing what we want automatically just because everyone in the world has to have a Passport account. Priceless.

dgb23 2y ago

> object oriented code for domain modeling I'm not sure about that. If we're talking about IT (information processing in general), then the domain model is just data representing facts and should probably be treated as that, and not some metaphorical simulation of the world. I've come up with a pretty useful test for when to apply OO: When you need to model a _computational unit_[0] in terms of _operational semantics_, then use OO. [0] Decidedly _not_ a simulation of a metaphor for the "real world". --- Examples: A resizable buffer: You want operations like adding, removing, preemptively resizing etc. on a buffer. It's useless to think of the internal bookkeeping of a buffer that is represented in its data structure when you use it. A database object: It wraps a driver, a connection pool etc. From the outside you want to configure it at the start, then you want to interact with it via operations. A HTTP server: You send messages to it via HTTP methods, you don't care about it's internal state, but only about your current representation of it (HATEOAS) and what you can do with it. A memory allocator: The name gives away that you can _do_ things with it. You first choose the allocator that fits your needs, but then you _operate_ on it via alloc/free etc. --- Some of us wince when we hear "OO", because it has been an overused paradigm. Some advocates of OO have been telling us that it is somehow total (similar to FP advocates) and people have been pushing back on this for a while now. When applied to information processing especially, it becomes ridiculous, complex and distracting. I call this "Kindergarten OO": You to write code as if you explain the problem to a child via metaphors. Computational objects however arise naturally and are very obvious. I don't care if those are encoded as classes, with closures or if we syntactically pretend as if they aren't objects. They are still objects.

mejutoco 2y ago

> but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling. One can do this in a module without OOP. The idea of mixing data and behaviour/state (OOP) instead of keeping data structure and functions transforming those (functional) is IMO the biggest mistake of OOP, together with using inheritance. I believe making part of the program data instead of code (and thus, empty of bugs) is such a big advantage. Already lisp was talking about it. Mixing data with behaviour, without a clear delimitation creates a tight-coupled implementation full of implicit assumptions. Outside the class things are clean, but inside they ossify, and grow in complexity. Pure functions with data in data out are such a big improvement in clarity when possible.

NomDePlum 2y ago

James Gosling, who I'd consider the father of one of the most popular OO languages gave this advice: "You should avoid implementation inheritance whenever possible" My early days of Java where largely building unmaintainable inheritance trees into my code and then regretting it. This quote gave me comfort that it wasn't really that good an idea. Decent discussion on inheritance Vs composition also found here: https://en.m.wikipedia.org/wiki/Composition_over_inheritance https://en.m.wikipedia.org/wiki/Composition_over_inheritance

voidhorse 2y ago

Look, I'm going to catch flak for this but at the end of the day the main problem is that Java and C++, the most popular OOP languages, are just bad programming languages. There are OOP languages out there, most of them older than Java and C++, that actually provide a much better set of knobs and handles for writing sane OO programs. Java is finally getting a bit better thanks to a lot of market pressure and good ideas from Kotlin. C++ will probably be a mess forever.