can i have same method name with same params and params type in a single class? how about in a different class with same name?
In response to the first part is the ans overriding? what about the second part of the questions "how about in a different class with same name?"
I think there a few examples in which the answer to both your questions is yes, but as far as my knowledge in Java and Objective C is concerned, you cannot have two methods named exactly the same with same parameter names and types in the same class. I believe that you can in two different classes, but you generally shouldn't, just to keep your code simple and easily understandable, but you can do it all the same.
Related
https://www.tutorialspoint.com/java/java_polymorphism.htm#:~:text=Polymorphism%20is%20the%20ability%20of,is%20considered%20to%20be%20polymorphic.
As per the link above, in which they say:
Polymorphism is the ability of an object to take on many forms.
I'm having trouble figuring out whether to take this literally or not.
From my knowledge of polymorphism, classes are polymorphic when they can have multiple children, each implementing a parent class method in a different way.
A function can be polymorphic as we can overload and override them so functions can display different behaviors.
I was told and taught that another form of polymorphism applies to objects that inherit from multiple parent classes.
In C++ for example an object may behave differently depending on its reference type if its methods aren't virtual.
Another example that comes to mind is in Java with multiple interfaces, I can look at an object as different types causing different expected behaviors.
Are these examples really considered polymorphism at play or is this just inheritance and Polymorphism best defines the first two examples (classes and methods)
Thanks
The literal meaning of the word "polymorphism" is what the tutorial says. However it makes very little sense to use the literal meaning of a technical term. In OOP, "polymorphism" means subtyping. There are other ways the term "polymorphism" is used in programming (ad-hoc and parametric polymorphism) but they are not related to OOP specifically.
"Polymorphic object" is not a standard term across the OOP literature. It has a very specific meaning in C++, and it's not "an object with several base classes". It is simply an object with at least one virtual function. From the OOP perspective, a C++ "polymorphic object" is just an object.
Deriving from more than one base classes is called multiple inheritance. I have never heard anyone using the term "polymorphism" for this.
I have classes using the strategy pattern (each class has the same single method, but implements it very differently). I have another class which chooses the implementation to use based on runtime-accessible values. I have one final class which basically pulls the others together, calls the necessary methods of the implementing class and formats the output.
What could I name this controller class to make it at least semi-clear what it is for? Before someone asks, it is already a very small class (< 100 lines), not worth splitting - I'm confident that it's not because of multiple responsibilities that I'm having trouble naming it.
I want to say "controller" - but that's already a specific concept in MVC architecture (which our app is using). Any ideas? Is there an accepted name for the pattern I'm describing?
In OOP, classes should generally be named after what they are; class names should be nouns. You already know that.
The problem with class names like XyzManager or XyzController is that although technically they are nouns, they're really verbs disguised as nouns. Thus, such classes are named after what they do, instead of what they are. That makes them not objects, but services, or functions.
Now, naming is hard, and sometimes it can't be avoided with an XyzManager. Often, when it happens, it's because you've not yet realised what concept the class really should encapsulate. Still, you should strive to identify what the class is, instead of what it does, and name it after that.
FWIW, I often use a thesaurus (there are several excellent online services for that) to find a good name.
I would like to name it Service
Example: if you have a TaxStrategyGerman, TaxStrategyFrench that are chosen by TaxStrategyFactory and used by TaxCalculationService.
I'm having trouble finding the standard way a class diagram should be drawn for objective C applications. Mostly:
Do I incude field types or just the var name?
Do I include method return types and parameters?
Thank you!
Many of the Objective-C diagrams I have seen do not include types or parameters. Only the field and method names are placed in the diagram.
However, I would strongly encourage you to include all this information, regardless of what the norm may be. By doing so, the class diagram is not only useful for modelling, but also serves as documentation. It's not particularly difficult to add the type annotations, and the end result is a far more complete (and useful) picture of the class.
Document them the same way you would document a class in any other object oriented language. Class properties should include the field type, property name and multiplicity. Class methods should include return types and parameters.
Do you know programming languages where changing the class of an object at runtime is allowed (supported)?
Please give a short example regarding the syntax. Give a use case, if you know any. Examples involving duck typing are welcome as well, so do not shy away from mentioning these languages.
Update: I figured out that Smalltalk has changeClassTo and become. CLOS can do change-class. I found a paper suggesting to use these mechanisms to implement 'husk objects' that are referenced at runtime, but only constructed from some persistence when actually accessed, providing some nifty lazy loading of related objects.
I assume, you mean the following:
You have an object of class A. But you would like to treat it as an object of class B.
There are some constructions possible:
If B is a subclass of A you can cast the object to B (but it should be created as B else you have unexpected (and hopefully unwanted) results).
In some languages you can cast anything to anything. If you know what you are doing, this is great, else prepare for several holes in your foot.
You mention ducktyping. I have no practical experience with it. But As far as I know, duck typing is something like this: "I need an object that support methods X, Y and Z." In that case you don't care about the class. You just want it to quack, swim and walk at your command.
Give a usecase
??? I'd expect you to ask for a solution on a specific use case.
Changing type of an object? I think "No."
But if you like to change part of an objects capabilities or behaviours have a look at loosely coupling!
For example your class holds a member of type File_Saver. There's a public setter accepting any instance of File_Saver and you can inject File_Saver_XML, File_Saver_PDF, ...
It's no common way, but any processing inside a class can be done by 1-n loosely coupled handlers, which you can exchange from outside.
Melt down to your question: You need a wrapper + a setter. :-)
Coming back to the case after some time, I've come to the conclusion that you want duck typing if you feel the need of changing an objects class.
Let's say you have a Person object and it has a method on it, promote(), that transforms it into a Captain object. What do you call this type of method/interaction?
It also feels like an inversion of:
myCaptain = new Captain(myPerson);
Edit: Thanks to all the replies. The reason I'm coming across this pattern (in Perl, but relevant anywhere) is purely for convenience. Without knowing any implementation deals, you could say the Captain class "has a" Person (I realize this may not be the best example, but be assured it isn't a subclass).
Implementation I assumed:
// this definition only matches example A
Person.promote() {
return new Captain(this)
}
personable = new Person;
// A. this is what i'm actually coding
myCaptain = personable.promote();
// B. this is what my original post was implying
personable.promote(); // is magically now a captain?
So, literally, it's just a convenience method for the construction of a Captain. I was merely wondering if this pattern has been seen in the wild and if it had a name. And I guess yeah, it doesn't really change the class so much as it returns a different one. But it theoretically could, since I don't really care about the original.
Ken++, I like how you point out a use case. Sometimes it really would be awesome to change something in place, in say, a memory sensitive environment.
A method of an object shouldn't change its class. You should either have a member which returns a new instance:
myCaptain = myPerson->ToCaptain();
Or use a constructor, as in your example:
myCaptain = new Captain(myPerson);
I would call it a conversion, or even a cast, depending on how you use the object. If you have a value object:
Person person;
You can use the constructor method to implicitly cast:
Captain captain = person;
(This is assuming C++.)
A simpler solution might be making rank a property of person. I don't know your data structure or requirements, but if you need to something that is trying to break the basics of a language its likely that there is a better way to do it.
You might want to consider the "State Pattern", also sometimes called the "Objects for States" pattern. It is defined in the book Design Patterns, but you could easily find a lot about it on Google.
A characteristic of the pattern is that "the object will appear to change its class."
Here are some links:
Objects for States
Pattern: State
Everybody seems to be assuming a C++/Java-like object system, possibly because of the syntax used in the question, but it is quite possible to change the class of an instance at runtime in other languages.
Lisp's CLOS allows changing the class of an instance at any time, and it's a well-defined and efficient transformation. (The terminology and structure is slightly different: methods don't "belong" to classes in CLOS.)
I've never heard a name for this specific type of transformation, though. The function which does this is simply called change-class.
Richard Gabriel seems to call it the "change-class protocol", after Kiczales' AMOP, which formalized as "protocols" many of the internals of CLOS for metaprogramming.
People wonder why you'd want to do this; I see two big advantages over simply creating a new instance:
faster: changing class can be as simple as updating a pointer, and updating any slots that differ; if the classes are very similar, this can be done with no new memory allocations
simpler: if a dozen places already have a reference to the old object, creating a new instance won't change what they point to; if you need to update each one yourself, that could add a lot of complexity for what should be a simple operation (2 words, in Lisp)
That's not to say it's always the right answer, but it's nice to have the ability to do this when you want it. "Change an instance's class" and "make a new instance that's similar to that one" are very different operations, and I like being able to say exactly what I mean.
The first interesting part would be to know: why do you want/need an object changes its class at runtime?
There are various options:
You want it to respond differently to some methods for a given state of the application.
You might want it to have new functionality that the original class don't have.
Others...
Statically typed languages such as Java and C# don't allow this to happen, because the type of the object should be know at compile time.
Other programming languages such as Python and Ruby may allow this ( I don't know for sure, but I know they can add methods at runtime )
For the first option, the answer given by Charlie Flowers is correct, using the state patterns would allow a class behave differently but the object will have the same interface.
For the second option, you would need to change the object type anyway and assign it to a new reference with the extra functionality. So you will need to create another distinct object and you'll end up with two different objects.