How to increase readability of an interface (C#)
-
@asdf one-liner getters and setters in simple objects are silly, and I would only use it to avoid conflict with other people.
-
@fbmac said in How to increase readability of an interface (C#):
one-liner getters and setters in simple objects are silly
Unless your language supports properties, they are still necessary. Only value objects should ever have publicly accessible members.
-
@Magus said in How to increase readability of an interface (C#):
@error Elastic Tabstops. Available now for VS, CodeBrowser, VIM, and a variety of other editors.
It looks really awesome, but unless we could get it installed on every machine on our team (read: not gonna happen), it seems like it could create consistency issues.
-
Why not just add some spaces?
using System.Collections.Generic; using System.Threading.Tasks; namespace AutoLotDAL.Repos { interface IRepo<T> { int Add (T entity); Task<int> AddAsync(T entity); int AddRange (IList<T> entities); Task<int> AddRangeAsync(IList<T> entities); int Save (T entity); Task<int> SaveAsync(T entity); int Delete (int id); Task<int> DeleteAsync(int id); int Delete (T entity); Task<int> DeleteAsync(T entity); T GetOne (int? id); Task<T> GetOneAsync(int? id); List<T> GetAll (); Task<List<T>> GetAllAsync(); List<T> ExecuteQuery (string sql); Task<List<T>> ExecuteQueryAsync(string sql); List<T> ExecuteQuery (string sql, object[] sqlParametersObjects); Task<List<T>> ExecuteQueryAsync(string sql, object[] sqlParametersObjects); } }
Makes it visually very clear what's going on with only some minor changes.
-
@anonymous234 I like it, until someone comes in and Ctrl+K, Ctrl+D reformats the file.
-
@asdf unless you're writing an API for a library where you can't ever change it, you're wrong.
-
See, this is why C is better! I'm sure you can #define a macro that creates synchronous and asynchronous versions of a function to make the code much clearer.
-
@xaade said in How to increase readability of an interface (C#):
@Dreikin said in How to increase readability of an interface (C#):
Tested it. It returns null.
The wrapped function is searching for a primary key in the table, null would be unfindable, so it acts the same way it would if the PK weren't present: it returns nothing, because nothing has that PK. I think it only accepts null because the PK parameter is an array (for multi-column keys), and arrays can be empty.
-
@fbmac said in How to increase readability of an interface (C#):
unless you're writing an API for a library where you can't ever change it, you're wrong.
Have you ever worked with a sufficiently large application in a team of more than 2 or 3 people? Whether you can make changes locally, to one class, or have to change 100 different other classes which use that class makes a huge difference, no matter whether you're at an API boundary (public API of a library) or not.
Yes, IDEs can assist you with that, but that's not the point: You're unnecessarily changing parts of the application which other people are working on, therefore creating possible merge conflicts, interrupting them and pissing them off.
-
@asdf say I have a class:
class Point {
int x;
int y;
int distance(Point p2);
}I'll not create a getter/setter for these, and I'll laugh at any cultist that claim I should .
-
@fbmac Congratulations, that's a great example of a value object, which I just said is the only valid exception to the rule.
-
@anonymous234 said in How to increase readability of an interface (C#):
See, this is why C is better! I'm sure you can #define a macro that creates synchronous and asynchronous versions of a function to make the code much clearer.
Or you can use a sane language, like Rust, which has macros that actually understand the structure of your code instead of just replacing text, and are therefore far less error-prone.
-
@error Yes, but that's unavoidable The only way to prevent that would be some kind of
#pragma donotautomaticallyfomatthisregionplease
-
@anonymous234 said in How to increase readability of an interface (C#):
See, this is why C is better! I'm sure you can #define a macro that creates synchronous and asynchronous versions of a function to make the code much clearer.
I'd laugh at this, but then... I remember.
Filed under: Thousand-yard stare
-
@asdf My bad. I'm not creating a getter/setter pair for any class that is used by less than a few other classes and I haven't foreseen any logic inside the getters and setters.
-
@asdf said in How to increase readability of an interface (C#):
@anonymous234 said in How to increase readability of an interface (C#):
See, this is why C is better! I'm sure you can #define a macro that creates synchronous and asynchronous versions of a function to make the code much clearer.
Or you can use a sane language, like Rust, which has macros that actually understand the structure of your code instead of just replacing text, and are therefore far less error-prone.
Isn't that what makes a macro a macro*? Otherwise you just have an inline function.
* You could say it
define
s macros.
-
@anonymous234 code in C if you like macaroni and in Java if you like Ravioli
-
@fbmac Well, if more languages supported properties, this whole discussion would be and you could have the advantages of getters/setters (encapsulation) and public members (no unnecessary boilerplate code) at the same time. :) But since the world isn't perfect, you need getters and setters to have a public API for a class whose implementation might change. Just let your IDE generate them for you, curse the gods of Java and move on with your life.
-
@fbmac said in How to increase readability of an interface (C#):
@anonymous234 code in C if you like macaroni and in Java if you like Ravioli
I'd say Java is lasagna.
Filed under: Mmm. Copypasta.
-
@xaade Then you do the work when you need to do it. When you're ready to swap in the new database, do the work. If you know 100% for sure it'll happen in the next 3 months, do the work. If it's some nebulous "someday we'll...", YAGNI.
-
@error I once tried to open a C file to see if I could figure out what it did, only to be greeted by something that looked nothing like C, instead being comprised of dozens of magical ALLCAPTERMS that were apparently some kind of meta-language made out of preprocessor macros . I noped out immediately.
-
@asdf but not the bull shit created by Martin Fooler and his cult followers
-
@fbmac said in How to increase readability of an interface (C#):
@anonymous234 code in C if you like macaroni and in Java if you like Ravioli
What if I want fettuccine?
-
-
@blakeyrat said in How to increase readability of an interface (C#):
Then you do the work when you need to do it. When you're ready to swap in the new database, do the work.
The problem is that this may mean that you have to rewrite the whole application if you didn't think about abstractions/coupling at all during the initial software design. Just take NodeBB and <insert_person_whose_identity_I_can't_remember_here>'s efforts to port it to a relational DB as an example.
-
@fbmac said in How to increase readability of an interface (C#):
but not the bull shit created by Martin Fooler and his cult followers
Patterns are a useful tool if used correctly. The actual problem is that way too many Java programmers apply patterns senselessly to everything that looks like a nail. ;)
-
a C dinosaur programmer will create unreadable functions with thousands of lines, reusing variables and abusing globals and etc.
a java cultist will create thousands of 5 line classes with dozens of indirection layers
both are unreadable code that should die
-
@error said in How to increase readability of an interface (C#):
Or you can use a sane language, like Rust, which has macros that actually understand the structure of your code instead of just replacing text, and are therefore far less error-prone.
Isn't that what makes a macro a macro*? Otherwise you just have an inline function.
Nope, the macro is still expanded at compile-time. See https://doc.rust-lang.org/book/macros.html for details.
-
@fbmac said in How to increase readability of an interface (C#):
a C dinosaur programmer will create unreadable functions with thousands of lines, reusing variables and abusing globals and etc.
a java cultist will create thousands of 5 line classes with dozens of indirection layers
both are unreadable code that should dieOk, now we finally agree on something.
-
@asdf a real abstraction could be useful.
I've seen very few real abstraction written, but I've seen many useless layers and indirections that were shitty design.
"repository pattern" always matches the shitty design case
-
@flabdablet said in How to increase readability of an interface (C#):
Has the compelling advantage that weenies who insist on editing code using a proportional font will hate your guts for it.
as well they should. code editing should be done in a monospace font. just like our goddess and savior Ada Lovelace intended!
-
@fbmac said in How to increase readability of an interface (C#):
"repository pattern" always matches the shitty design case
…and we disagree again. First, let's define the repository pattern:
Basically, a repository is a facade for your data layer. Instead of accessing the global DB object / data mapper / ... everywhere in your code and perform the same 3 steps to get a user by email address (code duplication! tight coupling!) you now have a Users class with a method getByEmailAddress() which does all that for you.
Advantages:
- Less code duplication
- Clean API for lower layer, decreasing coupling significantly
- Allows you to change the internals of the data layer (introducing caching, changing the DB structure, changing the storage method, …) without affecting the rest of the application
Basically, "repository" is just another name for "facade" in a specific context and repositories have all the advantages other facades have.
Are you really trying to tell us that the facade pattern doesn't have any merit?
-
@fbmac said in How to increase readability of an interface (C#):
@asdf say I have a class:
class Point {
int x;
int y;
int distance(Point p2);
}I'll not create a getter/setter for these, and I'll laugh at any cultist that claim I should .
I'd probably make it a struct in that case. (See: hilarious Minecraft garbage collection problems from passing millions of vector objects around)
-
@error said in How to increase readability of an interface (C#):
I'd probably make it a struct in that case.
Not everyone has the fortune of being able to use C#. Most of use write Java.
-
@asdf I was thinking about a more specific shitty pattern, associated with DDD
-
@error said in How to increase readability of an interface (C#):
@fbmac said in How to increase readability of an interface (C#):
@asdf say I have a class:
class Point {
int x;
int y;
int distance(Point p2);
}I'll not create a getter/setter for these, and I'll laugh at any cultist that claim I should .
I'd probably make it a struct in that case. (See: hilarious Minecraft garbage collection problems from passing millions of vector objects around)
structs won't help you with this in C#, and C++ classes don't have this problem
-
@fbmac IIRC "repository" means exactly the same in the context of DDD. It's supposed to be the public API through which you access/create the domain objects. So exactly what I explained.
Of course, if you ever find a repository that doesn't actually do its job (hiding the logic for instantiating domain objects and querying the database / web service / …), that's TRWTF, then. Don't blame the pattern itself for the people who are too stupid to use it correctly or frameworks/libraries that abuse it.
-
anyway, if you're trying to do good design you won't use nosql shit, so the ORM is the only data layer and/or repository you need
-
@fbmac ORM generated classes should also be the M in mvc for most database applications
-
@fbmac oh sod off with this nosql is always shite schtick. It works really fucking well when used correctly.
-
@lucas1 when
-
@error It basically means, you use one or more tabs, though. Which means that if your editor at least has smart tabs, it may line up somewhat anyway. At worst, things are tabbed out from their lines and not lined up, which is no worse than it would be if you didn't try to line them up.
-
@anonymous234 said in How to increase readability of an interface (C#):
See, this is why C is better! I'm sure you can #define a macro that creates synchronous and asynchronous versions of a function to make the code much clearer.
:do_not_want.mdb:
-
@lucas1 said in How to increase readability of an interface (C#):
@fbmac oh sod off with this csv files as a database is always shite schtick. It works really fucking well when used correctly.
FTFY
-
@fbmac say you need an audit log for transactions on a web service i.e. who logged in when and did what... it about 10 to 100 times smaller than the same data in SQL server. Fast write scenario for stuff like analytics it is far superior to SQL.
Also if you are doing full text searches it better to generate a search index from what is in your SQL database and rebuild the relevant parts of the index on add/update and delete scenarios.
-
@fbmac said in How to increase readability of an interface (C#):
so the ORM is the only data layer and/or repository you need
Yes and no. An ORM is definitely a good start and already does 50% of the job of abstracting the details.
There are cases when you need complex logic despite using an ORM, though. For example, some queries (that you have to perform in multiple different places) might be horribly inefficient unless you give your ORM hints (eagerly load this, enable lazy loading here, etc.) or cache the results somewhere. Also, building the query, even when using the ORM instead of constructing the SQL query directly, might require a lot of code that you might want to put in a method somewhere. This "somewhere" where you can put all that logic instead of scattering it everywhere is the repository.
ORM generated classes should also be the M in mvc for most database applications
If you're implementing a simple REST service, then probably yes. Unless what I wrote above applies. Anyway, it never hurts to add a facade (repository), because you don't need the full flexibility of the ORM in the upper layer of the application. You're almost always going to query the database in a finite set of very specific ways, so you might as well add an object with 1 method for each of those specific queries.
-
@asdf a cultist will duplicate all orm generated classes and write mapping code just to solve these hints. I hate morons who do that.
-
@asdf in c# you can specify whether it should be private, even on a one liner.
-
@fbmac said in How to increase readability of an interface (C#):
a cultist will duplicate all orm generated classes and write mapping code just to solve these hints
That, of course, is fucking moronic and has nothing to do with the repository pattern as it was intended. The repository is literally just 1 additional class with 1 method per specific query you want to execute. Nothing more, nothing less. Doesn't add LOC (since you're writing that code anyway), the indirection doesn't hurt (One additional method call that shouldn't hurt, because how often do you call these methods? If the answer is "a lot", then your performance bottleneck is going to be the DB, not the repository class.) and your code becomes cleaner, more readable and less tightly coupled, basically for free.
-
@asdf I've seen all of it in small data entry websites:
website - web service - facade - orm - database
some people just love to spend the day writing mapping code like:
obja.name = objb.name
obja.phone = objb.phone