New answers tagged

0

This could be a good strategy for a search algorithm. Supose you have recursive algorithm that performs very deep searches. When you found the element that satisfies your search criteria you can just throw an "OnFoundEvent". If you found nothing, you can throw an "OnNotFoundEvent". With this technique you skip all the backtracking mechanism caused by the ...


0

The real question here is "what is the consequence of failure?" If you delete something and it's not there, who cares? You wanted it gone anyway. If you want to insert data and it fails, what can you possibly do? Nothing, really. How, or even if you communicate errors largely depends on the fault tolerance of that transaction. Deleting something that ...


2

According to the Open/Close Principe (OCP): Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. Let's examine your static factory architecture under this perspective: Imagine that we want to extend our design horizontally with a subclass ProductThree. How could the makeProduct() ...


2

The reason you don't see static factory methods listed in the GoF book is because this pattern doesn't use polymorphism in any interesting way. Your diagram suggests this, but most languages do not support the structure it shows. Specifically, a static method cannot also be virtual. There is no instance object to dispatch on. It is not possible to override a ...


0

I'd take a look at what would be useful to whatever calls your delete method. At the moment, client code calling this method will see a false condition when the item isn't there to delete, or is not able to delete... How should the client code react? Is it important that your client code does something in either case? Without knowing what the application ...


0

The answer to your question is: it depends. What you are currently doing is called exception suppression, that is calling a method which may throw and returning false when it indeed happens. Is it a good practice? That is difficult to answer without knowing exactly what you want from the method where you are suppressing the exception. I personally have ...


1

For the most part rule Preconditions is validation. With the approach of keeping validation outside of Rule action and execution flow you will get: You will be able to reuse Preconditions. - In most cases it's a useless flexibility. Moreover usually you will have rules only with one precondition and one rule action. There will be a problem of sharing data ...


1

With a little guidance from @RobertHarvey I found a StackOverflow answer about Presentation Models. A presentation model is a utility class that is used to render data on a screen or report. Presentation models are typically used to model complex data structures that are composed from data from multiple DTO’s. Presentation models often represent a ...


6

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

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).


1

I think most applications should have them. These values are more of a convenience for trouble-shooting and other support needs. Soft deletes have benefits as well, but you always have to include them in your query logic. Just because you can use them, they're not enough. Many auditing needs require more data and sophistication even beyond logging. ...


4

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: ...


4

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

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 ...


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

What you are decribing is a common design pattern, and, as @Robert commented, its name is abstract factory remember SRP means, that a entity must have only one reason to change not that it must only do one thing at all, or return only one type of result. So no, you are not breaking SRP.


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 ...


0

The standard way of resolving circular references (and removing coupling) in object oriented systems is dependency inversion. To do this, we'd take one of your concrete classes (most likely the ClusteringEngine, as it seems the most self-contained, but theoretically at least you could do this for your Graph instead), and declare an interface for it. All of ...


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. ...


4

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 ...


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" ...


0

Apart from classes which were specifically appointed to return objects - such as factory and builder classes - is it okay for a method to return an object? Why wouldn't it be? You seem to suggest that it's necessary to signal to your fellow programmers that the class is specifically meant to return objects, or it must not return objects at all. In ...


0

Interestingly, if you apply SOLID to your OOP codebase rigorously (to extreme), you'll start to see functional programming! I literally laughed at myself when I saw it. Now I'm fully sold by FP.


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, ...


0

