Iterator pattern [closed] - oop

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

Related

Testing/TDDing Private Methods [closed]

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 3 years ago.
Improve this question
Yet ANOTHER post about testing private methods, but this one I hope will be a little different to the norm.
People are always wondering whether a private method should in fact be public or the functionality extracted into another class where it can be tested, or end up making other compromises.
Many programming/scripting languages off a Reflections class, so with that in mind, why can't we automate a way of making our private methods testable? For example, let's say we have a class with a private method that we want to test, surely something like this will work:
class ClassWeWantToTest {
private somePrivateMethod([args, ...]) {
// Do stuff.
}
}
class ClassWeWantToTest_TestWrapper extends ClassWeWantToTest {
public somePrivateMethod_test([args, ...])
{
return this->somePrivateMethod([args, ...]);
}
}
Such testing layers can be made manually and automatically in languages that allow it. There could even be a third party tool that understands the syntax, which will parse a class and generate a layer. Obviously, private methods will only be made public to the tests. In normal use, the private methods remain private.
Why hasn't it been done already? Is this a really stupid idea? I assume it is because it hasn't been done already. It would certainly help with class-clutter, where classes are just being created to help with testability. I know, it would expose the entire class, but so what? The developer knows how it works and can now test more aspects of his code without having to work blind. The developer would be able to work with the class with or without the wrapper which would give even more flexibility.
Many programming/scripting languages off a Reflections class, so with that in mind, why can't we automate a way of making our private methods testable?
You can, but you are putting the priorities the wrong way around.
The point of TDD is to improve your designs. One important element of the design is that the parts that are important to test are also easy/cost-effective to test.
Writing the same spaghetti code we've always written, but with tests, misses this.
More broadly, if you have a "private" method that is complicated enough that you aren't comfortable with the risks when you are only testing the public interfaces, then that's a big hint that what you really have is a concept that is separate and distinct from that of the enclosing method/class. Ergo, the remedy is to redesign your solution so that you can get your test probes where you want them.
You may want to review Martin Fowler on Published methods
There's something to be said for the public-published distinction being more important than the more common public-private distinction.

Understanding the relationship between protocols and delegates [closed]

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).

Generator, enumerator, iterator definitions [closed]

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.
Could someone provide definition for generator, enumerator, iterator terms. It seems different languages use these arbitrary and I would like to know exact differences.
An enumerator is a way of labeling values. If you had a container of integers, you could define an enumeration for possible values. It is easier to remember named values then numbers, for example imagine if everyone you knew didn't have a name, but instead was given a unique number. It would be harder to remember.
An iterator is an object that allows you to traverse a container. You iterate through it step by step. Some containers are straightforward to step through (like a contiguous array) but others aren't (like a linked list, where each element can be randomly scattered throughout memory, or a binary tree where there may be different possible orders to step through the data). Iterators allow you to traverse the container without worrying about these kinds of details.
As for generators, I am not familiar with them so I will leave you this quote from wikipedia:
In computer science, a generator is a special routine that can be used to control the iteration behaviour of a loop. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values. However, instead of building an array containing all the values and returning them all at once, a generator yields the values one at a time, which requires less memory and allows the caller to get started processing the first few values immediately. In short, a generator looks like a function but behaves like an iterator.
Wikipedia provides perfectly good generic definitions:
Iterator
Generator
Enumerator
In short, an iterator is a class that can be read repeated using a loop; a generator is a function that acts like an iterator by returning its values one-by-one; and an enumerator is a data type containing a list of possible values that can be used in a variable definition to force it to only contain one of those values.
As far as I know, the usage of these terms is pretty consistent between languages, albeit with different syntax (obviously). What have you seen that has confused you?

Are Polymorphism , Overloading and Overriding similar concepts? [closed]

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.

explanation of aggregation, containment & delegation in com [closed]

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.