3 ms·

It is much easier to change applications that are designed properly, regardless of the premature optimization, using adapters and interfaces is costless, and gi

• pistoleer 2y ago
  If only we could all finally agree on the definition of "proper design"!
  • lnxg33k1 2y ago
    For me, one that allows the application to be extended, maintained and understood easily
    • sethammons 2y ago
      The problem word, i think, is "extended." To me, that means adding functionality to the feature set, to others it may mean "changing the db" - and the two designs will be different.
    • onli 2y ago
      So as simple as possible, without unnecessary indirections and useless abstraction like interfaces that make reading the code hard, right? ;) There really are very different perspectives on what makes code easy to manage, and interfaces (especially ones used only for a single class) are a sure-fire way for me to make code unmanageable. But java enterprise coders disagree. That can clash hard.
      • lnxg33k1 2y ago
        What is about interfaces that makes reading code hard? It is a contract, for me reading just a list of operations that are available without the concrete code, is even clearer/cleaner. Not sure java is bad for indirections, java is bad for boilerplate and lack of defaults, imho. But I usually don't use frameworks/stlib directly, so I create my own boilerplate that is reusable
        • onli 2y ago
          It's about the indirection. In the calling code, instead of knowing which specific object you are working with - and thus easily being able to check its implementation - you only know which interface it implements. Getting to the implementation can be very time consuming, especially in a system with hexagonal architecture or similar indirect patterns and dependency injection. While searching the code you then lose the context of the problem you were working on. So I'm not talking about having one or two sensible interfaces as a contract, but codebases where every class has at least one interface, for "decoupling". Pure hell.
          • solidninja 2y ago
            In my experience, using tools that do not support the "Go To Implementation" shortcut makes it hard. In IntelliJ, Ctrl+Shift+Click will take you to the possible implementors of an interface. Concrete example from work today - we have a trading application and there are many paths that lead to alerts of some kind. Alerts are usually raised inline with any business logic (as should be - they intrinsically coupled). Alerts however can be delivered differently - via SMS, other messaging systems and/or log messages. The different places where the alerts need to be generated do not _need_ to know how the alert is going to be physically delivered to its destination - they just need to generate it. Without an interface (or at least a type alias for a function) - it would make being able to say e.g. this alert is a direct phone message vs. a chat message in some channel because of the type it is - much harder.
            • onli 2y ago
              Sure! There are valid use cases for them. I was specifically talking about unnecessary usage :) In the system I worked on the shortcut did not work - too many options or some consequence of the dependency system, additional layers of indirection.
    • pistoleer 2y ago
      You can't just extend a house willy nilly. You have to set up scaffolding, destroy some walls, have temporary rigs to keep the ceilings from collapsing, etc. Unless you want to live in a "shipping container" building, but even then there's a non 0 effort, and the shipping container constraint comes with its own set of issues. In real life, you just can't have it both ways. There's always a trade off. If the trade makes sense go for it I say, but I think people aren't always honest (to me or themselves) about the exact trade they are making.
• choeger 2y ago
  > using adapters and interfaces is costless, Hah, no, they're not. Every production app is read many, many times by several different developers, mostly to search for bugs. Reading across adapters, services, and interfaces make that much harder. Especially, if the architectural pattern was implemented slightly differently every time by various authors. Abstraction always comes with a price. Often, it is well worth to pay (or we would still code everything in C or assembly), but sometimes it's just a waste.
  • solidninja 2y ago
    I'm always fascinated by the amount of comments that devalue separating concerns and reducing coupling by using traits and modules. Maybe if you're exclusively writing serverless functions you don't need much code anyway, but the idea that you can go and read a piece of code that deals with the database separately from a piece of code that deals with your HTTP request encoding (and see how they meet in the middle via a few method signatures) is a pretty powerful one in my experience.
    • FridgeSeal 2y ago
      I don't think anyone here is seriously suggesting that separating IO and concerns is bad. I think people here are devaluing the "kind of approach" taken in these over-abstracted-architectures. The snippets of "improved" code in TFA have a lot of new line-noise, a lot of boilerplate and half-a-dozen "new" pieces of terminology, all in the quest to essentially separate IO and core logic. There's plenty of ways to perform this separation, many of them don't require replicating half the design-patterns from C# tutorial. I'm pretty partial to "functional-core, imperative-shell", I think that it achieves all the same advantages, with none of the new concepts, and far less line noise.
      • globular-toast 2y ago
        Thanks for providing an example of how to do the separation in a better way! Many of the other comments are just saying "this is stupid" because they've never built anything big enough to see why domain driven design exists. Abstract classes etc are just a means to an end, they are not the goal. Dependency inversion is the goal. It's good to know there are ways to do it in Rust.
• pjmlp 2y ago
  While I agree with the idea, they certainly have a development cost in complexity.