A pretty short question - how is the message handling method named (the first method that is called on message passing), and in which class it is defined?
Sending a message to an object is handled by the VM, you won't find the specific method that handles it.
However, ContextPart>>#send:to:with:super: contains an implementation that should be identical to how the VM is implemented. In particular, it calls Behavior>>#lookupSelector:, where you can see the code that climbs up the inheritance hierarchy.
Related
Headline: description called by super.init()
This is a new take on an old question. As a primarily Swift programmer I tend to not use NSObject for class definitions because of the residual side effects of Objective-C. Like if I have a read-only property called length and I then want to create a setter function called setLength, I get warnings about it conflicting with a similar definition from Objective-C. I just discovered the set(var){} setter. If I subclass a Cacoa class like UIDocument, etc. that inherit from NSObject, I have to live with these side effects.
I have a class that uses two other classes in the property definitions, none of them NSObjects. This class has a description computed variable that uses the description computed variables for the other two classes in its composition. All three classes need to conform to the CustomStringConvertable protocol. Ok, everything is good.
At some point this class got upgraded to being a UIDocument and the CustomStringConvertable became redundant and was removed. Everything still works.
Here is what I found out today. I wanted to break at a point in the program where it was printing one of the two properties and as a convenience I set the break point in the description variable for that class, thinking that it should only be called at the point I am interested in, where it is printed out. What I discovered is that the description variable gets called during all the super.init() of the UIDocument sub-class! And there were a few of them. I think composing strings as being relatively expensive but didn't care because they were only used in debug, but with them being called and who knows how they are used in super.init(), I need to change this.
I checked another UIDocument class in the same program that has 200 files associated with it and it is also calling description in super.init().
Does anyone have any input on the Best Practices for using description vs debugDescription?
I'm going to answer my own question as a matter of documentation.
I switched the UIDocuments subclasses to define and use debugDescription. I am debugging some code that loads all the files and does some manipulation and I was able to reduce the load time from 9.8 seconds to 6.8 seconds.
I also went through all the places where the Swift 3 conversion added String(describing:) to the program and found I could change a lot of them to using debugDescription and eliminate the String(describing:) wrapper.
I think the best practice is to only define and use debugDescription and for my non-NSObjects change conformance from CustomStringConvertable to CustomDebugStringConvertable.
In c# we have the protected accessor which allows class members to be visible on inherited clases but not for the rest.
In Swift this doesn't exist so I wonder what's a correct approach for something like this:
I want to have a variable (internal behavior) and and a public method using this variable on a base class. This variable will be used also on inherited clases.
Options I see
Forget about base class and implement variable and methods everywhere I need it. WRONG, duplicated code
Implement inheritance by composition. I'd create a class containing common methods and this will be used by composition instead of inheritance. LESS WRONG but still repeating code that could be avoided with inheritance
Implement inheritance and make variable internal on base class. WRONG since exposes things without any justification except allowing visibility on inherited clases.
Implementation Details for Base Class
I want to have a NSOperationQueue instance and and a public method to cancel queued operations. I add new operations to this queue from inherited classes.
In Swift the correct answer is almost always protocols and extensions. It is almost never inheritance. Sometimes Cocoa stands in our way, because there are classes in Cocoa more often than protocols, but the goal is almost always protocols and extensions. Subclassing is our last choice.
Your particular case is confusing because NSOperationQueue already has a public method to cancel queued operations (cancelAllOperations). If you want to protect the queue from outside access (prevent callers from using addOperation directly for instance), then you should put the queue inside another type (i.e. composition), and forward what you want to the queue. More details on the specific problem you're solving would allow us to help suggest other Swift-like solutions.
If in the end you need something that looks like protected or friend, the correct solution is private. Put your subclass or your friend in the same file with the target, and mark the private thing private. Alternately, put the things that need to work together in a framework, and mark the attribute internal. The Swift Blog provides a good explanation of why this is an intentional choice.
I have been developing my skills at creating large object orientated programs (30+ classes).
I am trying to make my code as clean as possible after reading a fantastic book called clean code.
One problem I am having is to do with calling a method on an object from "across the program"
Say I have 5 classes.
`ClassA
ClassB
ClassC
ClassD
ClassE`
an instance of ClassA contains an instance of ClassB, which in turn contains an instance of classC, so
`ClassA > ClassB > ClassC`
I'm not saying that this is the inheritance chain, rather that in the constructor of classA an instance of ClassB is created and so on.
Now, say that ClassD > ClassE in a similar way. ClassD is instansiated with an instance variable containing an instance of ClassE.
This is all well and good, and the classes are small and only handle one job, and it all seems nice and clean.
However, say that at some point in the program I need the instance of classC to call a method on the instance of ClassE.
The two objects are on 'opposite sides of the program' so to speak. Yet the method call is necessary.
I am left with three options as I see it
make the instance of classE a global variable, so that classD AND classC can access it (as well as anything else in the program). I feel like this is bad form as global variables are generally considered bad news
Create the instance of ClassE at the top level, then pass it in as an argument to the constructors of ClassA, ClassB, and ClassC. The trouble with this is that I would end up with really long constructor argument lists if this is happening more than once, and it seems like lots of work to pass ojects down chains of constructors like this
Move the object of ClassE to be instantiated by ClassC. The trouble with that is that its more strongly coupled with ClassD and only needs to be called once in the entire running of the program by ClassC.
So what do I do in situations such as these? And are there any resources I can read about this. I know that I could use the observer pattern for situations similar to this, but when its just for one method call it seems excessive, as I would be making things observable all over the program. I want my code as clean as possible!
Thanks in advance :)
Three words: Single Responsibility Principle. If you worry that your class has too many constructor arguments it's probably because this class needs to deal with too many different things. If you keep classes focused, they will be small.
You correctly indicate the coupling problem in the third solution you've described. The coupling problem is also present in the first solution (depending on a global variable is even harder to find/diagnose later). So the second option seems to be the best - as long as you refactor the code to keep your classes simple.
You could read up on Law of Demeter (Short explanation on wikipedia: http://en.wikipedia.org/wiki/Law_of_Demeter or a longer but very well written example http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf)
Depending on the context / content of your example you could for instance: Build your Class D as a wrapper to your class E (or similar facade / adapter). Meaning if your class c sometimes needs to talk to an E instance it does so via it's class D instance.
Another way to go would be to provide a reference to a class E instance to those objects that need one.
If all your objects are talking to the same instance of E you could also think about the singleton pattern where there is only one instance of a class. But this instance is more or less globally available.
Give a bit more context info and we can develop this further.
EDIT: btw. a funny explanation of lad of demeter can be found here:
http://www.daedtech.com/visualization-mnemonics-for-software-principles
EDIT Nr.2 (your comment): ad. 1.) Maybe you can implement your class D in a way that reliefs your other classes of ever talking directly to an E object. Instead they ask their D instance to do something (not knowing that D delegates the call to E). Depending on what you are trying to do this might be an option for you.
ad. Singleton.) Yes and No. The Singleton main use is that it guarantees (if implemented correctly) that only one instance of the singleton object exists. If you are talking about config settings this might not be a requirement. You are right however that basically the thing is kind of a global variable with all it's downsides. Your object D sounds as if it's immutable in a sense that it does not change it's state while your program is running so maybe the problem is not that you create a complex dynamic behaviour but that you create too many dependencies.
Just another link/principle to get you thinking:
What is Inversion of Control?
I am working with socket programming.I just wanted to clear a doubt related with a code i downloaded from -mobileorchard.com - Chatty. While R&D , I saw a function call in ChatRoomViewController.m file
[chatRoom broadcastChatMessage:input.text fromUser:[AppConfig getInstance].name];
when I saw in Room.m file, for the implementation of above call; it was
- (void)broadcastChatMessage:(NSString*)message fromUser:(NSString*)name
{
// Crude way to emulate an "abstract" class
[self doesNotRecognizeSelector:_cmd];
}
i googled for "doesNotRecognizeSelector:" , according to Apple its for error handling, stating "The runtime system invokes this method whenever an object receives an aSelector message it can’t respond to or forward." my question is why does the developer call the broadcastChatMessage:fromUser: function if its none of use there and to handle which method's "selector not found" exception ?
According to Stackovrflow, its used to create abstract class , according to this Question, its to avoid "Incomplete implementation" warning.
I am still not getting why that method is used in that Chatty Code, Kindly help me to understand the reason why that method is used.
This is the method that exists on every NSObject derived object that triggers the path to an exception when a method isn't recognized in a runtime call. For example, if you try to send a message to an NSString called -foo, it'll end up there since that's not a valid method on NSString.
In this case, the Chatty class Room is a base class that is never used directly. LocalRoom and RemoteRoom derive from it, and both of those classes provide an overriding implementation of -broadcastChatMessage:fromUser. Nobody ever calls that base class version, but for "completeness" the programmer has guaranteed that a subclasser must override this by implementing the method, but then turning around and calling this to trigger an exception.
Thing is, this isn't specifically idiomatic Objective-C. An "abstract" class is a concept from C++ and other languages; it's base class that exists only as a "pattern" from which to subclass. (In ObjC, this is often done by creating a formal #protocol when there isn't meaningful state, as there (mostly) isn't here).
Note that the call to -doesNotRecognizeSelector: is arbitrary. It's not necessary to avoid compiler warnings here (since the method is in fact implemented) and the original writer could have easily just thrown an exception directly, or done nothing instead.
It seems to me that you already answered your own question. There is no method to make abstract classes in Objective-C, so the closest thing to do it to have the methods that you need to override throw exceptions. If you override this method in a subclass, then doesNotRecognizeSelector: will no longer be called. Basically it is a way to get a developer to promise to implement this method in their subclass.
Also, as you mentioned, if you don't put this in then the compiler will issue a warning because no implementation exists for a method defined in the header. This will perform the same behavior as not implementing it, but the compiler will realize that you are doing it on purpose.
What are the different between calling to a function by delegate or by creating an instance and calling tomethod:
for example, I can use the next method
ViewC1.m
-(void) doSomthing{
}
viewC2.m
viewC1 *myInterface = [[viewC1 alloc] init];
[myInterface doSomthing];
or creating delegate with protocol... and use it like this:
viewC2.m
[self.delegate doSomthing];
It's primarily a question of the design pattern that you're trying to achieve. Delegation allows you to create less explicit linkages between classes. From Apple's The Objective-C Programming Language:
"Protocols free method declarations from dependency on the class
hierarchy, so they can be used in ways that classes and categories
cannot. Protocols list methods that are (or may be) implemented
somewhere, but the identity of the class that implements them is not
of interest."
So, to answer your question, there's no difference on an outcome basis, so long as self.delegate exists and implements doSomthing and viewC1 instances implement doSomthing. But without knowing the broader context, it's hard to say much more about the relative advantages. I'd read up on Objective-C protocols and about the delegate pattern as heavily used in the Cocoa frameworks to get a better feel for when to use this pattern. Follow Apple's lead in this case.
(By the way, in Objective-C, it's "methods" instead of "functions"...)
Assume there are two class ViewC1 and ViewC2. If you want to send message from ViewC1 to ViewC2 and receive the callback message from ViewC2 to ViewC1. It is better using protocol for this objects communication. If you using instance method for this objects communication, you will restricted ViewC2 to callback on specified object (In this case ViewC1). In order to let ViewC2 able to callback any objects. You can define the protocol on ViewC2. And let other object which want to receive the callback to conform it.