Post AStDOB9RUp3DMGwo8O by craigbro@emacs.ch
 (DIR) More posts by craigbro@emacs.ch
 (DIR) Post #ASsffSXyfwlnn8UZPs by smari@mastodon.social
       2023-02-20T19:36:02Z
       
       1 likes, 0 repeats
       
       It is frustrating that almost all discussion of software component abstraction is always predicated on object orientation. Object orientation is a flawed idea that makes software over-plumbed, slow, and rigid. But component abstraction are still very valuable, without treating indirect control authority as a primary goal.
       
 (DIR) Post #AStDOB9RUp3DMGwo8O by craigbro@emacs.ch
       2023-02-21T01:33:52Z
       
       0 likes, 1 repeats
       
       @smari I mentioned Domain Driven Design in a different reply, but wanted to bring it up distinct from #clojure .In DDD, I define entities, value objects, types and aggregates.  Any of those boundaries are then useful software component boundaries, depending on the complexity of my implementation and purpose.Using schema, instead of classes, is also great, especially when I can define them programmatically so a single canonial expression of them can produce my input, internal, storage, and canonical variations (think CRUD)The aggregates are a natural boundary for larger systems too, because by definition they are subsets of your entire domain language that are treated as a slice of state or meaning and are a common concept for end-user manipulation (be it a luser or a dev).I ramble, but I was triggered to show some solidarity with your complaint about the horid OO component breakdown of Java. 8^)