Hot answers tagged

61

Yes, it is a code smell (in lots of cases). I think it is difficult to replace if-else with virtual methods in tools In your example, it is quite simple to replace the if/else by virtual methods: class Tool{ public: virtual int GetAttack() const=0; virtual int GetDefense() const=0; }; class Sword : public Tool{ // ... public: virtual ...


22

The major problem with your code is, that whenever you introduce any new item, you not only have to write and update the item's code, you also have to modify your player (or wherever the item is used), which makes the whole thing a lot more complicated. As a general rule of thumb, I think it's always kinda fishy, when you can't rely on normal subclassing/...


8

You're trying to solve a human factor problem with an API-level solution, and I believe it's not going to work. It is most likely the case of XY problem. If the "risk" is losing the data because someone did something stupid (or malicious), you should eliminate this possibility (of data loss) altogether. There should be no "risky" methods whatsoever, because ...


7

I wouldn't use a singleton. It's a recognised anti-pattern, and makes testing difficult. I would much rather inject in a concrete implementation, and have your service reference a DAO interface (allowing you to inject different implementations in)


5

No it is not really a decorator pattern But it is a good way to compose instead of just inheriting. A decorator is an object you can wrap around another object, that alters the behavior of the object, but the resulting object is still used as the original object would be. You can actually wrap as many decorators around the object you want. In your example ...


5

While @DocBrown has given a good answer, it doesn't go far enough, imho. Before you start evaluating the answers, you should evaluate your needs. What do you really need? Below I will show two possible solutions, which offer different advantages for different needs. The first is very simplistic and tailored specifically to what you have shown: class Tool {...


5

To expand on my comment I will give you my opinion on your code : Generics : I believe there is thin line between cases where generics are useful and cases where they are abused and only bring more problems. Yours is way past into the problems area. Just looking at the big generic definition rings an alarm for me. This is augmented by fact that you have ...


4

Model View Controller is one of the oldest if not first design pattern. It was created at a time when few people understood any proper way for objects to interact. Consequently the only common thing implementations have is three separate areas of responsibility: Model, View, and Controller. How they interact and which knows about what is completely up for ...


4

I use your first approach but without throwing anything. The subroutine takes one extra argument, like yours - "I know this is risky but do it anyway", and it returns three possible values: Success Failure Blocked because it's risky and the caller didn't say "do it anyway". Apart from your use case, this is also useful for the case where the operation is ...


4

You could probably have a look at Rules Design Pattern. There is a good video also at Pluralsight, see Rules Pattern (you will need to sign in).


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

Fowler is only referring to the mapping between the in memory representation of the document and the document itself, not the persistence of changes made to the representation. You would still need to separate the responsibility of persistence from the domain model. The key here is that you would have no mappings between those two responsibilities, so ...


3

Your design / domain model is plain wrong, if you have to deal with instanceof. This is a clear usecase OOP was invented for, resp. Polymorphism. treating a bunch of different objects as a family of objects. There are two ways to solve your problem: 1) Define a common base for Indian Books and USBooks. This makes sense, when both are indeed Books. 2) ...


3

In many programming languages, all returned values are objects. As others have said, not being able to use the methods of returned objects forces you to never return anything at all. You should be asking your self, "What are the responsibilities of class A, B and C?" This is why using metasyntactic variable names like A, B and C always solicit the answer "it ...


3

which seems highly coupled. It's not highly coupled. In fact, it's the minimum coupling state. The ClusteringEngine will always depend on the Graph, no matter what you do. Furthermore, either the CentralController or the Graph must depend on the ClusteringEngine, else there won't be any clustering in the system. And finally, one considers that if the ...


3

No, it is not too verbose. I'd say it's close to being a best practice. Having created and modified dates on a per record basis allows one to see how stale that particular data row is. Most systems I have encountered have data retention requirements. By having these dates, one can have a data purge process to keep only a certain amount of data in a ...


3

Let's take the example of a major ERP on the market: all the master data and most of the transaction data carry 4 fields: the author and the time stamp of the record creation and of the last record modification. all the critical field changes (it's customizable what is critical) are logged with the author of the change, the timestamp of the change, the ...


3

would it be a 'bad idea', to implement a policy/practice to always persist data and to always implement 'auto-updating' (if possible) created, updated and deleted properties? Persistence and auditability (not stated but implied) are valuable goals, and it is good to think in that direction for cases where you need them. That said, to answer your questions: ...


2

When you want to add caching, data validation, monitoring, persistance or indeed logging not just to a specific class or method, but to a whole range of them throughout your application, this is called a cross-cutting concern. I can think of no software pattern that solves this problem cleanly. And though the Decorator is a fine pattern, you will find it ...


2

In my opinion, you can use one method (for each service function) and differentiate callbackful and callbackless version by either allowing null callback to be passed (idea#1) or by using callback to be registered by setCallback like your second idea (idea#2). Callback as argument (idea#1) public Response method(ServiceCallback callback) throws IOException ...


2

To provide a different perspective than the already existing answer I would say that it depends. The generic one is more reusable, but the domain-specific one signals intent and better separates your domain model from the choice of persistance. If you do var user = repo.GetUser(id); user.Enabled = false; repo.Update(user); Then the repo has no real idea ...


2

You don't need inheritance in this case, you need composition: public interface Manager { void manage(); } public class Mary implements Employee, Manager{ public void work(){ //Mary's implementation of work } public void manage(){ //manage } } Java allows classes to implement multiple interfaces, and is a good ...


2

Here is a good explaination on differentiating association, aggregation, and composition. But here's a thing. If you try to show everything your system is capable of (or every description of your system) on the same diagram, you're going to run out of relationships, or end up reusing the relationship kinds with widely different meaning on the same diagram. ...


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

I will try to be exhaustive about the possible solutions that you might use. As you wrote, I consider that a product has the following attributes : id, name, availability 1. Designing a resource for each attributes /products/555/name: GET returns the current name of the product id 555. PUT newname modify the current name of the product id 555 with newname ...


2

According to Demeter's law, is a class allowed to return one of its members? Yes it most certainly is. Let's look at the main points: Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to strangers. Only talk to your immediate friends. ...


2

If you have a small, fixed number of different part types which will be seldom extended, you can keep this pragmatic and give your PersisterFactory a handful of different methods like CreateDesignPersister, CreatePlotPersister or CreateSelectionPersister. If each of those classes contains only a single persisting method, even that maybe overengineering, a ...


1

Apart from classes which were specifically appointed to return objects [...] I don't quite understand this argument. Any object can return an object as a result of a message invokation. Especially if you think in "everything as object". Classes however, are the only objects that can instantiate new objects of their own kind by sending them the "new" ...


1

Is there a recommended way to handle this scenaio? You need to review Jim Webber's talk on DDD for Restful systems. The basic plot - to modify your aggregates, you deliver documents (aka messages) to your HTTP endpoints, and the changes made to your aggregates are a side effect of the document manipulation. So solution (a) is heading the right direction. ...


1

Would it make sense to create an interface for each handler to provide access only the settings that are of handler's concern I would generally say yes. If each object takes a generic config then that makes life very easy for you (the programmer), but the user/client is only going to discover missing configuration during runtime. I would rather have the ...



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