Having worked w/ languages that utilized namespaces for the past 10 years I am trying to figure out the best approach to project structure and class names in objective-c (iOS4+). Should you simply give all your classes, view controllers, etc. unique names? It seems archaic there is not a way to encapsulate groups of functionality with something like namespaces, especially if you build libraries and have a large development team.
Is there functionality equivalent to namespaces that I am missing? If not, what is a good approach to this problem?
Thanks
Should you simply give all your classes, view controllers, etc. unique names?
Yes.
The standard approach is to prefix class names with a short code. For instance, traditional Cocoa uses NS (from NextStep), while Cocoa Touch uses UI (for user interface, I guess).
Related
I have created categories of NSBezierPath, functions that deals with geometric objects, and classes that use aforementioned code.
What is the most natural way to use include them in new projects? I'm using them in almost all of my projects.
Make a framework of it and use the framework in your project.
This is the most sensible option, IMO, if those classes provide a coherent set of features. Otherwise, you could create a set of frameworks; in this case, though, beware of dependencies among them, because it would make managing them more complex and maybe the effort of it would not give any advantage.
If you really want to go 'pro' you might think of creating your own Xcode template to include those frameworks by default in your projects. Have a look at this post about making Xcode templates.
1) iPhone development - when to create a class library and when not to? (is there a best practise guide to explain this?)
2) Do you need to take a different approach when you decide to create a class library vs developing a web app or desktop app. Since iPhone app has many views is it better to duplicate functions from one view to another rather than create function libraries for reusable functions? (ie web service functions, should this be duplicated?)
3) Traditionally in a web application, desktop application, when you need to reuse a function more than 2 times, you might consider creating a library, but not all the time it really depends on the situation, is this still true for iPhone development?
A good rule of thumb is to ask yourself: will I use this in another project?
In my opinion, reusing functionality within different views in the same application is not enough of a good case for creating a library.
It's important to notice the differente in reuse between different apps (in which case it's good to create a library) and reuse inside the project (you solve it with good OO design)
You could check this link for a list of open-source iPhone libraries. You'll get an idea on what a library should consist of.
We create a class library when it is useful. Not all classes make sense in a library, and not all libraries need to be created for a particular purpose. General rule (for me) goes something like: If you've had to rip something out of another thing because it was useful, to put it in another thing, odds are good you want to, during the code removal from the first thing, make it reusable.
It may be a good idea, it's again, hard to answer this particular point in the abstract.
That's true for many classes of problem domains, including iPhone development.
Can someone explain to me what interface bloat in OOP is (preferably with an example).
G'day,
Assuming you mean API and not GUI, for me I/F bloat can happen in several ways.
An API just keeps getting extended and extended with new functions without any form of segregation so you finish up with a monolithic header file that becomes hard to use.
The functions declared in an existing API keep getting new parameters added to their signatures so you have to keep upgrading and your existing applications are not backwards compatible.
Functions in an existing API keep getting overloaded with very similar variants which can lead to difficulty selecting the relevant function to be used.
To help with this you can:
Separate out the API into a series of headers and libraries so you can more easily control what parts you actually need. Any internal dependencies should be resolved automatically by the vendor so the user doesn't have to find out the dependencies by trial and error, e.g. that I need to include header file wibble.h when I only wanted to use the functions in the API declared in the shozbot.h header file.
Make upgrades to the API backwards compatible by introducing overloading where applicable. But you should group the overloaded functions into categpories, e.g. if new set of overloaded functions are added to an existing API, say our_api.h, to adapt it to a new technology, say SOA, then they are provided separately in their own header file our_api_soa.h in addition to the existing header our_api.h.
HTH
Think of an OO language where all methods are defined in Object, even though they are only meaningful for some subclasses. That would be the most extreme example.
Most Microsoft products?
Interface bloat is having too much on the screen at once, particularly elements that are little used, or are confusing in their function. Probably an easier way to describe interface bloat is to look at something that does not have it, try Basecamp from 37signals. There are only a few tabs, and a few links in the header.
Interface bloat can be remedied by collapsable panes (using Javascript, for example), or drill-down menus that hide less-often used choices until they are needed.
Interface bloat is the gradual addition of elements that turn what may been a simple, elegant interface into one littered with buttons, menus, options, etc. all over the place that ruin the original cohesive feel of the application. One example that comes to mind for me is iTunes. In it's early renditions, it was quite simple, but has, over time, added quite a lot of features that might qualify as bloat (iTunes DJ, Coverflow, Genius).
Interface bloat is sometimes caused by trying to have every feature one click away, as in this humorous example:
Too many toolbar buttons
(Although funny, this example isn't fair to Firefox because in this example the user added all those toolbars)
A UI design technique called "progressive disclosure" is one way to reduce interface bloat. Only expose the most frequently-used features as a top-level click. If you have less-frequently-used features that are still valuable enough to include in your app, group them in a logical way, e.g. behind a dropdown menu or other navigation element.
Learning by example:
http://img46.imageshack.us/img46/5127/ofilematrix.png
An extreme example of interface bloat that most C++ programmers will be familiar with is std::basic_string. Page up and page down of member functions with only small variations, most of these functions wouldn't have had to be member functions but could have been free functions in a string utility library.
Objective-C doesn't have namespaces, and many (such as CocoaDevCentral's Cocoa Style Guide) recommend prefixing your class names with initials to avoid namespace collision.
Quoting from the above link:
Objective-C doesn't have namespaces,
so prefix your class names with
initials. This avoids "namespace
collision," which is a situation where
two pieces of code have the same name
but do different things.
That makes sense, I suppose. But honestly, in the context of a relatively small app (say, an iPhone game), is this really an issue? Should I really rename MyViewController to ZPViewController? If not, at what point do namespace collisions really become a concern?
If you're writing an application that uses some set of libraries, then you already know what your namespace looks like and you just need to select names that do not conflict with existing available functions.
However, if you are writing a library for use by others, then you should pick a reasonably unique prefix to try to avoid name collisions with other libraries. With only two characters there may still be name collisions, but the frequency will be reduced.
Small apps shouldn't use up all the good names, so won't have a problem with namespaces.
But it is a good idea to get used to the style that languages are generally written in. It makes it easier to read other people's code, and for others to read yours.
E. g., use camelCase variables in Java, but CamelCase vars in C#, hyphen_separated_names in C, etc.
It will make it easier for you to learn in the long run.
I have read (but haven't verified) that Apple has private classes in their frameworks that don't include any prefixes on the names. So if your application classes' names have no prefixes, you risk colliding with those.
I've worked with repositories where classes were not prefixed. (Or only some of the classes were prefixed.)
One thing that I found painful is it's sometimes hard to tell if code was written by someone inside or outside the company. Using a consistent prefix makes it immediately obvious for someone reading the code for the first time.
Keep in mind that code will be read many more times than written.
Also, it can definitely come in handy when using tools like grep and sed.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. What is "My" used for?
The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)
Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.
This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace
As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.
I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.
I use primarily these categories:
My.Computer: primarily for file system and network purposes
My.Application: Version number, current directory
My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
My.Settings: very handy
I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.
I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)
That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.
We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).
But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.
I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.
It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.
And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.
I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.
I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.
As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.
Never used it so far, although I've never actually looked into it either.
I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.
Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!
I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.
I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.
I don't use it a lot.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?
If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.