Hot answers tagged

58

I've left them public for ease of unit testing Ease of writing those tests, maybe. But you are then tightly coupling that class to a bunch of tests that interact with its inner workings. This results in brittle tests: they will likely break as soon as you make changes to the code. This creates a real maintenance headache, that often results in people ...


40

Should coding best practices always be used Always? No, that's silly. Best practices are guidelines. For most people, for most situations, if implemented with some finesse, they will yield the best results. They're where you start when considering solutions. But there will be places where best practices can and should be ignored, because there are better ...


35

I would normally expect you to exercise the private member functions via the public interface. In this instance I would write different tests to feed different file contexts in, with different data sets present in order to exercise those methods. I don't think your tests should know about those private methods. I think they're part of the implementation, ...


30

Yes. That is self-evident. Why would you not do what is best? That's not the issue though. The hard part is finding out what IS the best practice, because in order to answer that you need to know exactly what requirements you have and how the project is likely to evolve over the years, and that is fiendishly hard. One good rule of thumb however: It is NOT ...


11

The best practice is the one that most effectively fulfills your software's functional and non-functional requirements for features, maintainability, performance, etc. If that practice happens to align with some "industry standard," that's awesome. But if it doesn't, pragmatism wins. Where I currently work, we're building a new web UI for our product from ...


9

I think the issue comes from the design. My gut feeling says you either wrote the tests after the code, or that you already had a complete implementation in mind when you started writing the tests, and then you just shoehorned the tests to fit the design. I think this type of trouble can be avoided by remembering the short TDD cycle of making a small ...


7

I agree with @BrianAgnew and @kai, but would like to add more than a comment. While an IDedupeFiler (or whatever) should be tested through its public interface, the OP has decided there is value in testing the individual sub-routines. Irrespective of file size or line count (which is only a rough proxy count for class responsibilites), the OP has decided ...


6

If it is the case that the name of the car isn't publicly available in any way at all, then it makes no sense to test it, because obviously it doesn't matter to any client code. If the name of the car matters, even if you can't actually see it by inspecting the field, then exercise some method that relies on the name being correct and assert against some ...


5

The smaller the objects the more difficult to visualise program flow is. But the problem here is not that you have objects, its that you're trying to create a program from objects in a procedural manner. Your objects should be completely self-contained black boxes to the calling code, if you can make them like that then you can start to use them without ...


3

It's very typical to use the domain model as the resources in the web API layer, but it's usually not the right thing to do. The domain layer has clients, including the web API. The web API has clients, including your UI. The needs and wants of domain clients are not the same as the needs and wants of web API clients. Write your web API for your clients. If ...


3

RabbitMQ can be used for RPC. For more information, see RabbitMQ in Action: Distributed Messaging for Everyone by Alvaro Videla and Jason J. W. Williams: section 4.3: RPC with RabbitMQ, page 80. This being said, you don't really have to make a choice between a message queue service and REST/SOAP. Both can be used, and some services can expose both ...


3

I think you might benefit from a slight shift in the way you view unit tests. Instead of thinking about them as a way to guarantee that all your code is working, think of them as a way to guarantee that your public interface does what you claim it does. In other words, don't worry about testing the internals at all - write unit tests that prove that when ...


3

Layers, Onions, Ports, Adapters: it's all the same Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When ...


3

Let me reiterate what you're saying to be sure we're on the same page. In clean architecture Case A use-case/interactor classes often share base class/interface, like here public abstract class UseCase { private final ThreadExecutor threadExecutor; private final PostExecutionThread postExecutionThread; private Subscription ...


2

First off, you shouldn't be thinking of security in terms of a binary 'ok' or 'not ok'. Every choice you make has security implications that you want to understand. Regarding keeping the files on the web server's machine, that's not typically a problem for most commercial applications. You just need to make sure they aren't accessible via the web server....


2

There are a number of potential problems here. Theres not enough detail on the technical solution to say for sure but it seems an unsophistocated approach. Instead of critising the technology selection though, we should establish the security criteria needed for the application and ask how the solution achieves each point. eg. Should the documents be ...


2

what would be wrong with treating a client session as a resource/an application state as well? There is nothing wrong with that per say, the problem comes when you try and use application state (in the form of session resources) as a form of authentication. You are basically saying that if the application is in this specific state then this client (say ...


2

what would be wrong with treating a client session as a resource/an application state as well? The short answer is that you get unexpected side effects when the client's understanding of application state and the server's understanding of application don't match. Review Fielding: Section 6.3.4.2. Notice that, in the examples that you describe, the ...


2

The important question to ask, when designing aggregates, is how does the data change? For team to be an aggregate implies that it has some state, and even after that state changes it is still the same team. (ie, for team to be an aggregate, it must be an entity -- not merely a value type). So in your model, do teams change in any interesting ways? By ...


2

You asked: Does local applications running on the same machine that host the server, will have faster REST communication? Absolutely. Your data won't have to be serialised onto the wire. For faster "local" REST communications, does a server needs to expose 2 endpoints (one for localhost / one for remote) ? No. Your server will expose on a ...


2

I think you're overthinking things. You can use a traditional SQL-based RDBMS. It may or may not be fast enough (although I suspect you're worrying prematurely about optimization), but the only way to tell would be to try it. Just make sure that you write your code that interacts with the storage system in an abstract-enough way that it is simple to ...


2

In addition to the other answers, there's another benefit to making these functions private and testing them via the public interface. If you gather code coverage metrics on your code, it becomes easier to tell when a function is no longer being used. But, if you make all of these functions public, and make unit tests for them, then they will always have ...


2

If you quote the following sentence also, you have the answer: Events do not travel, they just occur. However, the term event is often used metonymically to denote the notification message itself, which may lead to some confusion. From the context it is clear that the two other quotes are talking about the event notification message rather than the ...


2

I assume by "best practices" you mean some list of rules that someone wrote in a book. For of course if you mean the phrase literally, then of course you should always write the best code you can. Need I point out that there is not a single, universally-accepted set of "best practices"? For any rule promoted by one expert, you can almost always find another ...


2

No. Best practices are things that are generally considered to be the best thing to do 99% of the time, but that doesn't mean they always apply to every situation. As a developer your job is to know and use those best practices, but also know when it's safe to cast them aside. This isn't supposed to be self-promotion, but I recently wrote a blog post ...


2

A few assumptions: Microservices can communicate between themselves Implementations of each microservice are not relevant to the external world (this is even easier when abstracted into a container) Imagine a client/server interaction, the client/server might communicate with a JSON API. Or a message broker. The specific implementation does not matter, ...


2

Change the hardcoded endpoint so it can be changed. Read the endpoint from a file containing all your settings. Its pretty easy to do, and allows for other settings to be changed according to other parameters. Possibly the easiest thing for you to do is to read the file if it is present, or default to a fixed value if not - this allows you to drop a new ...


2

Answering the questions an order that makes sense to me: Are the identified processes sensible, or are they too abstract? The items on your process list are rather brief and looks to me more like scenario heading names than processes. As I read it, in 4+1 processes are essentially running programs. ... At the highest level, the process ...


1

Unless someone has a really unique way of addressing this problem, I would think they would buy something already built because there are security issues along with established ways of doing this. First of all should I use NoSQL or SQL for this kind of architecture? From an architecture standpoint, both will work, so consider security as a prime ...


1

This data can be expressed well in a relational database, so a document based database doesn't really offer an advantage Using the database's querying features to narrow down the booking to the doctor and date(s) you're interested in and doing the actual processing in the application should work well. There are perhaps a few hundred bookings per month and ...



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