I am wrapping up an application where I am using a lot of Dictionary classes to store Function and Action delegates. I am now refactoring my project a bit and cleaning code. My question is where do or would you put your Dictionary classes in your project structure? Right now, they are located within the calling class source files but I was wondering if I should create a separate source file to store all my Dictionaries. I hope this is enough information. Please forgive me if it is not. Thanks.
I would organize the dictionaries in the same way as the rest of the code; group related functionality together, and separate unrelated functionality.
In addition, I'd look at how the delegation dictionaries are used. If your usage pattern is always to retrieve a delegate and immediately invoke it, then I'd wrap that behavior into a class with a "do-the-right-thing" method. Then each such class can be named by the domain concept it represents.
For example, if you had a dictionary which mapped US state abbreviations to a sales tax calculation, then you could wrap all of that into a class with a "compute sales tax" method taking a state code and subtotal as arguments. The fact that it's using a dictionary to look up the right computation scheme then becomes a hidden implementation detail.
Normally, the Dictionary class would be a thing unto itself (a library) and your various users would create instances of it.
If need be, they might specialize / sub-class it, but this should be rare.
Maybe the question you really should be asking yourself "why do I have multiple Dictionary classes"?
Related
So - I am really really digging coffeescript. But, I am curious how the possibility of repetition of code is dealth with across a large repository of code.
For instance.
Lets say I create a simple class.
class Cart
constructor: (#session, #group) ->
class Shoes extends Cart
compiler will create __extends and __hasProp methods.
Mind you, this is just one example -- pretty much this happens with loops etc... So, granted each bit of code is usually in its walled garden.. BUT, there could be many many of the same methods thru-out a code base.... because of the compiler just creating generic helper methods that are all the same.
Anyone else have to contend with this or deal with that possible bloat?
That is probably a lot more specific to what build tool you are using to manage a large codebase. grunt-contrib-coffee for example provides the ability to concatenate before compilation which means something like the __extends method should only get declared once. Likewise, I believe, asset pipeline in rails makes similar optimizations through the require statements.
I'm developing an app based on a TabBarController.
I have 2 views that do some similar actions.
My question is, should I make 2 different classes or should I use only one class with some "if" statements asking if is a class is one or the other. I need maximum performance on this.
The 2 views load a MKMapView, so I need to know if it is better to load just one object that does the entire thing, or two objects that do similar things.
Thanks!
In Object Orientation it's important to bear in mind the difference between a class and instances of that class.
If you ever find yourself thinking of writing some code in a class that says "What class am I? If I'm class X, do thing A; otherwise do thing B" -- don't! It's a classic problem begging for a nice object oriented solution. There are two common solutions in this kind of situation:
1) Write a single class that at instantiation time gets passed in some vital information that it then uses later. Then another part of your code is making instances of this class configured in the correct way -- e.g. in your problem, two instances of this class get made, each with a different bit of info (map location perhaps?) passed into the init method
2) Write a superclass that has two subclasses that specialise the general bahaviour of the superclass. So most of your logic and code goes in the superclass - suppose it's called MapDisplayViewController - but then you extend this class with two subclasses called (for example) MapDisplayViewControllerA and MapDisplayViewControllerB that override one or more methods in important, different ways to differentiate them.
For your problem it sounds like approach 1) would be good.
Having code which says "What class am I?" is often a good example of a 'code smell' -- in other words, a sign that something could be designed much better.
I would say load two objects. iOS will automatically unload your currently not displayed views if it needs more resources anyway. (Assuming you implemented viewDidLoad and viewDidUnload properly, of course).
In addition, if in case your view needs to initialize/load a lot of data when tab is switched, and the common flow involves the user switching from one tab to another frequently, the app may appear to lag during frequent loading, if you use only 1 object. No one likes long and frequent loading times.
Just my opinion though, based on the information your original post provides. A lot of additional factors can still come into play.
If I have a function (say messUp that does not need to access any private variables of a class (say room), should I write the function inside the class like room.messUp() or outside of it like messUp(room)? It seems the second version reads better to me.
There's a tradeoff involved here. Using a member function lets you:
Override the implementation in derived classes, so that messing up a kitchen could involve trashing the cupboards even if no cupboards are available in a generic room.
Decide that you need to access private variables later on, without having to refactor all the code that uses the function.
Make the function part of an interface, so that a piece of code may require that its argument be mess-up-able.
Using an external function lets you:
Make that function generic, so that you may apply it to rooms, warehouses and oil rigs equally (if they provide the member functions required for messing up).
Keep the class signature small, so that creating mock versions for unit testing (or different implementations) becomes easier.
Change the class implementation without having to examine the code for that function.
There's no real way to have your cake and eat it too, so you have to make choices. A common OO decision is to make everything a method (unless clearly idiotic) and sacrifice the three latter points, but that doesn't mean you should do it in all situations.
Any behaviour of a class of objects should be written as an instance method.
So room.messUp() is the OO way to do this.
Whether messUp has to access any private members of the class or not, is irrelevant, the fact that it's a behaviour of the room, suggests that it's an instance method, as would be cleanUp or paint, etc...
Ignoring which language, I think my first question is if messUp is related to any other functions. If you have a group of related functions, I would tend to stick them in a class.
If they don't access any class variables then you can make them static. This way, they can be called without needing to create an instance of the class.
Beyond that, I would look to the language. In some languages, every function must be a method of some class.
In the end, I don't think it makes a big difference. OOP is simply a way to help organize your application's data and logic. If you embrace it, then you would choose room.messUp() over messUp(room).
i base myself on "C++ Coding Standards: 101 Rules, Guidelines, And Best Practices" by Sutter and Alexandrescu, and also Bob Martin's SOLID. I agree with them on this point of course ;-).
If the message/function doesnt interract so much with your class, you should make it a standard ordinary function taking your class object as argument.
You should not polute your class with behaviours that are not intimately related to it.
This is to repect the Single Responsibility Principle: Your class should remain simple, aiming at the most precise goal.
However, if you think your message/function is intimately related to your object guts, then you should include it as a member function of your class.
We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because FooHelper indicates that it operates on Foo, but the behavior would most likely belong directly on the Foo class.
However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes FooHelper just as well as FooExtension. It's equally smelly (or not).
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
Application.Helper.SharePoint
Application.Helper.Authentication
and so on
In many cases, I use classes ending with Helper for static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.
The .NET Framework does this as well (for example in the LogicalTreeHelper class from WPF, which just has a few static (non-extension) methods).
Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.
I have an extremely hard time figurering out how classes needs to communicate with eachother. In a current project I am doing, many classes have become so deeprooted that I have begun to make Singletons and static fields to get around(from what I get this is a bad idea).
Its hard to express my problem and its like other programmers dont have this problem.
Here is a image of a part of the program:
Class diagram
ex1. When I create a Destination object it needs information from Infopanel. How to do that without making a static getter in InfoPanel?
ex2. DestinationRouting is used in everybranch. Do I really have to make it in starter and then pass it down in all the branches?
Not sure if this makes sense to anybody :)
Its a problem that is reacurring in every project.
After looking at your class diagram, I think you are applying a procedural mind set to an OO problem. Your singletons appear to contain all of the behavior which operate on the records in your domain model and the records have very little behavior.
In order to get a better understanding of your object model, I'd try and categorize the relationships (lines) in your class diagram as one of "is-a", "has-a", etc. so that you can better see what you have.
Destination needs some information from InfoPanel, but not likely all information. Is it possible to pass only the needed information to Destination instead of InfoPanel?
What state is being captured in the DestinationRouting class that forces it to be a singleton? Does that information belong elsewhere?
There's just too little information here. For example, I am not even sure if MapPanel and InfoPanel should be the way they are. I'd be tempted to give the decorator pattern a try for what it's worth. I don't know why a Listener is a child of a Panel either. We need to know what these objects are and what system this is.