It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm reading "Programming in Objective C" by Stephen G. Kochan, and in chapter 11 he mixed with a bit about: categories, protocols, delegation, informal protocols.
Now, he just talked a bit about everyone of them and it got me more confused...I know that delegation is one of the most important subjects in obj c and that it goes along with protocols.
Please help, it's important for me so I will not mess it up.
tnx
I'll try and explain delegation for you. It's really simple when you do know, but it takes time to get your head around it!
Let's say you have two classes, a Calculator class that performs calculations and a CalculatorScreen class that is used to present the result of a calculation to a user. The Calculator class should tell the CalculatorScreen when it has finished performing a calculation so the latter can update the UI.
A protocol provides a way to define a set of methods that are somehow related with a specified name. You could have a number of methods defined in a protocol called CalculatorDelegate in the Calculator class, but the method implementations are defined elsewhere.
The class that defines the protocol (in this case Calculator) can tell a delegate (an object that conforms to the protocol - in this case CalculatorScreen) to implement the method. The calculator class might finish an addition calculation and tell its delegate (the screen) to update. You get me?
Sorry, as I was writing I realized it is hard to explain and sympathized with every author that has tried!
iOS Example:
When you set up a table on the iPad's display, you use the UITableView class. But that class doesn't know what the title of the table is, or how many sections and rows it is to have, or what to fill it with. So it delegates that responsibility to you by defining protocols called UITableViewDataSource and UITableViewDelegate. When the UITableView needs to know some information, for example, number of rows, it calls the appropriate method on the delegate (your own class), the delegate class contains the implementation of those methods defined in the protocol.
In answer to your question, I'd drop the book for a bit and start coding what you have learned so far in a dummy app! The best way to learn is to do (for me at least).
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
So ive been looking at several videos, read some information on the internet about this design pattern but just to make things clear is it correct that this pattern is:
an Object (Subject) that has its own implementation of the Iterator interface
And nothing else? no fancy stuff like the observer pattern or decorator pattern or anything like that? It is simply just an implementation of an already known interface?!
Short Answer
Yes, implementing the interface is all there is to it.
Long Answer
Saying "only implementing an interface" is like having an idea for a movie and then "only creating the movie".
Your interface is nothing more than a spec; it doesn't do any work, it just defines a signature. The vast majority of your work is done when you implement the interface -- ie: WRITE the code.
Please don't let the words "implement an interface" fool you. It can be simple, or intractably complex.
To give you an idea, take this example. I have an interface for a class that can take your height and weight and from that alone predict the name of your future wife. It's amazing, isn't it? Here's the interface:
class IPredictor {
public abstract void setWeight(double weight);
public abstract void setHeight(double height);
public abstract string getNameOfFutureWife();
};
Now to make this work, you ONLY need to implement the interface. Please let me know when you have it done; I'd like to know the name of the future Mrs. Barzell :D
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am very confused about the concepts of polymorphism ,overloading and overriding because it seems same to me. Please explain these concepts, and how are they different from each other
Very confused so please guide me properly.
Thanks
Polymorphism can be achieved through overriding. Put in short words, polymorphism refers to the ability of an object to provide different behaviors (use different implementations) depending on its own nature. Specifically, depending on its position in the class hierarchy.
Method Overriding is when a method defined in a superclass or interface is re-defined by one of its subclasses, thus modifying/replacing the behavior the superclass provides. The decision to call an implementation or another is dynamically taken at runtime, depending on the object the operation is called from. Notice the signature of the method remains the same when overriding.
Method Overloading is unrelated to polymorphism. It refers to defining different forms of a method (usually by receiving different parameter number or types). It can be seen as static polymorphism. The decision to call an implementation or another is taken at coding time. Notice in this case the signature of the method must change.
Operator overloading is a different concept, related to polymorphism, which refers to the ability of a certain language-dependant operator to behave differently based on the type of its operands (for instance, + could mean concatenation with Strings and addition with numeric operands).
The example in Wikipedia is quite illustrative.
The following related questions might be also useful:
Polymorphism vs Overriding vs Overloading
Polymorphism - Define In Just Two Sentences
Shortly, no they are not the same.
Overloading means creating methods with same name but different parameters.
Overriding means re-defining body of a method of superclass in a subclass to change behavior of a method.
Polymorphism is a wide concept which includes overriding and overloading and much more in it's scope. Wikipedia's description of polymorphism can help you understand the polymorphism better. Especially the Subtype polymorphism (or inclusion polymorphism) section is where you should look.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How does a delegate work in objective-C?
Hello Community,
I have been trying to understand the concept of delegates in Objective-C. I tried following up the documentation, however I am looking for some really easy example to get familiarized as of how to send messages between delegates and if I want to create a custom delegate, how may I go further with that?
Hope someone could make me better understand this concept.
The basic concept of delegates is to delegate important decisions or information to some other object instance.
In most frameworks you use subclassing and override methods in order to hook into the application flow. It works but the drawbacks are many, for example:
You can not change the decision maker without a complete new subclass.
Without multiple inheritance you can only make decisions for one object (yourself).
There are four reasons why an object might want to call upon a delegate, and each of these four uses a keyword in the delegate method name to signal this. It's a naming convention only, but you should follow the pattern if you want to be a good citizen.
Ask if something should happen. For example: gestureRecognizer:shouldReceiveTouch:
Before something unavoidable is going to happen. For example: applicationWillTerminate:.
After something has occured. For example: accelerometer:didAccelerate:
And to retrieve data, this is more a data source than a delegate, but the line between the two are fuzzy. The name do not contain a defined name, but should contain the named piece of data that is requested. For example: tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath:
As a general rule the first argument to any delegate method should be the named object instance requesting delegation.
Check here:How do I create delegates in Objective-C?
Or: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html#//apple_ref/doc/uid/TP40002974-CH7-SW18
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
can u explain me what is the difference between aggregation, containment & delegation
Since you've tagged this with COM, I'll assume you're asking how COM uses these terms - in COM terminology they mean something somewhat more specific than when used in general.
Conveniently, MSDN has pages that define these - I'll give a brief summary:
Containment/Delegation - when one outer object owns (contains) and makes use of (delegates to) an inner object. The two objects maintain distinct identities and separate sets of interfaces.
Aggregation - when two or more COM objects essentially pool their interfaces and behave as though they are a single COM object. The client code is then dealing with what appears to be a single object, but is in fact an 'aggregate' of other objects.
Aggregation is usually used when you want one object to 'inherit' a set of interfaces from another object. It's somewhat complex to implement, however: COM requires that from any interface on an object you must be able to QI to any other interface, so the various objects involved have to cooperate to ensure that you can QI from any interface on one of the objects to any interface on the other, an have ref counting work across both objects.
Containment describes the idea of one class, having a data member that is an object of another class/type.
Delegation expresses the idea that one class uses another class to accomplish a task or goal.
Delegation is usually accomplished by containment
Aggregation and Containment are generic concepts (concepts above com or any other technology) of Object Composition. The Object Composition link, has a separate section on Aggregation in com also.
Similarly, you can read about delegation.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I am trying to understand the core of object oriented programming for php or actionscript proect. As far as I understand, we will have a Main class that control different elements of the project. For example, photoslider class, music control class..etc. I created instance of those classes inside my Main class and use their method or property to control those objects.
I have studied many OOP articles but most of them only talks about inheritance, encapsulation...etc I am not sure if I am right about this and I would appreciate if someone can explain more about it. Thanks!
Same question , i was asking when i were just starting my career but i understood Object Orientation as i progress in my career.
but for very basic startng point in oop.
1- think about object just try to relate your daily household things like ( your laptop, your ipad, your Mobile, your pet)
Step 2-
Try to relate objects like ( Your TV an your remote ) this gives you the basic idea how object should relate to each other.
Step 3-
Try to visulize how things compose to create a full feature like your Body compose of (Heart, Lungs and many other organs)
Step 4-
Try to think about object lifetime ( Like as a example a car enigne is less useful outside Car , so if car is a object than this object must contain a engine and when actual car object destroys engine is also destroyed)
Step 5-
Try to learn about a polymorphism ( Like a ScrewDriver can take may shapes according to your need then map to your objects if your using c# than try to leran about ToString() method overriding)
Step 6 -
Try to create a real life boundry to your real life object ( Like your House ; You secure your house by various means )
this is the initial learning .. read as much as text as you find and try to learn by your own examples
in the last ; oop is an art first , try to visulize it.
my main suggestion is to look at the objects as "smart serfs": each one of these will have memory (the data members) and logic (the member functions).
In my experience, the biggest strength of OOP is the control that you have on the evolution of your design: if your software is remotely useful, it will change, and OOP gives you tools to make the change sustainable. In particular:
a class should change for only one reason, so it must be solve only one problem (SINGLE RESPONSABILITY PRINCIPLE)
changing the behaviour of a class should be made by extending it, not by modifying it (OPEN CLOSED PRINCIPLE)
Focus on interfaces, not on inheritance
Tell, don't ask! Give orders to your objects, do not use them as "data stores"
There are other principles, but I think that these are the ones that must be really understood to succeed in OOP.
I'm not sure I ever understood OOP until I started programming in Ruby but I think I have a reasonable grasp of it now.
It was once explained to me as the components of a car and that helped a lot...
There's such a thing as a Car (the class).
my_car and girlfriends_car are both instances of Car.
my_car has these things that exist called Tyres.
my_car has four instances of Tyres - tyre1, tyre2, tyre3, tyre4
So I have two classes - Car, Tyre
and I have multiple instances of each class.
The Car class has an attribute called Car.colour.
my_car.colour is blue
girlfriends_car is pink
The sticking point for me was understanding the difference between class methods and instance methods.
Instance Methods
An instance method is something like my_car.paint_green. It wouldn't make any sense to call Car.paint_green. Paint what car green? Nope. It has to be girlfriend_car.wrap_around_tree because an instance method has to apply to an instance of that Class.
Class Methods
Say I wanted to build a car? my_new_car = Car.build
I call a Class method because it wouldn't make any sense to call it on an instance? my_car.build? my_car is already built.
Conclusion
If you're struggling to understand OOP then you should make sure that you understand the difference between the Class itself and instances of that Class. Furthermore, you should try to undesrstand the difference between class methods and instance methods. I'd recommend learning some Ruby or Python just so you can get a fuller understanding of OOP withouth the added complicaitons of writing OOP in a non-OOP language.
Great things happen with a true OOP language. In Ruby, EVERYTHING is a class. Even nothing (Nil) is a class. Strings are classes. Numbers are classes and every class is descended from the Object class so you can do neat things like inherit the instance_methods method from Object so String.instance_methods tells you all the instance methods for a string.
Hope that helps!
Kevin.
It seems like you're asking about the procedures or "how-tos" of OOP, not the concepts.
For the how-tos, you're mostly correct: I'm not specifically familiar with PHP or ActionScript, but for those of us in .NET, your program will have some entry point which will take control, and then it will call vairous objects, functions, methods, or whatever- often passing control to other pieces of code- to perform whatever you've decided.
In psuedo-code, it might look something like:
EntryPoint
Initialize (instanciate) a Person
Validate the Person's current properties
Perform some kind of update and/or calculation
provide result to user
Exit
If what you're looking for is the "why" then you're already looking in the right places. The very definitions of the terms Encapsulation, Inheritance, etc. will shed light on why we do OOP.
It's mostly about grouping code that belongs to certain areas together. In non-OOP languages you often have the problem that you can't tell which function is used for what/modifies which structures or functions tend to do too many loosely related things. One work around is to introduce a strict naming scheme (e.g. start every function name with the structure name it's associated with). With OOP, every function is tied to a data structure (the object) and thus makes it easier to organize your code. If you code gets larger/the number of tasks bigger inheritance starts to make a difference.
Good example is a structure representing a shape and a function that returns its center. In non-OOP, that function must distinguish between each structure. That's a problem if you add a new shape. You have to teach your function how to calculate the center for that shape. Now imagine you also had functions to return the circumfence and area and ... Inheritance solves that problem.
Note that you can do OOP programming in non-OOP languages (see for example glib/gtk+ in C) but a "real" OOP language makes it easier and often less error-prone to code in OOP-style. On the other hand, you can mis-use almost every OOP language to write purely imperative code :-) And no language prevents one from writing stupid and inefficient code, but that's another story.
Not sure what sort of answer you're looking for, but I think 10s of 1000s of newly graduated comp sci students will agree: no amount of books and theory is a substitute for practice. In other words, I can explain encapsulation, polymorphism, inheritance at length, but it won't help teach you how to use OO effectively.
No one can tell you how to program. Over time, you'll discover that, no matter how many different projects your working on, you're solving essentially the same problems over and over again. You'll probably ask yourself regularly:
How to represent an object or a process in a meaningful way to the client?
How do I reuse functionality without copy-pasting code?
What actually goes in a class / how fine-grained should classes be?
How do support variations in functionality in a class of objects based on specialization or type?
How do support variations in functionality without rewriting existing code?
How do I structure large applications to make them easy to maintain?
How do I make my code easy to test?
What I'm doing seems really convoluted / hacky, is there an easier way?
Will someone else be able to maintain the code when I'm finished?
Will I be able to maintain the code in 6 months or a year from now?
etc.
There are lots of books on the subject, and they can give you a good head start if you need a little advice. But trust me, time and practice are all you need, and it won't be too long -- maybe 6 or 9 months on a real project -- when OO idioms will be second nature.