2,011 reputation
415
bio website laurentbourgaultroy.ca
location Canada
age
visits member for 1 year, 8 months
seen 2 days ago

2d
reviewed Approve suggested edit on When is C a better choice than C++?
Jun
12
awarded  Nice Answer
Apr
14
answered What does HATEOAS offer for discoverability and decoupling besides ability to change your URL structure more or less freely?
Mar
14
comment Differences betwen HTML templating systems
Oh, so true :) .
Mar
13
answered Differences betwen HTML templating systems
Mar
13
comment Regarding interfaces of classes in OOP
I sure created a lot of interface that had a few get on them. Entity with a getId, with the contract of : I don't care how you find your id, but it must be cheap, consistent, and be unique to you. Or a generic Report with getTitle. Different implementation created the title using different strings. Some implementation did it on the fly, other just delegated to a collaborator. If someone assumed that there was a field behing getTitle, they would have been pretty sad indeed...
Mar
13
comment Regarding interfaces of classes in OOP
For C#, you may want to read this. Its not really about Get per say, but more about properties = cheap and method = may not be cheap. As for Java, well, yes, I totally agree that bar() is more compact, but a lot of framework and developper have gone by the convention of "get set" and it's better to follow an imperfect convention that being inconsistent. I think there is a difference between a "logical" property of a class and a field : one is part of the interface, the other an implementation detail
Mar
13
comment Is it sufficient to use acceptance and integration tests instead of unit test?
"I don't like to focus on the textbook approaches - rather, focus on what gives your tests value" Oh, so true! First question to always ask is "what problem do I solve by doing this?". And different project may have different problem to solve!
Mar
13
comment Regarding interfaces of classes in OOP
Hum, in C#, GetFoo() usually mean that the returned value is computed and is potentially expensive. Properties (the get/set equivalent of java) can be computed if its cheap. So "get mean accessing a field" may not be a universal rule of programming. Scala also allow those "it's computed but you wouldn't know it" properties. And in Java, I've been using getBar() to get a computed properties for years now. Do you have a source for that convention that computed is foo() and field is getFoo()? I am not saying it's wrong, but I can't remember seeing that convention in the codebase I worked on.
Feb
24
asked What is the point of link rel=“self” in a REST API?
Feb
10
revised Should entities be accessible from all layers of an application?
Typos
Feb
10
answered Should entities be accessible from all layers of an application?
Feb
10
comment Switch or a Dictionary when assigning to new object
I guess the fact that you explicitely put it in a Constant mean that you need the created object to be mutable. But if one day you can make them immutable, then returning the object directly will be the best solution. You can put the dict in a const field and only incur the cost of creation once in the whole application.
Feb
10
comment Switch or a Dictionary when assigning to new object
Oh, that's nice!
Feb
7
revised How do I integrate a browser-based JavaScript unit testing framework into my workflow?
added 145 characters in body
Feb
7
answered How do I integrate a browser-based JavaScript unit testing framework into my workflow?
Jan
23
comment With all of these services, how can I not be anemic?
Would your sales force understand these "models". Hum yes. I sat with a sale rep that explained to me all of these models. I didn't invent them. I'm currently working on supporting non-aggregated fact tables (not supported yet). And yes, we have big fat button labeled "Connect to an aggregated fact table". The user get it, the support team get it, and our sale rep get it. If you don't believe me, read about my domain yourself I guess?. Does the maker of MySQL workbench need to abstract MySQL away? That wouldn't make sense!
Jan
22
comment With all of these services, how can I not be anemic?
Well have to agree to disagree on that one. The point of a domain model is to create a metaphor of your domain in code, and push away the technical detail. The database schema in our app is not a technical detail. We could not swap it out without impact. Its important. Thus, its part of our model. But look, you can have your own definition :) . By the way you can create a domain model in scala and functional language. Nothing say it has to be mutable.
Jan
21
comment With all of these services, how can I not be anemic?
We have a BI product. The user is required to enter the database info for our software to connect and display the data in graphic form. So he need to know how his database well, and a lot of our code is interpreting this input to send the correct SQL query to show his statistics. This is our domain, and half the application logic exist to correctly connect to an arbitrary relational database. We need to validate the connection info, pull the table schema, link them together, ask for dimension structure, etc. So our domain is full of Database, FactTable, StarSchema, SqlQuery, etc.
Jan
21
comment With all of these services, how can I not be anemic?
I know I am kind of late, but persistence/database access may be part of the domain. I work in the business intelligence domain and we need to connect to a generic data warehouse and extract data from it. So all the knowledge of relational database and SQL goes straight in the domain, because those are in the language of the user and of the domain expert. Actually, I think the real persistence rule is similar to one you gave "if a persistence module can be re-implemented anytime without impacting the business logic, it doesn't belong in the domain". Not exactly never ever, but close.