13

Your first problem is that you think of the design as "wrong." That's really not the right way to consider things. Rather, different designs make different design trade-offs. Any design has pros and cons that have weighed against each other. If there is a problem with the design its not that is "wrong" but rather that it makes poor choice of trade offs. Don'...


4

I think you are making a common junior-level programmer error in your judgement here. Because the solution is not the way you would have done it, you want to redesign it. One of the most important things you need to become comfortable with is that whether the design is the way you think it should be doesn't matter. It really, truly doesn't matter at all. ...


2

Why not use the "classic" approach to the strategy pattern with a base class EmailTemplateStrategy, a pure virtual method buildTemplate, and derivated classes like BuildReceiptTemplateStrategy, BuildVoidTemplateStrategy, BuildRefundTemplateStrategy? This is technically not much different from what you have now, but it has the following advantages A ...


1

Yes, Yes, and Yes You have struck on all the ways for passing information around. Construct a container and refer to it everywhere Pass many, many arguments through the function signature Construct an Agent and have them solve retrieving the information based on a request. There really isn't a best way. What might be reasonable will depend on the ...


1

When it comes to business logic we agree that DRY principle is a cornerstone of structuring it well. However, this is not always true for the database world. The main reason is that assembling needed information from different sources requires additional costs. If we talk about the same database-scenario this is what denormalization is for: sometimes you ...


1

First choice is better for security and independence between tenants, like the choice about database.But you have to build tools to handle it. Failure of one queue, don't expose failure to other tenants. First is not simple technically, but have functionals advantages : limited failure independence between tenants/confidentiality, eg: data cannot be ...


1

Your code is contradictory. Here, you state that the content of your ITypeAData object is intended as a read-only value: public interface ITypeAData { int Value { get; } } Here, you clearly intend to be able to set the value of your ITypeAData content: (dataManager.TypeAData as TypeAData).Value = 0; This is contradictory. Either it's intended to ...


1

I use this same style with my video game development with Unity 3D. I create components like Health, Input, Stats, Sound, etc. and add them to an Game Object to build up what that game object is. Unity already has mechanics to add components to game objects. However, what I found was most everyone was querying for components or directly referencing ...


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