Tag Info

Hot answers tagged

6

You've discovered the need for spatial indexing. R-trees are probably the most common approach. The basic idea is a tree structure with rectangular bounding boxes computed over all the children of a given node. That way searching for a region or a point can traverse the tree, pruning out any parts of the tree (most of it) where the bounding box is not a ...


4

In general, it turns out very badly if objects of the same level know about each other. Once objects know about each other they are tied, or coupled to each other. This makes them hard to change, hard to test, hard to maintain. It works out much better if there is some object "above" that knows about the two and can set the interactions between them. The ...


4

Is this an appropriate use of the Singleton pattern, or are there still some pitfalls that I'm missing? No, this has almost all of the pitfalls of singletons and even that assumes that you actually use Supplier almost everywhere and have other implementations. I'm not going to go into the various pitfalls of singletons as they have been covered well ...


3

Dependency Inversion should be best fit in your case. The interfaces should not be defined based on supported capabilities, but on what P_User is expecting from the protocol. Each protocol can then implemented what P_User needs based on it's capabilities.


2

What you could do is a variation of an Abstract Factory. Something like this: public class ProtocolFactory { public IP _protocol; public ProtocolFactory(IP protocol) { _protocol = protocol; } public IA GetAService() { return _protocol as IA ?? new NoOpProtocol(); } public IB GetBService() { ...


2

You have really two options here: factoring - isolate interfaces of each object and use soft casting (as operator) to determine extended capabilities of the class optional feature pattern - implement all methods available on all classes in one base class and throw NotSupportedException when the given function is not supported. Both of those have their ...


2

What you are looking for is not a singleton, but a factory. The reason is you have a single object that figures out which logic to execute, then executes it. As you say in your comment, it is functionally similar to a switch statement: figure out which branch to execute, then execute it. That works fine if your logic is simple, but once it grows in ...


2

With the details given, i find difficult to justify the need for temporary implementation - ImplB. Anyway, am parking that here. As all the 3 are implemented for a specific purpose, though there could be added functionality for implC, I believe that there could be a certain abstract type for these 3 - interface or an abstract class. Once that is in place ...


2

I have experience with big CRM/ERP product created this way. It is doable, but takes considerable more time and functionality will be limited. If this kind of thing is proposed only for access control, I don't think it's worth it. Some downsides: All types of controls you want to use, must be custom coded to support persisting info into database. If it is ...


1

I think that the advantages of this approach far, far outweigh any disadvantages. What you're achieving here is more ore less a perfect "implementation" of the I in SOLID by way of the Stairway pattern - that is to say, your application depends "down" on an interface defined in Company.Framework.Persistence.dll and the individual implementations themselves ...


1

I do it that way too. Projects/dlls are essentially free and make the code more readable and easier to use. I have known people use a single large DLL and differentiate with name spaces. But as you say they have to deploy unused code, I don't see any benefits to the practice and many downsides such as change to one implementation requires recompile of ...


1

(Disclaimer: I don't know any of the technologies mentioned in the question; I'm just inferring from the descriptions on the question itself and the linked articles.) Dependency and the order of execution. Based on the linked documentation, It seems you can control the order of execution of middlewares simply by calling app.use(...) in a particular ...


1

This depends a great deal on the nature of the PDFs you accept as input. If you have control over the format of the PDF you're accepting, you can very easily extract the data you need; on the other hand, if you agree to accept any valid PDF at all, your task will be much harder. A loose hierarchy of options that PDFs can provide: PDF forms are designed ...



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