It may be bad though, in which case leave things as they are (or switch to a fully static approach). This may be a good thing, in which case you could switch to using your approach if you find it easier to work with. We are now using the same AuditInserter to insert two actions. Var inserter = new AuditInserter(new DataContext, new Person) This can be shown by changing the Main to: public class MainProgram Your version of the code behaves quite differently to either static version though. Other folk will have other personal preferences and might even just adopt that caching of parameters approach for all cases (as your former developer seems to have done). If it increased to five, six or more, I'd likely adopt something similar to that former developer. For just those two items, I'd stick with the fully static approach. Which approach you take is a mixture of personal preference and how many parameters you have in the real example. Private void DoSomethingAfter(DataContext dataContext, Private void DoTheInsert(DataContext dataContext, => // do something with person and dataContext here Private void DoSomethingFirst(DataContext dataContext, But we then increase complexity in another respect: the methods now have multiple parameters to allow those values to be passed around: public class AuditInserterĭoTheInsert(dataContext, person, action) => _(_person, action) Īgain that code can be simplified in one respect by just making it all static: we can get rid of the constructor and the fields. Private void DoTheInsert(AuditableAction action) => // do something with _person and _dataContext here => (_dataContext, _person) = (dataContext, person) Private AuditInserter(DataContext dataContext, Person person) => new AuditInserter(dataContext, person).InsertAudit(action) I've taken the liberty of using syntax features in C# 7 to reduce the size of the code to for brevity): public class AuditInserter Public static void Insert(DataContext dataContext,ĭ(person, action) īut let's revisit that code and add some private methods to make it more representative of the real code. All of the static code you show can be reduced to the following with no change of function: public class AuditInserter However, with your clarification that the InsertAudit method would call several other private instance methods, is becomes much clearer what's happening. This clarification changes the static approach from "deeply confused and confusing" to being a viable solution to avoiding passing around parameters.)įrom the example you give, your colleague's code is deeply confused and confusing. The InsertAudit method would call several other private instance methods.". (Answer rewritten in light of the comment, " Sorry, I should've mentioned that I made a very simple example to help show the main design element that confused me. The code is in C# but this issue is not C#-specific. I'm loathe to just blindly follow this existing pattern without understanding what benefits it offers (if any). Is there any benefit of this design? It would be my natural inclination to design it like so: public class AuditInserter Note that this is not an example of the singleton pattern - the object does not hold a reference to a static instance of itself. The constructor is private and construction of the object is handled by the static method. Private void InsertAudit(AuditableAction action) I'm working in a C# codebase that was largely written by a former developer and this pattern is used extensively.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |