Hot answers tagged

6

Short answer: The problem is that the caller needs to traverse (and know the structure of) the entire multi-object data structure in order to access it's leaf node. I think you're confusing things a bit. You're arguing: if A knows about B and that's ok, and B knows about C and that's ok (etc.), then it must be ok for A to know about C. But it's not ...


4

The practical uses of a neural network is pretty much everything. Recognition / detection in vision Artificial intelligence in games Classification ... In short : neural network can do pretty much everything as long you're able to get enough data and some efficient machine to get the right parameters. My professor told me once that some competition ...


4

Beyond AlexanderBird's answer, I would simply say the following - object orientation is about telling objects to do things for you, not just exposing attributes and getting you to do things with them. So in the above, you're asking object A about it's object B, then asking object B about C, and so on. Just tell object A to do something, and let it delegate ...


3

The simplest method to use to avoid the situation is probably not to do it at all. Most databases will take care of it for you and automatically generate a row-id without you having to lift a finger. Microsoft SQL - IDENTITY MySQL - AUTO_INCREMENT Oracle PostgreSQL - Serial


2

Whilst it's admirable to check your preconditions, I wonder: is your class usage such that you'll need to check all these ? e.g. I will check preconditions for a set of components that are exposed for more general usage, but for more limited usage in which I know how the component will be used, I won't perform so many checks. The counter argument to this ...


2

By wrapping the whole thing in an IIFE, you can create private variables and functions. This way, the exposed API can wrap the private functions any which way, and persist would only be called when using the public delete: var obj; (function() { function realDelete(id) { delete obj.users[id]; //maybe some other code (ui manipulation) ...


2

B is harder to parallelize, but you're not doing that. So what, right? Nope, it's still a Bad Thing, and here's why: That extra parameter you're trying to avoid is there for a reason. It indicates a data dependency which might not otherwise be obvious. This makes your code easier to reason about after time has passed and you are no longer familiar with ...


1

I would use the former approach. The latter duplicates a lot of effort, especially since the pairs of interfaces will likely be the same. So following the KISS and DRY principles, I would simply use one set of interfaces and not create a second (likely duplicate) set.


1

Your second method is probably the best approach. However, you didn't ask what the "best approach" was or mention any specific problem you are encountering outside of concurrency, but rather: What are other methods I can use ? "Row number" for an order is not really a necessity for uniqueness in your database. When an order is displayed, the row order ...


1

The primary plan A advantage is testing. You want to run your unit tests in parallel, right? Bingo, multiple networks in parallel. Not to mention just flat out testability problems with the global context.


1

For many cases, I just use the flag like your second example : deleteUser : function(id, isPersist){ delete this.users[id]; //maybe some other code (ui manipulation) if (isPersist) this.persist(); } deleteAllUsers : function(){ var me = this; var uids = Object.keys(this.users); uids.forEach(function(u, i){ ...


1

I think the interface to deleteUser() and deleteUsers() should be similar, so I'm against your second solution. In this scenario, I'd keep the deleteUser() method, and internally delegate to a private persistence method. For consistency's sake, I would do the same for deleteUsers(). By doing that you're keeping the public interfaces consistent, and the ...


1

Your Business Layer is the place where the encryption should happen. Repositories should only concern with data retrieval and storage.


1

Does implementing hashing that difficult in the language/framework you use, so that it would justify a separate dedicated service? What I mean is that, for instance, in Python, it's just three lines of code. In C#, it looks much more complicated, but still not enough in my opinion to have a separate service for that. One interface, one implementation class, ...


1

Repositories generally shouldn't be involved in encryption unless it's a feature of the persistence-layer, so unless you're asking the database to do encryption/hashing or using some very interesting queries, I'd use a separate service. It splits up responsibility. Create a service, and if necessary you inject the Service into the Repository as a ...


1

If you are into TDD, I suggest you write up a test which will fail until the functionality gets implemented. The only downside I can see is if you are a somewhat lazy function such failing tests will contribute a lot of noise to runs and may hide actual failures behind all that.


1

In my humble opinion, the controller should be the "facade" itself, that means that the controller should decide which service to call, and the services should be in charge of generating the response object. What I would do is to define a method per action, and discriminate the service using REST naming, something like this: @Path("/") public class ...


1

Partial classes are just a means of splitting one class into multiple files. It is particularly useful when parts of a class can be generated but you want custom code in it as well. I don't see how this helps you select which properties are obsolete for a new version or not. I would suggest attributing obsoleted properties with [Obsolete("since version ...



Only top voted, non community-wiki answers of a minimum length are eligible