In a previous job, my manager suggested use of a Translator pattern for converting data from a DataTable to objects. Basically, the Translator class had only static (i.e. class) methods so it was an aggregation of function calls. My initial approach was to implement constructors for each object that could take a DataTable row as an argument and create an instance that corresponded to the data.
He said that the Translator class had been suggested by Microsoft, and provided better modularity of code. I can see this point, but at the same time it seems like a very non-OO approach (although the Visitor pattern has similar characteristics).
Have any of you used this pattern, and what do you think of it? pros and cons?
From C2.Com it appears that the Translator pattern is a non-OOP implementation of the visitor pattern. It notes and the end of the article a few of the drawbacks, including the fact that in OOP semantics it is difficult to express (but not code), in other words it will work fine but may not make a lot of sense if you are using pure OOP for the rest of your code.
I think you are talking about Entity Translator. I think that the translator in this scenario is naturally a static method. Where it lives is a matter of aesthetics. It should also be quite easily unit tested as it should only have dependencies on two data structures that it translates between. Kind of sounds like another name for their "data contract" is DTO (Data Transfer Object).
If you can perform the mapping without any external dependencies, then there's really no use in utilizing anything other than a static method.
Maybe I'm missing something, but why not just use linq?
IEnumerable<Customer> customerQuery =
from cust in customers
where cust.City == "London"
select cust;
foreach (Customer customer in customerQuery)
{
Console.WriteLine(customer.LastName + ", " + customer.FirstName);
}
Anyway, the TranslatorPattern is about changing the data structure from one representation to another equivalent structure. Here http://c2.com/cgi/wiki?TranslatorPattern is the deeper info on that.
Related
A recent question here made me rethink this whole helper classes are anti pattern thing.
asawyer pointed out a few links in the comments to that question:
Helper classes is an anti-pattern.
While those links go into detail how helperclasses collide with the well known principles of oop some things are still unclear to me.
For example "Do not repeat yourself". How can you acchieve this without creating some sort of helper?
I thought you could derive a certain type and provide some features for it.
But I bellieve that isnt practical all the time.
Lets take a look at the following example,
please keep in mind I tried not to use any higher language features nor "languagespecific" stuff. So this might been ugly nested and not optimal...
//Check if the string is full of whitepsaces
bool allWhiteSpace = true;
if(input == null || input.Length == 0)
allWhiteSpace = false;
else
{
foreach(char c in input)
{
if( c != ' ')
{
allWhiteSpace = false;
break;
}
}
}
Lets create a bad helper class called StringHelper, the code becomes shorter:
bool isAllWhiteSpace = StringHelper.IsAllWhiteSpace(input);
So since this isnt the only time we need to check this, i guess "Do not repeat yourself" is fullfilled here.
How do we acchieve this without a helper ? Considering that this piece of Code isn't bound to a single class?
Do we need to inherit string and call it BetterString ?
bool allWhiteSpace = better.IsAllWhiteSpace;
or do we create a class? StringChecker
StringChecker checker = new StringChecker();
bool allWhiteSpace = checker.IsAllwhiteSpace(input);
So how do we acchieve this?
Some languages (e.g. C#) allow the use of ExtensionMethods. Do they count as helperclasses aswell? I tend to prefer those over helperclasses.
Helper classes may be bad (there are always exceptions) because a well-designed OO system will have clearly understood responsibilities for each class. For example, a List is responsible for managing an ordered list of items. Some people new to OOD who discover that a class has methods to do stuff with its data sometimes ask "why doesn't List have a dispayOnGUI method (or similar such thing)?". The answer is that it is not the responsibility of List to be concerned with the GUI.
If you call a class a "Helper" it really doesn't say anything about what that class is supposed to do.
A typical scenario is that there will be some class and someone decides it is getting too big and carves it up into two smaller classes, one of which is a helper. It often isn't really clear what methods should go in the helper and what methods should stay in the original class: the responsibility of the helper is not defined.
It is hard to explain unless you are experienced with OOD, but let me show by an analogy. By the way, I find this analogy extremely powerful:
Imagine you have a large team in which there are members with different job designations: e.g, front-end developers, back-end developers, testers, analysts, project managers, support engineers, integration specialists, etc. (as you like).
Each role you can think of as a class: it has certain responsibilities and the people fulfilling those responsibilities hopefully have the necessary knowledge to execute them. These roles will interact in a similar way to classes interacting.
Now imagine it is discovered that the back-end developers find their job too complicated. You can hire more if it is simply a throughput problem, but perhaps the problem is that the task requires too much knowledge across too many domains. It is decided to split up the back-end developer role by creating a new role, and maybe hire new people to fill it.
How helpful would it be if that new job description was "Back-end developer helper"? Not very ... the applicants are likely to be given a haphazard set of tasks, they may get confused about what they are supposed to do, their co-workers may not understand what they are supposed to do.
More seriously, the knowledge of the helpers may have to be exactly the same as the original developers as we haven't really narrowed down the actual responsibilities.
So "Helper" isn't really saying anything in terms of defining what the responsibilities of the new role are. Instead, it would be better to split-off, for example, the database part of the role, so "Back-end developer" is split into "Back-end developer" and "Database layer developer".
Calling a class a helper has the same problem and the solution is the same solution. You should think more about what the responsibilities of the new class should be. Ideally, it should not just shave-off some methods, but should also take some data with it that it is responsible for managing and thereby create a solution that is genuinely simpler to understand piece by piece than the original large class, rather than simply placing the same complicated logic in two different places.
I have found in some cases that a helper class is well designed, but all it lacks is a good name. In this case, calling it "Builder" or "Formatter" or "Context" instead of "Helper" immediately makes the solution far easier to understand.
Disclaimer: the following answer is based on my own experience and I'm not making a point of right and wrong.
IMHO, Helper classes are neither good nor bad, it all depends on your business/domain logic and your software architecture.
Here's Why:
lets say that we need to implement the idea of white spaces you proposed, so first I will ask my self.
When would I need to check against white spaces?
Hence, imagine the following scenario: a blogging system with Users, Posts, Comments. Thus, I would have three Classes:
Class User{}
Class Post{}
Class Comment{}
each class would have some field that is a string type. Anyway, I would need to validate these fields so I would create something like:
Class UserValidator{}
Class PostValidator{}
Class CommentValidator{}
and I would place my validation policies in those three classes. But WAIT! all of the aforementioned classes needs a check against null or all whitespaces? Ummmm....
the best solution is to take it higher in the tree and put it in some Father class called Validator:
Class Validator{
//some code
bool function is_all_whitespaces(){}
}
so, if you need the function is_all_whitespaces(){} to be abstract ( with class validator being abstract too) or turn it into an interface that would be another issue and it depends on your way of thinking mostly.
back to the point in this case I would have my classes ( for the sake of giving an example ) look like:
Class UserValidator inherits Validator{}
Class PostValidator inherits Validator{}
Class CommentValidator inherits Validator{}
in this case I really don't need the helper at all. but lets say that you have a function called multiD_array_group_by_key
and you are using it in different positions, but you don't like to have it in some OOP structured place you can have in some ArrayHelper but by that you are a step behind from being fully object oriented.
This is a question independent from languages.
Conceptually, it's good to code for interfaces(contracts) instead of specific implementations. I've got no problem understanding merits about the practice.
However, when I really code in that practice, the users of my classes, from time to time need to cast the interfaces for specific needs of specific functions provided by specific classes that implement that interface.
I understand there must be something wrong, either on my side or on the user's side, as the interface should expose all methods/properties(in the case of c#) that can possibly be necessary.
The code base is huge, and the users are clients.
It won't be particularly easy to make changes on either side.
That makes me wonder some downsides about using interface as parameter and return type.
Can people please list demerits of the practice? And please, include any solution if you know how to work around it.
Thanks a lot for enlightening me.
EDIT:
To be a bit more specific:
Assume we have a class called DbInfoExtractor. It has a public method GetInfo, as follows:
public IInformation GetInfo(IInfoParam);
where IInformation is an interface implemented by specific classes like VideoInfo, AudioInfo, TextInfo, etc; IInfoParam is an interface implemented by specific classes like VidoeInfoParam, AudioInfoParam, TextInfoParam, etc;
Apparently, depending on the specific object passed into the method GetInfo, the DbInfoExtractor needs to take different actions, as it is reasonable to assume that for different types of information, the extractor considers different sets of aspects(e.g. {size, title, date} for video, {title, author} for text information, etc) as search keys and search for relevant information in different ways.
Here, I see two options to go on:
1, using if ... else ... to decide what actually to take depending on the type of the parameter the GetInfo method receives. This is certainly bad, as avoiding this situation is one the very reasons we use polymorphism.
2, We should call IInfoParam.TakeAction(), and each specific implementation of IInfoParam has its own TakeAction() method to actually search and find the corresponding information from the database.
This options seems better, but still quite bad, as it shouldn't be the parameter that takes action searching and finding the information; it should be the responsibility of DbInfoExtractor.
So how can I delegate the TakeAction back to DbInfoExtractor? (I actually wrote some code to do this, but it's neither standard nor elegant. Basically I make parameter classes nested classes in DbInfoExtractor, so that they can call various versions of TakeAction of DbInfoExtractor.)
Please enlighten me!
Thanks.
Thanks.
Why not
public IVideoInformation GetVideoInformation(VideoQuery);
public IAudioInformation GetAudioInformation(AudioQuery);
// etc.
It doesn't look like there's a need for polymorphism here.
The query types are Query Objects, if you need those. They probably don't need to be interfaces; they know nothing about the database. A simple list of parameters (maybe just ID) might be sufficient.
The question is what does the client have, and what do they want? That's your interface.
Switch statements and casting are a smell, and typically mean that you've violated the Liskov substitution principle.
NOTE: I am asking this question out of inquisitiveness and not questioning the importance of a language feature.
Looks to be a great feature introduced to people from imperative world of programming.
I am new to Scala and still trying to figure out where all, do its massive sets of constructs fit in and can be leveraged.
Pattern matching can definitely do stuff 100 x better than the switch case.
but still, it is a case construct over which we use to prefer polymorphism since the time OOP came out.
So in short what I am finding difficult to understand is, If switch case encourages duplication and we better write case related code into respective classes then How does Scala's pattern matching overcome this ?
We can still have classes or generic classes for various cases and again leverage polymorphism to our need.
It's the matter of the difference between objects and data structures.
If you are dealing with objects use the subtype polymorphism - adding new types doesn't require recompilation, retesting or redeployment of the existing ones, whereas adding a new algorithm (a method on the interface, which is at the top of the hierarchy) does.
If you are dealing with data structures use patter matching - adding new algorithms doesn't require recompilation, retesting or redeployment of the existing ones, whereas adding a new type does.
Read more about it here.
Patter matching is a great feature because it is easy to use.
It solves the problem of "how to bring functionality to an object system" far better than most design patterns in widely used object-oriented languages. For example there is the Visitor pattern, which separates an algorithm from its object structure. The idea is great because it allows us to change behavior of our objects without touching their classes. But on the other side this pattern fails in overcomplexity and verbosity of notation. With pattern matching, this can be solved easily:
def calc(e: Expression): Double = e match {
case Num(n) => n
case Add(a, b) => calc(a)+calc(b)
case Sub(a, b) => calc(a)-calc(b)
...
}
This separates the calculation of an AST from its definition and is much better to read than the polymorphic Visitor pattern.
Because patter matching is so easy, we can use it everywhere - you will find it on places which you have never thought of in most OO languages. A great example are Actors, which use algebraic data types (ADT) to communicate between each other:
sealed trait Message
case class Hello(name: String) extends Message
case class Bye(name: String) extends Message
case class Question(q: Symbol) extends Message
class MySelf extends Actor {
def receive {
case Hello(name) => println("Hello "+name)
case Bye(name) => println("Buy "+name)
case Question('AreYouOk) => sender answer "I'm ok"
...
}
}
I wish you a lot of fun by implementing this with the Visitor pattern!
I see few points where pattern matching completes OOP and allows for more modular programming.
When you have a big project, you want to avoid putting "too much behaviour" inside your domain classes. You can move the behaviour outside, and typically have a method which receives a class at the top of a hierarchy and matches against the children classes.
When you are using a specific libraries and you would like to add behaviour but you cannot modify the sources . You can also use implicit conversion for this, but in simple cases pattern matching is faster and easier.
To answer your question, I would probably say that you underestimate the code reusage pattern matching can bring: when you create a match block that creates a PartialFunction. If you need to reuse your pattern-matching blocks, you can use PartialFunction chaining, through the orElse method. This also brings benefits when designing a hierarchical set of handlers of a specific object, since the matches are executed in order.
Inheritance and case constructs are both valid ways to achieve polymorphism. They are good in slightly different situations. Unlike inheritance based polymorphism, pattern match is not extensible, however often you don't need it to be. Many structures in functional programming, such as Option, Either or :: can be used more concisely with pattern matches that oop polymorphism and if statements. In general any problem could be solved with either type of polymorphism. It is only a matter of elegance.
They don't they actually do have that exact problem if you abuse them.
Just as the polymorphy by inheritance gets into problems when it causes your classes to attract all kinds of methods that don't really belong into that class.
While Java has some reasonable strong support for inheritance the switch statement is just a joke.
In Scala you have even stronger support for inheritance and the amazing pattern matching.
It's your job to pick the right hammer for your nail.
This is a question about using an object-oriented language. I've been using C++ to solve Project Euler for a while, and I recently read in an article that a lot of people treat C++ like a procedural language, since you can get away without creating classes. I've been doing exactly that.
My question is whether it's "bad" to just be writing functions in an object-oriented languageint mult_order(int base, int mod) for multiplicative order, gcd(int a, int b) for gcd, but without putting them in a class). I've been "reinventing the wheel" a lot for the purpose of learning--should I put them in a library, or create a Math class or something along those lines?
From what I've been taught (and what I've experienced), the underlying idea behind OOP is a simple one:
Use it when it makes your life easier.
It could easily be the case that, for your purpose, using a class wouldn't make things easier - you don't have a reason to repeatedly access a single object that performs these mathematical operations - or creating a class would create unnecessary overhead.
For your example, I think you'll be fine without objects, but do consider that somewhere in the future, it may be necessary to create an object that can handle those operations.
It seems you need to be using a namespace instead of a class.
There's nothing wrong with having functions that don't belong to a class, but you should still group them together.
Use a class when you need properties for an object, or inheritance, or state, not just so you can group functions together.
The main benefit using classes is going to give you is reuse through inheritance. So if you find you have situations where you have some common code, and then other sections of code that are variations on that, then making classes would help you. If not, then you are probably OK the way you are. Not every problem has to be solved with object oriented programming.
I remember back when MS released a forum sample application, the design of the application was like this:
/Classes/User.cs
/Classes/Post.cs
...
/Users.cs
/Posts.cs
So the classes folder had just the class i.e. properties and getters/setters.
The Users.cs, Post.cs, etc. have the actual methods that access the Data Access Layer, so Posts.cs might look like:
public class Posts
{
public static Post GetPostByID(int postID)
{
SqlDataProvider dp = new SqlDataProvider();
return dp.GetPostByID(postID);
}
}
Another more traditional route would be to put all of the methods in Posts.cs into the class definition also (Post.cs).
Splitting things into 2 files makes it much more procedural doesn't it?
Isn't this breaking OOP rules since it is taking the behavior out of the class and putting it into another class definition?
If every method is just a static call straight to the data source, then the "Posts" class is really a Factory. You could certainly put the static methods in "Posts" into the "Post" class (this is how CSLA works), but they are still factory methods.
I would say that a more modern and accurate name for the "Posts" class would be "PostFactory" (assuming that all it has is static methods).
I guess I wouldn't say this is a "procedural" approach necessarily -- it's just a misleading name, you would assume in the modern OO world that a "Posts" object would be stateful and provide methods to manipulate and manage a set of "Post" objects.
Well it depends where and how you define your separation of concerns. If you put the code to populate the Post in the Post class, then your Business Layer is interceded with Data Access Code, and vice versa.
To me it makes sense to do the data fetching and populating outside the actual domain object, and let the domain object be responsible for using the data.
Are you sure the classes aren't partial classes. In which case they really aren't two classes, just a single class spread across multiple files for better readability.
Based on your code snippet, Posts is primarily a class of static helper methods. Posts is not the same object as Post. Instead of Posts, a better name might be PostManager or PostHelper. If you think of it that way, it may help you understand why they broke it out that way.
This is also an important step for a decoupling (or loosely coupling) you applications.
What's anti-OOP or pro-OOP depends entirely on the functionality of the software and what's needed to make it work.