Timeline for Is the fluent interface pattern suitable in casual scenarios?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 20, 2022 at 10:55 | vote | accept | Daniele Repici | ||
| Sep 13, 2022 at 9:47 | comment | added | Laiv | Alice must understand that there's something called "consistency". If the same problem has been already solved in "one" way, a new one is unnecessary unless requirements change. If the source code turns into a Babel Tower, where all the happy ideas end without any sort of consistency in the style, some chunks of code can be readable, but whoever has to maintain the code can feel lost deciding how to write code. If new developers feel like Alice's style is "nice" and follow it, Bob will have to deal with a horde of developers introducing unnecessary complexity all over the code. | |
| S Sep 12, 2022 at 13:49 | history | suggested | Peter Mortensen | CC BY-SA 4.0 |
Copy edited (e.g. ref. <https://en.wikipedia.org/wiki/Fluent_interface> and <https://en.wikipedia.org/wiki/Domain-specific_language>). Introduced abbr. "BL". Added some context. Eliminated a sentence fragment. Expanded. Used more standard formatting (we have italics and bold on this platform).
|
| Sep 12, 2022 at 12:21 | comment | added | Daniele Repici | Alice and Bob are peer devs. | |
| Sep 12, 2022 at 12:09 | comment | added | Flater | In general, you can scrap the LOC arguments from your reasoning. Line count is not a valid measure of code quality, and is not a valid measure of what is and isn't an appropriate implementation. When you skip the LOC arguments, it seems that all that's left is Bob's opinion on what he considers more readable. Is Bob in a position to break ties such as these, or is Alice on equal footing with him? Because this just sounds like 2 devs with differing subjective opinions. | |
| Sep 12, 2022 at 7:38 | comment | added | S.D. |
isRoleHigherThanAll is oddly specific. I guess there is a utility set of many such specific use case functions which keeps growing ?
|
|
| Sep 12, 2022 at 6:14 | answer | added | nvoigt | timeline score: 2 | |
| Sep 11, 2022 at 13:08 | comment | added | Filip Milovanović | I don't know if Bob is right or wrong in this particular case; from what you described, it seems that your team is used to a very procedural style, where you create large classes with a bunch of roughly related methods. The team also seems to harbor the "Adding a class needs justification!" attitude (e.g., the objection that "it is only used in one single place"). This is again related to being more comfortable with procedural code, and not understanding levels of abstraction. On the other hand, "with the classic way the utility code LOC are more than halved" suggests Alice overengineered. 2/2 | |
| Sep 11, 2022 at 13:08 | comment | added | Filip Milovanović | "given that such Utility API only exists to break a complex BL class and externalize a particular aspect of the logic into a different unit of code" - can't say for sure without further context, but on the face of it, this is not necessarily a valid objection. Breaking a class is how you manage complexity, distribute responsibilities, and achieve decoupling - you are supposed to do that, the question is has it been done in the right way. BL classes especially shouldn't be large, complicated beasts - build complicated BL out of smaller units. 1/2 | |
| Sep 11, 2022 at 11:00 | review | Suggested edits | |||
| S Sep 12, 2022 at 13:49 | |||||
| Sep 11, 2022 at 10:06 | history | became hot network question | |||
| Sep 11, 2022 at 10:02 | answer | added | Steve | timeline score: 2 | |
| Sep 11, 2022 at 6:00 | history | tweeted | twitter.com/StackSoftEng/status/1568841770590404609 | ||
| Sep 11, 2022 at 3:14 | answer | added | candied_orange | timeline score: 14 | |
| Sep 10, 2022 at 23:19 | answer | added | Ewan | timeline score: 4 | |
| S Sep 10, 2022 at 15:24 | review | First questions | |||
| Sep 10, 2022 at 19:04 | |||||
| S Sep 10, 2022 at 15:24 | history | asked | Daniele Repici | CC BY-SA 4.0 |