Why does cocoa use delegates rather than inheritance?
With delegates, you can have one object be the delegate of many other objects. For example, you can have your MyController instance be the delegate of an NSTableView, an NSTextField, an NSWindow, and any other objects that compose your interface. This gives a compact place to put all of your user interface code related to one section of your UI.
If you'd done that with subclassing, you'd have to create one subclass every object you wanted callbacks from.
Also, this is a classic inheritance vs composition question
In general creating a subclass can be a time consuming process, requiring a lot of groundwork, and overriding various template methods.
Meanwhile, using a delegate allows you to create a simple object that answers a few specific question or reacts in various ways.
Now when you combine this with the dynamism that you can achieve by swapping out delegates on the fly it can create a very flexible robust system that promotes more code reuse.
There is some general discussions regarding these things here and here. You can also find some older SO questions here and here.
Discussed at length here:
http://www.cocoadev.com/index.pl?ExtendsIsEvil
And Java guys know this too:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Related
If we omit visibility modifiers(let's say all methods are public), is there any common convension to put new methods in class? I mean if I put them on bottom it's logically correct, because methods are sorted by date. If I put them on top, it's easy to see and compare what methods are added if the class is very long.
Just depends on what you and your team are comfortable with. I usually have method at the top of my class followed by fields. If there are many method that do different thing you are better off organizing them in a new class. Now without seeing any code I'm simply guessing.
No, I don't think there is.
As Kalagen said it's up to you and your team to decide it.
I would keep any methods that share similar functionality together and keep the class definition short.
The short answer in my opinion is no. Coding style might vary depending on the language you are using and the team you are working with. In addition you might have your own preference as well. I tend to add new methods close to methods that are related to it (e.g. if method1 calls method2 then method1 is above method2). Then it is relatively easy to find the method that's being called. On the other hand, most IDEs can find the method with a mouse click.
If you're using version control, you can easily see what methods were added and in which order, so sorting by date is not needed.
And as others have mentioned, keep the class small. Take a look at the Single responsibility principle. If the methods you are adding are not related to the responsibility of the class, extract them and create a new class.
I am currently working on implementing multiple events which share common properties and are basically the same: Templates. Our event provider applies several events like SomeTemplateAddedEvent and SomeOtherTemplateAddedEvent. There could possibly come more variations later, so I was thinking about implementing a base class for each TemplateAddedEvent since they all share common properties. But I am doubtful if this is the right way to go, since some people prefer events to be simple classes containing every property instead of having to dig deeper to find out what the event can provide.
I hope someone can shed some light on this subject.
Inheritance is normally used for two orthogonal reasons - to reuse functionality and to declare an "is-a" relationship between classes. It seems that you're using it for the first reason. This reason is a weaker argument because reuse can also be attained with composition. The question to ask then is whether there exists an "is-a" relationship between the events. Sometimes inheritance among events is desirable, such as when it makes sense to provide a handler for all events deriving from the base class.
Overall, I'd caution against inheritance if it is only applied to attain code reuse. If it is an appropriate statement about the domain, then it can make sense.
I have a custom class that exposes an NSString property. In Interface Builder I've bound the title of an NSButton to the property of my custom class.
Is it possible to get a reference to the NSButton instance from within my custom class?
Essentially I'm trying to locate all the user interface elements that are bound to the property in my custom class.
In general, this sounds like an anti-pattern and/or a bad idea. That said, there are a couple of things to bear in mind. Multiple observers could be bound to your property. You can override addObserver:forKeyPath:options:context: and removeObserver:forKeyPath: (and removeObserver:forKeyPath:context:) and then maintain your own array of observers. With that approach I would caution you that you may need to go to extra effort for the array to not retain observers, as traditionally KV observations don't retain the observing object, and you will likely run into leaks/heap growth if you start retaining them by putting them in an NSArray.
The other gotcha with overriding addObserver:... and removeObserver:... is that, without considerable extra work, you wont know if the observation is for a binding or for something else (like, say, a dependent keyPath notification). One possible workaround for that would be to interrogate the observer via infoForBinding: on all exposedBindings on a later runloop pass using performSelector:afterDelay:. (I think I just threw up in my mouth a little bit for suggesting this.)
Relying on private implementation details of the KVO system is not likely to be a good approach, unless your goal is simply to better understand how KVO works, but it sounds like you're actually trying to accomplish something.
Really, this whole approach just feels like a recipe for disaster. It sounds like an MVC violation from the get-go. Why would the model object need to know about the view objects? Whatever you're trying to accomplish here would almost certainly be better accomplished by having the nib be owned by an NSViewController subclass which has IBOutlets for all the UI elements, and properties for the model. That object would then be in a position to more cleanly manage the apparently complex relationship between your view and model objects without runtime trickery. Since you've not elaborated on the ultimate goal of this trickery, it's hard to say what the best approach would be.
I've looked through the other questions and am still struggling so if anybody could take the time to look at this, it would be much appreciated :).
I currently have my app working fine but I've been reading and have decided it doesn't fit the MVC design pattern. I am still learning lots about design and would like to edit it so that it is more sound.
I think I know what should go in to my model class, and I think that it should be instantiated in the app delegate. My questions are: why in that location? Is lazy instantiation the best/correct way to do this? And finally, once initiated, do I use a property to access the class or do you use special methods?
Sorry for the overload; I am also trying to get my reputation up enough to vote on other questions! :)
It's really hard to answer a general question like this, since there are so many ways one could implement any particular project. In general, I don't think that instantiating a model class in your app delegate is necessarily the way to go. Since a controller class mediates between the model and the view, it's often better to instantiate your model in a controller class -- for instance, I have a program that keeps track of the plants in my garden, and my controller class is a subclass of NSArrayController. It seems to make sense to create new plant objects in the controller and then just add them to its arrangedObjects. I try to have as few connections (via properties or ivars) between classes as I can, the thought being that each class should take care of its own business as much as possible. Often, you don't need to have a reference to the class, because you are calling class methods to create new objects, and then those objects can access any instance methods of that class without any explicit reference to the class.
If I need two modes in my application what design pattern would I use so I can prevent ugly conditional code? App is currently MVC, but I don't want conditional code in my controllers and don't want two controllers for each view unless I have to.
Any suggestions?
A different subclass for each implementation, with shared functionality either in a common superclass or using the Template Method pattern.
Perhaps the State Pattern?
Abstract Factory, or Proxy. Your controller would contain some kind of Factory or Proxy instance that is used to retrieve a "mode" and act on it accordingly.
It is difficult to say for sure without more information, but I would suggest the strategy pattern. You could use the same controller and just swap out the strategy object to produce the desired change in behavior.
Here is an article you may find useful:
http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html
take a look at JSR-168, java portlet and its reference implementation, it should be similar to what you are trying to achieve.
The appropriate place for such a decision is the controller of MVC. I would recommend you write it there first. If it really is repetitive, it may be straightforward to figure out how to clean it up: you can move the conditional logic into a base class, or depending on the language, may be able to handle it with some sort of filter. You may also be able to create some "factory" for the views, which understands the "mode" of your application. Architecturally, though, all this is in the controller.
You are right to not want it in the view. This would be pretty messy. You probably want two versions of the views, one for "view" and one for "edit".
In the end, this is what controllers are for. Good luck!
In CafeTownsend demo made with PureMVC there is a similar situation where there are two different views and two separate Mediators. You absolute don't need conditional code for that. I don't know what technology and programming language you are using, but in Flex it will be a ViewStack with the ListView and EditView as children:
Corresponding mediator is registered by demand when the view is created. You can check other implementations using previous link.