Now and again I end up with code along these lines, where I create some objects then loop through them to initialise some properties using another class...
ThingRepository thingRepos = new ThingRepository();
GizmoProcessor gizmoProcessor = new GizmoProcessor();
WidgetProcessor widgetProcessor = new WidgetProcessor();
public List<Thing> GetThings(DateTime date)
{
List<Thing> allThings = thingRepos.FetchThings();
// Loops through setting thing.Gizmo to a new Gizmo
gizmoProcessor.AddGizmosToThings(allThings);
// Loops through setting thing.Widget to a new Widget
widgetProcessor.AddWidgetsToThings(allThings);
return allThings;
}
...which just, well, feels wrong.
Is this a bad idea?
Is there a name of an anti-pattern that I'm using here?
What are the alternatives?
Edit: assume that both GizmoProcessor and WidgetProcessor have to go off and do some calculation, and get some extra data from other tables. They're not just data stored in a repository. They're creating new Gizmos and Widgets based on each Thing and assigning them to Thing's properties.
The reason this feels odd to me is that Thing isn't an autonomous object; it can't create itself and child objects. It's requiring higher-up code to create a fully finished object. I'm not sure if that's a bad thing or not!
ThingRepository is supposed to be the single access point to get collections of Thing's, or at least that's where developers will intuitively look. For that reason, it feels strange that GetThings(DateTime date) should be provided by another object. I'd rather place that method in ThingRepository itself.
The fact that the Thing's returned by GetThings(DateTime date) are different, "fatter" animals than those returned by ThingRepository.FetchThings() also feels awkward and counter-intuitive. If Gizmo and Widget are really part of the Thing entity, you should be able to access them every time you have an instance of Thing, not just for instances returned by GetThings(DateTime date).
If the Date parameter in GetThings() isn't important or could be gathered at another time, I would use calculated properties on Thing to implement on-demand access to Gizmo and Widget :
public class Thing
{
//...
public Gizmo Gizmo
{
get
{
// calculations here
}
}
public Widget Widget
{
get
{
// calculations here
}
}
}
Note that this approach is valid as long as the calculations performed are not too costly. Calculated properties with expensive processing are not recommended - see http://msdn.microsoft.com/en-us/library/bzwdh01d%28VS.71%29.aspx#cpconpropertyusageguidelinesanchor1
However, these calculations don't have to be implemented inline in the getters - they can be delegated to third-party Gizmo/Widget processors, potentially with a caching strategy, etc.
If you have complex intialization then you could use a Strategy pattern. Here is a quick overview adapted from this strategy pattern overview
Create a strategy interface to abstract the intialization
public interface IThingInitializationStrategy
{
void Initialize(Thing thing);
}
The initialization implementation that can be used by the strategy
public class GizmosInitialization
{
public void Initialize(Thing thing)
{
// Add gizmos here and other initialization
}
}
public class WidgetsInitialization
{
public void Initialize(Thing thing)
{
// Add widgets here and other initialization
}
}
And finally a service class that accepts the strategy implementation in an abstract way
internal class ThingInitalizationService
{
private readonly IThingInitializationStrategy _initStrategy;
public ThingInitalizationService(IThingInitializationStrategy initStrategy)
{
_initStrategy = initStrategy;
}
public Initialize(Thing thing)
{
_initStrategy.Initialize(thing);
}
}
You can then use the initialization strategies like so
var initializationStrategy = new GizmosInitializtion();
var initializationService = new ThingInitalizationService(initializationStrategy);
List<Thing> allThings = thingRepos.FetchThings();
allThings.Foreach ( thing => initializationService.Initialize(thing) );
Tho only real potential problem would be that you're iterating over the same loop multiple times, but if you need to hit a database to get all the gizmos and widgets then it might be more efficient to request them in batches so passing the full list to your Add... methods would make sense.
The other option would be to look into returning the gizmos and widgets with the thing in the first repository call (assuming they reside in the same repo). It might make the query more complex, but it would probably be more efficient. Unless of course you don't ALWAYS need to get gizmos and widgets when you fetch things.
To answer your questions:
Is this a bad idea?
From my experience, you rarely know if it's a good/bad idea until you need to change it.
IMO, code is either: Over-engineered, under-engineered, or unreadable
In the meantime, you do your best and stick to the best practices (KISS, single responsibility, etc)
Personally, I don't think the processor classes should be modifying the state of any Thing.
I also don't think the processor classes should be given a collection of Things to modify.
Is there a name of an anti-pattern that I'm using here?
Sorry, unable to help.
What are the alternatives?
Personally, I would write the code as such:
public List<Thing> GetThings(DateTime date)
{
List<Thing> allThings = thingRepos.FetchThings();
// Build the gizmo and widget for each thing
foreach (var thing in allThings)
{
thing.Gizmo = gizmoProcessor.BuildGizmo(thing);
thing.Widget = widgetProcessor.BuildWidget(thing);
}
return allThings;
}
My reasons being:
The code is in a class that "Gets things". So logically, I think it's acceptable for it to traverse each Thing object and initialise them.
The intention is clear: I'm initialising the properties for each Thing before returning them.
I prefer initialising any properties of Thing in a central location.
I don't think that gizmoProcessor and widgetProcessor classes should have any business with a Collection of Things
I prefer the Processors to have a method to build and return a single widget/gizmo
However, if your processor classes are building several properties at once, then only would I refactor the property initialisation to each processor.
public List<Thing> GetThings(DateTime date)
{
List<Thing> allThings = thingRepos.FetchThings();
// Build the gizmo and widget for each thing
foreach (var thing in allThings)
{
// [Edited]
// Notice a trend here: The common Initialize(Thing) interface
// Could probably be refactored into some
// super-mega-complex Composite Builder-esque class should you ever want to
gizmoProcessor.Initialize(thing);
widgetProcessor.Initialize(thing);
}
return allThings;
}
P.s.:
I personally do not care that much for (Anti)Pattern names.
While it helps to discuss a problem at a higher level of abstraction, I wouldn't commit every (anti)pattern names to memory.
When I come across a Pattern that I believe is helpful, then only do I remember it.
I'm quite lazy, and my rationale is that: Why bother remembering every pattern and anti pattern if I'm only going to use a handful?
[Edit]
Noticed an answer was already given regarding using a Strategy Service.
Related
I discovered yesterday that I can simulate a fluent interface if I return the class instance from each method like this...
public class IsThisFluent
{
public IsThisFluent Stuff()
{
//...
return this;
}
public IsThisFluent OtherStuff()
{
// ...
return this;
}
}
Is this all there is to it?
I admit, I'm a bear of very little brain and I want to carry on this this but I thought it might be best to check with a grown up.
Am I missing something?
Is there a 'gotcha' that I haven't spotted with this pattern?
That's pretty much it.
Here's a really good article on it:
http://rrpblog.azurewebsites.net/?p=33
EDIT
The original site seems to have died, so here's WayBackMachine to the rescue
I also really like this example from this answer:
https://stackoverflow.com/a/1795027/131809
public class Coffee
{
private bool _cream;
public Coffee Make { get new Coffee(); }
public Coffee WithCream()
{
_cream = true;
return this;
}
public Coffee WithOuncesToServe(int ounces)
{
_ounces = ounces;
return this;
}
}
var myMorningCoffee = Coffee.Make.WithCream().WithOuncesToServe(16);
Which reminds me, I need a coffee now.
return this is not all there is to fluent interfaces.
Chaining methods is a simplistic form of building a fluent API, but fluent APIs generally look like DSLs (domain specific languages) and are much, much harder to design.
Take Moq as an example:
new Mock<IInterface>()
.Setup(x => x.Method())
.CallBack<IInterface>(Console.WriteLine)
.Returns(someValue);
The Setup method, defined on the type Mock<T>, returns an instance of ISetup<T, TResult>.
The Callback method, defined for ICallback<TMock, TResult> returns an instance of IReturnsThrows<TMock,TResult>. Note that ISetup<T, TResult> extends IReturnsThrows<TMock,TResult>.
Finally, Returns is defined on IReturns<TMock,TResult> and returns IReturnsResult<TMock>. Also note that IReturnsThrows<TMock,TResult> extends IReturnsResult<TMock>.
All these little nuances are there to force you to call these methods in a particular order, and to forbid you from calling Setup twice in a row, for example. Or from calling Returns before you call Setup.
These details are very important to ensure a good user experience.
To read more on designing fluent interfaces, take a look at Martin Fowler's article on FluentInterface. FluentAssertions is another prime example of how complex the design might get - but also of how much more readable the outcome is.
Nope, that's pretty much it.
The idea behind is that you can chain method calls together manipulating internal state as you go. Ultimately the main goal of a Fluent interface is readability, LINQ being a very good example of one.
I am trying to implement the strategy pattern. Here is part of my implementation:
public List<string> GetOrderedEmployeeNames(IOrderByStrategy strategy)
{
return GetEmployeeFullNames().OrderBy(strategy.Order);
}
now every time I call this function I have to write:
var employees = GetOrderedEmployeeNames(new OrderByFamilyName());
Is 'new-ing up' the strategy every time the right way or am I implementing this incorrectly?
If the class that implements IOrderByStrategy doesn't have any state (i.e. behaves the same every time) then you might as well store it in a field somewhere to save having to re-new it.
That said, new is a very efficient operation and if you're not calling it in a tight loop, it may be simpler to keep doing what you're doing.
Not necessarily, although it's probably not hurting anything to create objects as I'm assuming they're mostly methods and don't hold a lot of data.
Some alternatives:
Implement a StrategyFactory that either creates new instances or hold references to flyweights (small objects that are indexed by some key, like a string)
Implement the strategies as singletons, but that may be more overhead than you need if there are a lot of strategies.
You can store a property if the strategy will have same behavior. If not, you can create object with parameters.
private IOrderByStrategy orderByStrategy;
public IOrderByStrategy OrderByStrategy
{
get
{
if(orderByStrategy != null)
return orderByStrategy;
else
return new OrderByStrategy();
}
}
var employees = GetOrderedEmployeeNames(OrderByStrategy);
Second situation:
var employees = GetOrderedEmployeeNames(new OrderByFamilyName("familyname","DESC"));
Take a look at this code.
interface ILoader
{
}
interface ILoader<T>: ILoader
{
T Load();
}
class CarLoader: ILoader<Car>
{
...
}
class TrainLoader: ILoader<Train>
{
...
}
class Container
{
List<ILoader> loaders = new ILoader[] { new CarLoader(), new TrainLoader()};
public T Load<T>()
{
// Finding right loader
var loader = loaders.OfType<ILoader<Car>>.FirstOrDefault();
return loader.Load();
}
}
I've got about 100 of loaders and I need to load a lot of Trains, Cars, etc. I think that List of loaders is very slow (has OfType() linear complexity??), what do you suggest to use instead of list? Dictionary<Type,ILoader> or Hashtable<Type,ILoader> or HashSet<ILoader>? How fast would be for example to use hashset.OfType<ILoader<Car>>(), same as list or faster?
Build a Dictionary<Type, ILoader> and populate it with the loaders. Then you can just do:
ILoader<T> loader = (ILoader<T>) loaderDictionary[typeof(T)];
On the other hand, if you've only got 100 items to look through, even a linear scan isn't exactly going to take long. Have you actually benchmarked a real usage situation and found this to be your bottleneck?
The Enumerable.OfType extension method does run in linear time and it is probably fast enough for your purposes. Don't micro-optimizate your code unless you have measured the performance and are sure that you need to optimize it.
Rather than concentrating on the performance you should first consider the suitability of your design. A good design in general does not need to inspect the types of the object - the information you need should be available in other ways. In this case for example you might want to ask if each loader is capable of loading an object by passing that object to a CanLoad method and returning true or false. This will make your design more flexible.
Loader loader = loaders.First(x => x.CanLoad(myObject));
Now you can have loaders that can load multiple types of objects.
If you want a new Loader each time and you want a one-to-one mapping another option is to also ask the object itself to create a suitable loader:
Loader loader = myObject.CreateLoader();
Each class can implement CreateLoader differently so that you get a Loader of the correct type for your object. By taking advantage of polymorphism this works without ever needing to ask an object what type it is.
One of the questions I was asked was that I have a database table with following columns
pid - unique identifier
orderid - varchar(20)
documentid - int
documentpath - varchar(250)
currentLocation - varchar(250)
newlocation - varchar(250)
status - varchar(15)
I have to write a c# app to move the files from currentlocation to newlocation and update status column as either 'SUCCESS' or 'FAILURE'.
This was my answer
Create a List of all the records using linq
Create a command object which would be perform moving files
using foreach, invoke a delegate to move the files -
use endinvoke to capture any exception and update the db accordingly
I was told that command pattern and delegate did not fit the bill here - i was aksed to think and implement a more favorable GoF pattern.
Not sure what they were looking for - In this day and age, do candidates keep a lot of info on head as one always has google to find any answer and come up with solution.
I sort of agree with Aaronaught's comment above. For a problem like this, sometimes you can overthink it and try to do something more than you actually need to do.
That said, the one GoF pattern that came to mind was "Iterator." In your first statement, you said you would read all the records into a List. The one thing that could be problematic with that is if you had millions of these records. You'd probably want to process them in a more successive fashion, rather than reading the entire list into memory. The Iterator pattern would give you the ability to iterate over the list without having to know the underlying (database) storage/retrieval mechanism. The underlying implementation of the iterator could retrieve one, ten, or a hundred records at a time, and dole them out to the business logic upon request. This would provide some testing benefit as well, because you could test your other "business" logic using a different type of underlying storage (e.g. in-memory list), so that your unit tests would be independent from the database.
A deep understanding of patterns is something you should definitely have as a developer - you shouldn't need to go to Google to determine which pattern to "use" because you won't have enough time to really understand that pattern between when you start reading about it and when you apply it.
Patterns are mostly about understanding forces and encapsulating variation. That is, forces create certain kinds of variation and we have well understood ways of encapsulating those kinds of variation. A "pattern" is a body of understanding about which forces lead to which kinds of variation and which methods of encapsulation best address those.
I have a friend who was teaching a course on patterns and it suddenly struck him that he could solve a given problem "using" (meaning "implementing the encapsulating technique of") every pattern in his course book. It really did a great job of helping drive home the fact that finding the right technique is more important that knowing how to apply a technique.
The Command pattern, for instance, starts with an understanding that sometimes we want to vary when something happens. In these cases, we want to decouple the decision of what to do from the decision of when to do it. In this example, I don't see any indication that when your command should be executed varies at all.
In fact, I don't really see anything that varies so there might not have been any patterns in the problem at all. If your interviewers were saying there were, then they may have some learning to do as well.
Anywho... I'd recommend Design Patterns Explained by Shalloway and Trott. You'll get a deeper understanding of what patterns are really for and how they help you do your job and, the next time they tell you that you are "using" the wrong pattern, you might just be in a position to educate them. That seems to go over pretty well for me... about 20% of the time. :)
I would rather say that the interviewer wanted you to use (or mention) the SOLID object oriented design principles here, and in that process you might use some design pattern.
For instance, we could a make a design like below which adheres to SRP, OCP, and DIP.
internal interface IStatusRecordsToMove
{
List<IRecord> Records { get; }
}
internal interface IRecord
{
string Status { get; set; }
}
internal interface IRecordsMover
{
ITargetDb TargetDb { get; }
void Move(IStatusRecordsToMove record);
}
internal interface ITargetDb
{
void SaveAndUpdateStatus(IRecord record);
}
class ProcessTableRecordsToMove : IStatusRecordsToMove
{
public List<IRecord> Records
{
get { throw new NotImplementedException(); }
}
}
internal class ProcessRecordsMoverImpl : IRecordsMover
{
#region IRecordsMover Members
public ITargetDb TargetDb
{
get { throw new NotImplementedException(); }
}
public void Move(IStatusRecordsToMove recordsToMove)
{
foreach (IRecord item in recordsToMove.Records)
{
TargetDb.SaveAndUpdateStatus(item);
}
}
#endregion
}
internal class TargetTableBDb : ITargetDb
{
public void SaveAndUpdateStatus(IRecord record)
{
try
{
//some db object, save new record
record.Status = "Success";
}
catch(ApplicationException)
{
record.Status = "Failed";
}
finally
{
//Update IRecord Status in Db
}
}
}
i'm working on a fork of the Divan CouchDB library, and ran into a need to set some configuration parameters on the httpwebrequest that's used behind the scenes. At first i started threading the parameters through all the layers of constructors and method calls involved, but then decided - why not pass in a configuration delegate?
so in a more generic scenario,
given :
class Foo {
private parm1, parm2, ... , parmN
public Foo(parm1, parm2, ... , parmN) {
this.parm1 = parm1;
this.parm2 = parm2;
...
this.parmN = parmN;
}
public Bar DoWork() {
var r = new externallyKnownResource();
r.parm1 = parm1;
r.parm2 = parm2;
...
r.parmN = parmN;
r.doStuff();
}
}
do:
class Foo {
private Action<externallyKnownResource> configurator;
public Foo(Action<externallyKnownResource> configurator) {
this.configurator = configurator;
}
public Bar DoWork() {
var r = new externallyKnownResource();
configurator(r);
r.doStuff();
}
}
the latter seems a lot cleaner to me, but it does expose to the outside world that class Foo uses externallyKnownResource
thoughts?
This can lead to cleaner looking code, but has a huge disadvantage.
If you use a delegate for your configuration, you lose a lot of control over how the objects get configured. The problem is that the delegate can do anything - you can't control what happens here. You're letting a third party run arbitrary code inside of your constructors, and trusting them to do the "right thing." This usually means you end up having to write a lot of code to make sure that everything was setup properly by the delegate, or you can wind up with very brittle, easy to break classes.
It becomes much more difficult to verify that the delegate properly sets up each requirement, especially as you go deeper into the tree. Usually, the verification code ends up much messier than the original code would have been, passing parameters through the hierarchy.
I may be missing something here, but it seems like a big disadvantage to create the externallyKnownResource object down in DoWork(). This precludes easy substitution of an alternate implementation.
Why not:
public Bar DoWork( IExternallyKnownResource r ) { ... }
IMO, you're best off accepting a configuration object as a single parameter to your Foo constructor, rather than a dozen (or so) separate parameters.
Edit:
there's no one-size-fits-all solution, no. but the question is fairly simple. i'm writing something that consumes an externally known entity (httpwebrequest) that's already self-validating and has a ton of potentially necessary parameters. my options, really, are to re-create almost all of the configuration parameters this has, and shuttle them in every time, or put the onus on the consumer to configure it as they see fit. – kolosy
The problem with your request is that in general it is poor class design to make the user of the class configure an external resource, even if it's a well-known or commonly used resource. It is better class design to have your class hide all of that from the user of your class. That means more work in your class, yes, passing configuration information to your external resource, but that's the point of having a separate class. Otherwise why not just have the caller of your class do all the work on your external resource? Why bother with a separate class in the first place?
Now, if this is an internal class doing some simple utility work for another class that you will always control, then you're fine. But don't expose this type of paradigm publicly.