71–80 of 125 posts
Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…
Earlier quoted context omitted.
This is almost exactly the motivational example that Codd used when originally describing relational algebra. He described 5 different data organization schemes for a single problem and designed relational algebra to work with all of them. This ability for the same program logic to work with many different data storage layouts should make changes like you describe less painful to implement. (see page 2) E. F. Codd. 1…
My dream, when I'll have a few years of free time, is to design a language were the relational table is the primary data structure abstraction.
Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…
A customer has an account. The customer is the domain root. Hence there would be no accounts if there were no customers.
A customer does need to to hve an account. An account must have a customer.
It's not cyclic in any way
This was one of the reasons I used lots of Interfaces back in the day with Java.
Earlier quoted context omitted.
In the functional paradigm, language constraints aside, to model this "story" would need these: - The definition of Account - The definition of Customer - A ledger consisting of: List of Account, List of Customer, List of Account-Customer relations A clerk works on the records on the ledger with one hand and one pen, a metaphor for the service process working on the data in the database. An act, such as money transfe…
> `customer.accountService.createAccount(newAccountData)` I believe that most OO implementations would read accountService.createAccount(customer, newAccountData) Care to elaborate if that was the main point of the clerk's schizophrenia criticism? Or if I'm misinterpreting just call me dumb, haha.
But my main point is that it should not be written that way at all.
Semantically, if we must include the subject, it should be
`theService.createAccount(Customer, NewAccountData)`
Or replace theService with CustomerAccountService or whatever.
Writing that way, with functions depending on types, avoid getting tangled from the so-called account-customer cyclical dependencies. Because account and customer don't need to know each other until a function needs to know both of them. There's no such thing as `customer.getAccounts()` because in the end the query would roughly look like `getAccountsWhereCustomerIs(CustomerId)`.
You're not dumb. It's just me mis-writing due to the fact that I'm writing this at 4 in the morning lol. Or maybe I'm misinterpreted parent comment and that confuses you. In that case, I'm the dumb.
Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…
But functional-only business applications already did take the world by storm! Relational DBs is the defacto way data is organized, and a Junction table is the way you model the data so that a functional query (generally in SQL) can be made against it.
Earlier quoted context omitted.
My dream, when I'll have a few years of free time, is to design a language were the relational table is the primary data structure abstraction.
This is a cool idea. What would you need to be able to try this in 2 weeks, instead of a few years? What's the lean slice?
Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…
Sometimes I read conversations about software engineering concepts by career developers and I get this sense that there is this entire hidden world of other engineers that I have somehow managed never to encounter. Every engineer I've ever met who has been doing it for more than a couple years universally decries circular dependencies. Every one of them has come to that opinion via hard won experience dealing with re…
If you've working with Java at Google (Guice) makes you learn to hate hiding circular dependencies behind dependency injection, since your binary gets injected by some huge tree of thousands of dependencies all that can create errors or interfere with each other. And without static checking trying to reason and fix those issues becomes really hard.
I strongly prefer using the languages actual type system to create circular dependencies that you can inspect using well known tools over that any day, better have a problem you can see than hide the same problem to satisfy some tools requirement.
Earlier quoted context omitted.
It's called the "dependency inversion principle". People don't like to call it "reflection", and heap various layers like XML or dependency injection annotions on it, but technically, it comes down to reflection at runtime, as far as I've seen. It certainly has its cost in additional complexity through indirection, but it's better than creating cyclic dependencies or giant balls of mud. https://en.m.wikipedia.org/wik…
No, you don’t need reflection or annotations to use dependency inversion. Why do you think so?
If you can do dependency inversion without reflection, more power to you :-) We can't do classpath scanning in the project I'm working on because of the size of the classpath, and compile time configuration using direct imports would introduce cycles, so reflection it is for us, in one form or another.
Earlier quoted context omitted.
I’m having a hard time understanding why you think F# is unable to handle the domain model presented.
It reads as an extremist take on Chesterton’s Fence: “the fence exists, therefore it is probably the only thing that could’ve worked.” There is nothing in this contrived example that F# or Haskell (gasp, pure functional) wouldn’t handle with ease. It just would be modeled differently from traditional langs. I’d argue the alternative modeling forced by FP langs would be superior.
Then I'd like to see that. The other example of the functional someone gave more above, was not convincing to me. Much more complicated then the straight-forward simple, but evil cycle approach.