Most of the time, it doesn't need to know; aggregates with correctly designed boundaries don't need to know about outside state to maintain its invariant (that's basically the definition of an aggregate boundary). When an aggregate needs to know about state outside it's own boundary, the usual answer is a DomainService. The aggregate invokes a query on the ...


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. ...


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 ...


0

Do not create tokens in the business layer unless your company's business is security. It can either be its own project or part of the web api. The web api is, after all, the trust border for the application, and the tokens are likely translated (by web api) into user objects for your other layers. Ideally, you shouldn't handling this in your own code at ...


0

To quote from this answer: ViewModel Presenter projects the data from the Model into a format that fits the View. The Model is the data in a way that makes sense to store the data. The Model knows the current washing state, has the ability to start/stop washing, can open the door, etc. The Model is also deciding when it will refuse to open the door. ...


0

Having a block of code that knows about all possible "tools" is not great design (especially since you'll end up with many such blocks in your code); but neither is having a basic Tool with stubs for all possible tool properties: now the Tool class must know about all possible uses. What each tool knows is what it can contribute to the character that uses ...


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 ...


0

I think one way to recognise the flaws in this approach is to develop your idea to its logical conclusion. This looks like a game, so at some stage you will probably start to worry about performance and swap those string comparisons for an int or enum. As the list of items gets longer, that if-else starts to get pretty unwieldy, so you may consider ...


1

Nearly ever user interface is going to require the ViewModel to have state that does not belong in the model so I believe that there is no such thing as a "stateless" ViewModel in MVVM. Some examples: Enabled/Disabled state of user interface controls Selected items (listboxes, radio buttons, etc) Input data that has not yet been validated or committed to ...


0

As written, it "smells," but that might just be the examples you gave. Storing data in generic object containers, then casting it to get access to the data is not automatically code smell. You will see it used in many situations. However, when you use it, you should be aware of what you're doing, how you're doing it, and why. When I look at the 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 {...


0

If one uses polymorphism it is always best if all code that cares about which class is used is inside the class itself. This is how I would code it: class Tool{ public: virtual void equipTo(Player* player) =0; virtual void unequipFrom(Player* player) =0; }; class Sword : public Tool{ public: int attack; virtual void equipTo(Player* player) ...


1

Why not creating abstract methods modifyAttack and modifyDefense in the Tool class? Then each child would have their own implementation, and you call this elegant way: for(Tool* tool : tools){ currentAttack = tool->recalculateAttack(currentAttack); currentDefense = tool->recalculateDefense(currentDefense); } // proceed with new values for ...


0

As previously stated, this is a serious code-smell. However, one could consider the source of your problem to be using inheritance instead of composition in your design. For example, given what you've shown us, you clearly have 3 concepts: Item Item which can have attack. Item which can have defense. Note that your fourth class is just a combination of ...


-3

There's no answer that says that it doesn't smell so I'll be the one that stands for that opinion; this code is totally fine! My opinion is based on the fact that sometimes it's easier to move on and allow your skills to gradually increase as you create more new stuff. You can get stuck for days on making a perfect architecture, but probably nobody will ever ...


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 ...


0

In general I avoid implementing several classes/inheriting if it's just for communicating data. You can stick to a single class and implement everything from there. For your example, this is enough class Tool{ public: //constructor, name etc. int GetAttack() { return attack }; //Endpoints for your Player int GetDefense() { return defense }; ...


1

What stops us from implementing INotifyDataErrorInfo, INPC and all the stuff at the level of models? That how the model is described by the business and how it is shown in the UI can (and will) be different. While simple scenarios might make it seem that models and UIs are exactly the same, reality is not so simple. ViewModel's primary purpose is to ...


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 ...


0

A lot of answers here say that ACLs are "not just" about wrapping messy code. I'd go further and say they are not about that at all, and if they do then that is a side benefit. An anti-corruption layer is about mapping one domain onto another so that services that use second domain do not have to be "corrupted" by concepts from the first. ACLs are to domain ...


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/...


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 ...


1

Generally speaking, if you ever have the need to use if (in combination with requiring the type of an instance) in any OOP language, that's a sign, that something smelly is going on. At least, you should have a closer look at your models. I would model your Domain differently. For your usecase a Tool has an AttackBonus and a DefenseBonus - which could both ...


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 ...


0

If you stick to the more general methods, update, insert, findById, findAll, delete, your code will likely be more re-usable. By this I mean that instead of writing a specific method for every scenario you will find that you can simply expose the more general methods and use those for the specific cases that are needed. For example, I might need to disable ...



Top 50 recent answers are included