I have two classes, one for contacts and another for organisations. Each contact belongs to an organisation and an organisation can have many contacts.
I want a function which creates a contact where one of the parameters is the organisation name. If the organisation name already exists then the contact will be assigned to that existing organisation. Otherwise, a new organisation will be created on the spot for the contact.
Since this function creates a contact and can also possibly create an organisation, my first thought was to create a helper class for it since it doesn't seem to belong to either class. I've been led to believe that helper classes are bad practice in OOP so I'm looking for other suggestions. How would you implement this without the use of a helper class?
It is very difficult to define what exactly is good practice in OOP and what isn't without looking at the specific case in detail. The concerns you are stating are valid, here's my answer to those:
Helper classes are not necessarily "bad practice" in OOP
There are quite a few situations, where helper classes are the way to go. If those helper classes simplify your design, they are actually favorable.
An object function may create other objects - this does not mean it has to go into a helper class.
If your contact creates an organization, that's fine. If an organization creates a contact, that's fine as well. Those two classes are part of your object design and may depend on one another without violating any design rules in OOP. I don't see why your code "should" go into a helper class at all.
Related
I have classes using the strategy pattern (each class has the same single method, but implements it very differently). I have another class which chooses the implementation to use based on runtime-accessible values. I have one final class which basically pulls the others together, calls the necessary methods of the implementing class and formats the output.
What could I name this controller class to make it at least semi-clear what it is for? Before someone asks, it is already a very small class (< 100 lines), not worth splitting - I'm confident that it's not because of multiple responsibilities that I'm having trouble naming it.
I want to say "controller" - but that's already a specific concept in MVC architecture (which our app is using). Any ideas? Is there an accepted name for the pattern I'm describing?
In OOP, classes should generally be named after what they are; class names should be nouns. You already know that.
The problem with class names like XyzManager or XyzController is that although technically they are nouns, they're really verbs disguised as nouns. Thus, such classes are named after what they do, instead of what they are. That makes them not objects, but services, or functions.
Now, naming is hard, and sometimes it can't be avoided with an XyzManager. Often, when it happens, it's because you've not yet realised what concept the class really should encapsulate. Still, you should strive to identify what the class is, instead of what it does, and name it after that.
FWIW, I often use a thesaurus (there are several excellent online services for that) to find a good name.
I would like to name it Service
Example: if you have a TaxStrategyGerman, TaxStrategyFrench that are chosen by TaxStrategyFactory and used by TaxCalculationService.
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.
Before I jump into the meat of the question, let me note that this is a purely theoretical query. I'm not interested in this for practical reasons, I'm interested in the underlying OOP theory on how to handle this type of situation.
In a project I'm working on, I have two closely related classes. One is the generic 'user' class. The other is subclassed, and adds additional features used by certain users -- for a generic example, think a 'moderator' class.
How do I handle public methods that are available on the user class that don't make sense for the child to have called?
For example, it makes perfect sense to call User::getUserWithId(id) (this method retrieves data from the DB and initializes and returns the user class with that data); it doesn't make as much sense (if any) to use that method with the moderator class.
Should I just ignore it -- if a user calls moderator::getUserWithId(id), they're still getting a user, exactly what they asked for. Should I override it to return a moderator, despite the method name? Or is there something in OOP land I'm not familiar with that lets me 'block' the call?
If you have methods in your base class that don't make sense in your subclass, then I think you need to re-evaluate if you should model these classes via an inheritance relationship. Needing to hide members of a base class in a subclass is a red flag that indicates modeling this via an inheritance relationship is problematic.
An inheritance relationship should indicate an "is a" relationship. For your example, a moderator object "is a" user object and thus should have the same methods and properties as the user object. If it does not, then it would appear that it does not have a true inheritance relationship with its base user class.
In this case, you might want to consider using interfaces instead of inheritance. You can factor the common functionality between the User and Moderator classes into an interface. If there is common code that they can share, then you can use composition to achieve this, by creating a common implementation of the interface and then passing it to the classes that need to reuse this code. For further information, see here and here.
As the author in the second link above puts it:
Does TypeB want to expose the complete interface (all public methods no less) of TypeA such that TypeB can be used where TypeA is expected? Indicates Inheritance.
Does TypeB only want only some/part of the behavior exposed by TypeA? Indicates need for Composition.
From your need to hide a member of the base class, it seems that you are in the second category, and might want to explore using composition and an interface.
Yesterday I left a response, that somehow got lost. I think, #Joe Alfano has a very good explanation that addresses your "theoretical" and also particular questions.
Beside that, In my opinion, one source of your problem might be that you are doing database access in your Domain Object. In general, unless there is a compelling reason, this is not a good practice. If you remove that database access into a separate layer like Data Access Layer (DAL) this problem goes away. You won't have User::getUserWithId(id) things in your classes, they will be handled in DAL. Like
class UserDao {
User getById(id)
}
Class ModeratorDao {
Moderator getById(id)
}
If you go with DAL-like approach, then you will also find ways to re-factoring code, which is a separate thing.
I'm hoping someone can help me decide the best way to model this design for what sounds like should be a simple use case.
I have a Client domain class. I have a Person command object and a Firm command object which represents either a firm or an organization.
I also have subclasses, lets call them for ClientSubClass1 and ClientSubClass2 for the sake of naming, that both extend Client.
Where I'm puzzled is that a client should be able to be either a person or a firm.
So the best way forward I feel is to use embedding and embed both a Firm class and Person class into the Client class and add a flag that indicates whether the client is a person or firm.
Otherwise I can't see how to use inheritance to accomplish what I need.
Any thoughts would be really appreciated, thanks.
In Grails you can use inheritance in your domain classes, and GORM will create and manage a flag in the database for you without you needing to explicitly declare one. I would create Person and Firm domain classes that inherit from Client.
Command classes are mainly useful for binding parameters in requests to controller actions, which is somewhat unrelated to how your data is stored and retrieved.
Well just to answer this question and wrap it up, I decided to create a higher level Contact domain class, which has a Person and Organization sub class (tableperHierarchy false).
A Client extends Person and contains an embedded Organization, and a flag to indicate whether when referring to that Client I should use the Person details or the Organization details, for instances such as when I want to display the name of the client, I know whether to use the personal name (title, forename, initials, surname) or the firm name from the embedded Organization.
Within the Contact class definition I also use an embedded Address class, held in 'src/groovy' so it doesn't create its own table.
So I have a mixture of composition and inheritance which work quite well.
Let's say there are two classes related to each other via some relations. For example, a Student maintains a list of the Classes he takes, and each Class has a list of Students taking it. Then I am afraid of letting the Student directly being able to modify its set of Classes, because each modification would have to be followed by a similar modification of a Class's list of Students, and vice versa.
One solution is to have a class whose sole purpose is to keep track of Class-Student relations, say Registrar. But then if some method in Student requires knowledge of its Class list, the Student needs to be passed the Registrar. This seems bad. It seems Student shouldn't have access to the Registrar, where it can also access other Students. I can think of a solution, creating a class that acts as a mediator between Student and Registrar, showing the Student only what it needs to know, but this seems possibly like overkill. Another solution is to remove from Student any method that needs to access its classes and put it instead in Registrar or some other class that has access to Registrar.
The reason I'm asking is that I'm working on a chess game in Java. I'm thinking about the Piece-Cell relations and the Piece-Player relations. If in the above example it wasn't OK for a Student to have access to the Registrar, is it OK here for a Piece to have access to the Board, since a Piece needs to look around anyway to decide if a move is valid?
What's the standard practice in such cases?
If relations can be changed - classes should be decoupled as much as possible, so along with each class create an interface, do not introduce tied relations between classes.
High level of separation you can achieve using intermediate services/helpers which encapsulates logic of communication between classes, so in this case you should not inject one class to an other even both are abstracted by interfaces, basically Student does not know anything about Class, and Class does not know anything about Student. I'm not sure whether such complexity is makes sense in your case but anyway you can achieve it.
Here is you may find a useful design pattern Mediator which can encapsulate interaction logic between two decoupled entities, take a look at it.
With the mediator pattern, communication between objects is
encapsulated with a mediator object. Objects no longer communicate
directly with each other, but instead communicate through the
mediator. This reduces the dependencies between communicating objects,
thereby lowering the coupling.
What I think you have found in your pretty nice example and explanation is that OO does not solve all problems well. As long as the responsibility is well shaped and sharp, everything is fine. And as long each responsibility fits in exactly one bucket (the class), it is pretty easy to design. But here you have a tradeoff:
If I define for each responsibility a separate class, I will get a bloated design that is pretty difficult to understand (and sometimes to maintain).
If I include for each separate responsibility at least one interface, I will get more classes and interfaces than I need.
If I decide that one of the two classes is responsible for the relation as well, this one object has more knowledge than usual about the other.
And if you introduce in each case a mediator or something similar, your design will be more complex than the problem.
So perhaps you should ask the questions:
What is the likelihood that the relation between the 2 objects will change?
What is the likelihood that the relation will exist between more 1 type of objects at each end?
Is that part of the system a highly visible part, so that a lot of other parts will interface it (and therefore will be dependent on it)?
Take the simplest solution that could possibly work and start with that. As long as the solution is kept simple, it is only your code (you don't design a library for others), there are chances that you can change the design later without hassle.
So in your concrete case,
the board field should have access to the whole board XOR
the figure on the field should have the responsibility of moving XOR
there should be an object type (ChessGame?) that is responsible for the overall knowledge about moving, blocking, attacking ...
I do think that all are valid, and it depends on your special "business case" which one is the most valid.