Hot answers tagged

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

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

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

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


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

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


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


1

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


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


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


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.



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