MSDN documentation for classes contain many inherited properties and methods. I think this is clutter and greatly reduces the usability.
For example, take look here, at the BitmapSource class. You can't really see what's special about this class. Everying is inherited, inherited, inherited.
It think that if something is inherited then it should be doucmented at the BASE class. So if a Mamnal BreastFeeds and a Dog Barks, I would go to the documenation of Mammal for breast feeding (anyhow, to read about it :), and for that of Dog for barking. Of course, if something is over-ridden, it should also appear at the derived class's documentation such as in BitmapSource.Height.
So: Is there a way to view MSDN documentation hiding the inherited clutter? Some variation on the Url, a switch, offline help, a utility?
OK, found the solution: Visual Studio's Object Browser. SO much more understandable!
Related
I'm coming from AS3 to Obj-C, and classes are confusing me. I want to create a ball class as a test, with colour, radius etc. Looking through other people's code I've discovered they use structs to implement them, and this seems like a much nicer method. I've searched but am unable to find a really clear explanation of what structs are, and how to implement them.
In terms of my ball class, to implement it I'd want to use something like Ball *myBall = [Ball radius:(14), mass:(1)]; etc. This seems like a nice clean way to do it. Can anyone suggest some further reading on this?
Thanks.
Read Apple's own Objective-C Primer. It's worth reading. The documents linked there are also useful. You know, vendors (in this case Apple) often have a nice set of documentations because they need to sell their technology...
For a comparison of ActionScript and Objective-C, see this series of blog posts for example.
Using classes straight of the bat would be a better idea as once you start developing you'll probably want to extend the functionality like object orientated methods (what classes are for).
Creating a class for ball with an appropriate constructor and properties would fit your needs.
I recommend starting here.
I had a bunch of objects which were responsible for their own construction (get properties from network message, then build). By construction I mean setting frame sizes, colours, that sort of thing, not literal object construction.
The code got really bloated and messy when I started adding conditions to control the building algorithm, so I decided to separate the algorithm to into a "Builder" class, which essentially gets the properties of the object, works out what needs to be done and then applies the changes to the object.
The advantage to having the builder algorithm separate is that I can wrap/decorate it, or override it completely. The object itself doesn't need to worry about how it is built, it just creates a builder and 'decorates' the builder with extra the functionality that it needs to get the job done.
I am quite happy with this approach except for one thing... Because my Builder does not inherit from the object itself (object is large and I want run-time customisation), I have to expose a lot of internal properties of the object.
It's like employing a builder to rebuild your house. He isn't a house himself but he needs access to the internal details, he can't do anything by looking through the windows. I don't want to open my house up to everyone, just the builder.
I know objects are supposed to look after themselves, and in an ideal world my object (house) would build itself, but I am refactoring the build portion of this object only, and I need a way to apply building algorithms dynamically, and I hate opening up my objects with getters and setters just for the sake of the Builder.
I should mention I'm working in Obj-C++ so lack friend classes or internal classes. If the explanation was too abstract I'd be happy to clarify with something a little more concrete. Mostly just looking for ideas or advice about what to do in this kind of situation.
Cheers folks,
Sam
EDIT: is it a good approach to declare a
interface House(StuffTheBuilderNeedsAccessTo)
category inside Builder.h ? That way I suppose I could declare the properties the builder needs and put synthesizers inside House.mm. Nobody would have access to the properties unless they included the Builder header....
That's all I can think of!
I would suggest using Factory pattern to build the object.
You can search for "Factory" on SO and you'll a get a no. of questions related to it.
Also see the Builder pattern.
You might want to consider using a delegate. Add a delegate method (and a protocol for the supported methods) to your class. The objects of the Builder class can be used as delegates.
The delegate can implement methods like calculateFrameSize (which returns a frame size) etc. The returned value of the delegate can be stored as an ivar. This way the implementation details of your class remain hidden. You are just outsourcing part the logic.
There is in fact a design pattern called, suitable enough, Builder which does tries to solve the problem with creating different configurations for a certain class. Check that out. Maybe it can give you some ideas?
But the underlying problem is still there; the builder needs to have access to the properties of the object it is building.
I don't know Obj-C++, so I don't know if this is possible, but this sounds like a problem for Categories. Expose only the necessary methods to your house in the declaration of the house itself, create a category that contains all the private methods you want to keep hidden.
What about the other way around, using multiple inheritance, so your class is also a Builder? That would mean that the bulk of the algorithms could be in the base class, and be extended to fit the neads of you specific House. It is not very beautiful, but it should let you abstract most of the functionality.
Is there any way to discover at runtime which subclasses exist of a given class?
Edit: From the answers so far I think I need to clarify a bit more what I am trying to do. I am aware that this is not a common practice in Cocoa, and that it may come with some caveats.
I am writing a parser using the dynamic creation pattern. (See the book Cocoa Design Patterns by Buck and Yacktman, chapter 5.) Basically, the parser instance processes a stack, and instantiates objects that know how to perform certain calculations.
If I can get all the subclasses of the MYCommand class, I can, for example, provide the user with a list of available commands. Also, in the example from chapter 5, the parser has an substitution dictionary so operators like +, -, * and / can be used. (They are mapped to MYAddCommand, etc.) To me it seemed this information belonged in the MyCommand subclass, not the parser instance as it kinda defeats the idea of dynamic creation.
Not directly, no. You can however get a list of all classes registered with the runtime as well as query those classes for their direct superclass. Keep in mind that this doesn't allow you to find all ancestors for the class up the inheritance tree, just the immediate superclass.
You can use objc_getClassList() to get the list of Class objects registered with the runtime. Then you can loop over that array and call [NSObject superclass] on those Class objects to get their superclass' Class object. If for some reason your classes do not use NSObject as their root class, you can use class_getSuperclass() instead.
I should mention as well that you might be thinking about your application's design incorrectly if you feel it is necessary to do this kind of discovery. Most likely there is another, more conventional way to do what you are trying to accomplish that doesn't involve introspecting on the Objective-C runtime.
Rather than try to automatically register all the subclasses of MYCommand, why not split the problem in two?
First, provide API for registering a class, something like +[MYCommand registerClass:].
Then, create code in MYCommand that means any subclasses will automatically register themselves. Something like:
#implementation MYCommand
+ (void)load
{
[MYCommand registerClass:self];
}
#end
Marc and bbum hit it on the money. This is usually not a good idea.
However, we have code on our CocoaHeads wiki that does this: http://cocoaheads.byu.edu/wiki/getting-all-subclasses
Another approach was just published by Matt Gallagher on his blog.
There's code in my runtime browser project here that includes a -subclassNamesForClass: method. See the RuntimeReporter.[hm] files.
As you may have guessed from the question - I am right at the beginning of the Obj-C journey.
I'm hoping that someone out there knows of some diagrams that depict the relationship between classes, objects and methods - and that they're willing to share.
The problem I'm having is that just looking at code in a textbook doesn't completely explain it - for me at least.
Thanks for reading!
Regards,
Spencer.
No diagrams, but this is the tutorial I wish I'd read before I started:
http://www.cocoadevcentral.com/d/learn_objectivec/
Simple English, all the basic concepts.
Classes are just like classes in any language. They are descriptions.
Objects are like nouns. They are an instance of a class. That is, if you had a description of a generic book (the class) and you made a thesaurus based on that description, the thesaurus would be the object.
Methods are more or less functions. If the objects are nouns, then the messages are verbs.
[ScienceBook getTableOfContents]; //this would like return a table of contents.
Here, the object ScienceBook is being sent a getTableOfContents message (method). So now, the science book would theoretically find, format and return the table of contents to whom ever sent the message.
To some extent, diagrams may not be that helpful to answer the questions you present.
It may help to think of things like this:
A "class" provides the prototype or definition for some thing. For example, a "Person" or a "Car". A common synonym for "class" is "type".
An "object" is a concrete example or instance of a class. For example, you are an instance of "Person", and your car is an instance of "Car".
A "method" is a behavior, action or property of a class. However, a method is normally only meaningful in the context of an object. "Person" -> "Eat" is not meaningful, but "you" -> "Eat" is.
These are fundamental Object-Oriented concepts that are not specific to Objective-C. If you are interested in a general overview that is language-agnostic, I recommend "Object Thinking" by David West. Even though it's from Microsoft Press, it covers the concepts rather than any specific language.
I come from a fairly strong C++ background, but I can definitely remember when I started, I had a hard time grasping at the concept until I found a way to associate it with physical objects.
The word class and object you can use almost interchangeably. Think of an object as a container, like a bucket. The word bucket would be your "class". It is the name you give to the type of object you have.
A bucket has a certain purpose...to carry something. It might be water...or perhaps sand. So perhaps you want to fill the bucket. This would be something you do to the bucket, so in objective-c, this would be your method. You might write something like:
- (void) fillWith:(elementType)something;
So in this case, "something" might be something that represents and object you wish to fill your bucket with.
Your class might look like the following:
typedef enum items {
CRAYONS,
MARKERS,
SAND,
WATER } elementType;
#class Bucket {
elementType item;
}
- (void) fillWith:(elementType)something;
#end
Here's one link to some objective-c samples. Also try the apple development center.
If you're after information on Object Orientated Programming (ie the meaning of classes, objects, methods etc) then I'd advise against Objective-C. Objective-C on the Mac relies heavily on the Cocoa framework. The Cocoa framework is vast and performs a lot of 'magic' which will make it harder to understand the fundamentals of OOP.
An easier place to start would be a language used for web development. It's easier to get to the nuts and bolts of OOP with these languages.
Apologies for the recursive nature of this question but the chosen answer to a question on SO got me questioning my understanding of reflection.
I thought reflection was mainly about querying the internal happenings of a program while it's running. The example given in this response patches Ruby's built-in Integer class.
Isn't this more like function overloading/inheritance rather than runtime modification?
Is class reopening really an example of reflection?
Reflection can be used to implement late binding.
Late binding can be used to implement monkey patching.
Monkey patching can be used to achieve the sort of coding style shown in that answer.
But there are other ways to implement such features that don't require monkey patching, or reflection. Heck, a good macro pre-compiler could get you close.
So, technically correct, but not (IMHO) the greatest example.
At the risk of increasing the level of recursion, I would like to respond although you are referencing my answer at that link.
The misunderstanding is an easy one to make because of our intuitive understanding of reflection as referring to looking inwards. And that's certainly an important aspect of reflection in programming also - in Ruby, for example, we have methods like instance_of to allow objects to ask questions about themselves at runtime.
But take a look at the wikipedia definition of reflection:
reflection is the process by which a
computer program can observe and
modify its own structure and
behaviour.
As you can see, reflection is more than just runtime self-inspection. It's also the ability to change runtime behavior. Reopening a class is also referred to as "monkey patching". You can read more about it here.
A monkey patch is a way to
extend or modify the runtime code of
dynamic languages without altering
the original source code.
This process is also referred to as:
- Guerrilla patching
- Extending previously declared classes
- Reopening classes
- Dynamic Funk
- Hijacking
- Duck Punching
- Method Swizzling