Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am wondering when I should subclass and I should include, let me explain you why :
I saw that whenever you include a class, you can access to it's methods, for example, if I create a new class that is a subclass of NSObject, I can still access to NSString and its methods just by including NSString.h
I also read that when you create a class that is a subclass of another class, you also access to it's methods.
So as a beginner to Objective-C, I just don't when should I use the first one and when should I use the second one ?
Subclassing is an object-oriented programming technique for creating a subtype of an existing type that inherits the supertype's behavior. #include is a compiler directive that substitutes the contents of the named file in its place. The two have very little to do with each other except that you have to include the file that declares a class in order to subclass it.
This question is kind of like "When should I build a doghouse and when should I use a hammer?"
Whenever there is a class that does what you want it to do, you can just use it. That's what you would do with NSString, for example.
When you need a new class that has nothing to do with any existing class, you subclass NSObject. Since NSObject is the subclass of everything in Objective-C, many people won't count that actually as "subclassing" but just as creating a new class.
When you need a class that is a modified version of an existing class, you subclass that class. However, Objective-C gives you some tools to avoid subclassing, and you shouldn't create a subclass unless you really have to. For example, you can add methods and even instance variables to existing classes without creating a subclass, and many classes are configurable through the use of delegate objects.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What I have been taught, and therefor restricted to, is to pass an object as a handler. I have used this approach in both my Java and Objective-C programming projects, and it works.
However, I stumbled upon a framework that registers a class as the handler, not an object. I wish that framework was open-source so I can see how that works, but it isn't :/.
Beware! After I register the class, I implement non-static methods to handle the events. If they were static, it would be obvious how this works, and I would really hate this approach.
So, these are my questions:
How does a class handler work and differ from normal object handlers?
When would you recommend one over the other?
Does this pattern have a name?
What I mean by object handlers:
Java:
button.addActionListener(handlerObject);
What I mean by class handlers:
Java:
object.addCrazyHandler(MyHandler.class);
Java (not sure about Objective-C) allows you through the Reflection API to do introspection on objects and their classes, hence the Object.getClass() method and all the methods on Class. Not only can you find all the constructors, methods, fields, implemented interfaces and superclass of a class, you can also call them (though it's slower than a direct call): newInstance() on constructors, invoke() on methods, get() or set() on fields. For example (exception handlers omitted), to call a no-argument constructor through Reflection:
Object o = SomeClass.class.getConstructor().newInstance();
Lots of frameworks use this: test frameworks such as TestNG or JUnit use it to instanciate the test classes, for example. So does Spring when you use XML configuration.
In your case, I suppose the framework wants to control the lifecycle of the handler, which it can't if you provide it with an instance. Another option would have been for it to take an instance of a factory, but that may be too restrictive. That can also mean more boiler-plate code to write, when it can easily create the object itself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Can anybody tell me when to use categories and when to use subclassing in Objective-C? Also please tell me the advantages and disadvantages of them.
An objective-c category is useful if you want to alter the behavior of ALL instances of the class, with minimal code. Subclassing is more useful if you want to alter the behavior of only certain instances, and retain the original method for others.
Categories can be dangerous, especially if you cannot view the source of the original method, so you should generally use subclasses on third-party and private frameworks rather than a category.
Category : It is used if we want to add any method on a given class whose source is not known. This is basically used when we want to alter the behaviour of any Class.
For example : If we want to add a method on NSString to reverse a string we can go for categories.
Subclassing : If we want to modify state as well as behaviour of any class or override any methods to alter the behaviour of the parent class then we go for subclassing.
For example : We subclass UIView to alter its state and behaviour in our iOS code.
Adding to what coneybeare said. Subclassing is a better option for customization, and Categories are better to be used when you just want to add some functionality to existing classes.
Do you want to change something which happens as part of framework
calls during the lifecycle of a UI object? Use Subclass. Override
respective methods, such as init, drawrect, layoutsubviews etc.
Do you want something application wide, something which is in
addition to the existing functionality, and you don't care if this
becomes available to all instances of this pre-existing instances of the framework class? Use categories. Example: animate UILabel upon certain user action, and apply this animation through out your app to all UILabel instances.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I want to find a good resource and/or book on this matter.
I am already really comfortable and efficient with creating apps with interface builder and see the value in using it in terms of all the visual feedback it provides in realtime / how good of a time saver it is.
So many questions like this were answered by people trying to persuade people to be ignorant of how to create an interface programmatically and to just use interface builder all the time.
I see the value in using IB but I feel that my knowledge of Cocoa is incomplete without knowing how to create an interface from both approaches.
Any help is gladly appreciated!
Thanks in advance!
Every setting in the Interface Builder has a corresponding property in the object. For example, compare the Interface Builder inspector for NSTextField/UITextField and the documentation of NSTextField/UITextField.
IBOutlet and the target/action mechanism are not special either: the former just uses Key-Valued Coding to set the outlet to an object, and the latter just uses setTarget: and setAction: of NSControl (or a similar method of UIControl on iOS.)
What the IB does is to precook these objects with the properties set as you specify in the inspector. When loaded, the data is fed to initWithCoder: of the class.
So, if you'd like to go IB-less just for fun, all you have to do is to alloc+init the UI object, and set all the properties by code. There's nothing more than that (except for special menu items on OS X which is somehow handled implicitly when MainMenu.nib is loaded, that is.)
There is an open source project called nib2objc which translates a nib/xib to a .m file with explicit Cocoa calls. That will help you understand what is going on.
On a bit more about nib files, read Apple's own documentation. The special magic at the loading of MainMenu.nib is described in this series of blog posts. But this is not really about how you would create UI without the nib in general; it's about how the special menu items are treated by the system.
In any case, internally speaking, there's almost no difference between loading a nib and writing UI codes programatically; both just create UI objects and set the UI properties appropriately. With IB, you set the properties beforehand and the precooked objects are read at the run time. If you do it in your code, the properties are set at run time. But once they are set, the resulting objects are exactly the same. So, there's really not much to learn.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Consider that I have a complex class structure where many elements inherit from other elements. I may have a method GetStuff(string stuffName, int count) defined in an interface, which is inherited by other interface, which is then implemented abstractly by an abstract class, which is then implement explicit in a concrete class etc. etc...
How should I handle inherited members such as GetStuff() when documenting my code with XML comments which will be used with a tool such as Doxygen or Sandcastle? It seems wrong to just copy and paste the same description at each level. Should I be considering a different audience at the interface level vs the concrete class level? For example the documentation for GetStuff() at the interface may consider people implementing the interface, whereas the documentation at the concrete level may instead consider people who will be using the class?
Document the interface method according to its code contract. Do not comment on its implementation, only on its semantic purpose, i.e. what it’s supposed to do, not how. The audience for this documentation is both your implementors and your users: the method will both be implemented as well as called.
Document the abstract method simply by saying that it implements the interface method and linking to it. There is nothing extra to be said about it, and duplicating the comment violates the DRY (Don’t Repeat Yourself) principle: you would have to remember to make any change to it in both places. (Of course, in the case of an abstract method that doesn’t implement an interface method, document it in the same way that you would document an interface method.)
Document the concrete implementation by saying that it implements the interface method and/or that it overrides the abstract member. Optionally add information about its implementation if it is relevant to the caller — for example, its performance characteristics, or situations in which it might throw, etc.
remark
on part of post
by Eric Anastas
It seems wrong to just copy and paste
the same description at each level.
I can imagine it being wrong to just copy. It is however possible to let doxygen copy it for you and then change what you would like to change for that implementation/scope.
For more information, you can look at the description for #copydoc.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
There are two classes:A and B.
And I need to implement a function whoViewed,
I have two options,make it an member function of A and B.Which smells a little duplicate.
Another choice is to make it a separate class:Viewer,but it's more abstract.
If you were me,which way will you choose?
To make it more general:
what will you do when you need to get statistic information across different classes(like get the latest viewed 10 entities{which can be A or B} from database) within the scope of OOP.
I would recommend not using inheritance and instead go with composition. Create a class called ViewMonitor which will handle the shared functionality. The odds are that there is no logical way to design an inheritance structure.
Obviously duplicating the whoViewed() method in 2 places is bad, so that option is off the table. You have a third option: Create a parent class that implements whoViewed() and have A and B inherit from it. The famous Gang of Four Design Patterns book recommends favoring composition over inheritance. So this would suggest making the Viewer class you mentioned in the question. Given the limited context provided in your question, I would suggest taking the GoF's advice and going with the Viewer class.
Incidentally, if you expect the implementation of whoViewed() to be different in A and B, you could make Viewer an interface and implement the interface in A and B.
if WhoViewed in A and B has the exact same functionality, make a class, from which they can inherit.
If the implementation of the method is different for both classes, of if they already inherit from another class, use an interface for A and B.
I would not suggest to introduce inheritance here, because it is serious decision, require that both classes to be truly polymorphic in all aspects.
In this case - make implementation in the third class, make this class a member of A and B, and then delegate call to the whoViewed method to this member.
In a pseudo code:
class C
{
WhoViewed();
}
Class A{
C m_C;
WhoVied{
m_c.WhoViwed();
}
In the B do the same as in A.
If speaking in OOD language - replace inheritance with delegation.
I would use composition and delegate to an external object. Your problem sounds like a cross cutting concern, hence AOP could be an option for you.
Depending on the language you could use Mixins (Ruby) or Traits (Scala).
This seems more like an AOP problem and should be solved using an aspect.
If you can think of the "who Viewed" as an aspect that you can then store the latest viewed 10 entities from database.
You would then intercept the calls to your entities and store the required metadata off in an easy to locate location.
if whoViewed() implementation is same for both then I would like to have a seperate helper class or an abstract class which is inherited by both A and B.
if whoviewed() implementation is ways apart write them in their respective classes.