Disclaimer
Please don't just vote to close this because the title looks subjective, and if it's been asked before please point me to the previous question in the comments and I'll delete this one -- I really did look high and low trying to find a previous question on the subject.
Background
Given I have the following interface and concrete implementation:
public interface IFoo
{
// Some stuff
}
public class Foo : IFoo
{
// Concrete implementations of stuff
}
And somewhere I have the following method:
public Foo GiveMeAFoo()
{
return new Foo();
}
I have traditionally always returned Foo, seeing as it is inherently an IFoo anyway, so it can be consumed at the other end as an IFoo:
IFoo foo = GiveMeAFoo();
The main advantage of this that I can see is that if I really need to consume Foo somewhere as the concrete implementation, I can.
Actual Question
I recently came across some comments on another question, giving someone a hard time for doing this, suggesting the return type should be IFoo.
Am I wrong or are they? Can anyone give me a reason why returning the concrete implementation is a bad idea?
I know that it makes sense to require an IFoo when receiving a parameter to a method, because the less specific a parameter is, the more useful a method is, but surely making the return type specific is unreasonably restrictive.
Edit
The use of IFoo and Foo might have been too vague. Here's a specific example from .NET (in .NET, arrays implement IEnumerable -- i.e. string[] : IEnumerable<string>)
public string[] GetMeSomeStrings()
{
return new string[] { "first", "second", "third" };
}
Surely it's a bad idea to return IEnumerable here? To get the length property you'd now have to call Enumerable.Count(). I'm not sure about how much is optimised in the background here, but logic would suggest that it's now going to have to count the items by enumerating them, which has got to be bad for performance. If I just return the array as an array, then it's a straight property lookup.
If you want your method to be the most flexible that it can be, you should return the least derived type (in your case, IFoo):
public interface IFoo { }
public class Foo : IFoo { }
public IFoo GiveMeAFoo() { return new Foo(); }
That will allow you to change the concrete implementation of IFoo internal to your method without breaking anybody that is consuming your method:
public interface IFoo { }
public class Foo : IFoo { }
public class Foo2 : IFoo { }
public IFoo GiveMeAFoo() { return new Foo2(); }
You can create a bunch of interfaces and give it to different teams. Taking your own example
public interface IFoo
{
// Some stuff
}
public interface IBar
{
public IFoo getMeAFoo();
}
Then you can give these interfaces to a person developing a front end app and he doesn't have to know what the concrete implementation is. The guy developing the front end can use the getMeAFoo() method knowing that it returns an object of IFoo whereas the concrete implementation can be developed separately as:
public class Foo implements IFoo
{
// more stuff
}
public class MoreFoo implements IFoo
{
//
}
public class WunderBar implements IBar
{
public IFoo getMeAFoo()
{
case 1:
return new Foo();
case 2:
return new MoreFoo();
}
}
Hope this makes sense :)
In my opinion, it's always better to return the most abstract type you can. If you find yourself in need for anything that's specific to the type you ar actually returning, I would consider it a code smell.
The main advantage of this is that you can change your mind about which type you really want to return. The called method is made more decoupled from its callers.
Also, you can possibly remove dependencies. The caller code don't need to know anything about the actual type you chose to create.
My final remark is a quotation from Eric Lippert: "You probably should not return an array as the value of a public method or property". (His article is focused in C#, but the general idea is language-agnostic)
Fine, everywhere you use it, you use IFoo foo = GiveMeAFoo();
Then someone else uses your code and doesn't use it that way, for whatever reason, they use Foo foo = GiveMeAFoo();
Now they see all the functionality of Foo that isn't (for good reason) part of IFoo. Now they can use parts of the implementation that aren't part of the interface. Now you can't change your implementation without breaking their code, your implementation is now the public API and you are going to tick people off if you try to change your implementation details that they are counting on.
Not good.
Related
So I have made this simple interface:
package{
public interface GraphADT{
function addNode(newNode:Node):Boolean;
}
}
I have also created a simple class Graph:
package{
public class Graph implements GraphADT{
protected var nodes:LinkedList;
public function Graph(){
nodes = new LinkedList();
}
public function addNode (newNode:Node):Boolean{
return nodes.add(newNode);
}
}
last but not least I have created another simple class AdjacancyListGraph:
package{
public class AdjacancyListGraph extends Graph{
public function AdjacancyListGraph(){
super();
}
override public function addNode(newNode:AwareNode):Boolean{
return nodes.add(newNode);
}
}
Having this setup here is giving me errors, namely:
1144: Interface method addNode in namespace GraphADT is implemented with an incompatible signature in class AdjacancyListGraph.
Upon closer inspection it was apparent that AS3 doesn't like the different parameter types from the different Graph classes newNode:Node from Graph , and newNode:AwareNode from AdjacancyListGraph
However I don't understand why that would be a problem since AwareNode is a subClass of Node.
Is there any way I can make my code work, while keeping the integrity of the code?
Simple answer:
If you don't really, really need your 'addNode()' function to accept only an AwareNode, you can just change the parameter type to Node. Since AwareNode extends Node, you can pass in an AwareNode without problems. You could check for type correctness within the function body :
subclass... {
override public function addNode (node:Node ) : Boolean {
if (node is AwareNode) return nodes.add(node);
return false;
}
}
Longer answer:
I agree with #32bitkid that your are getting an error, because the parameter type defined for addNode() in your interface differs from the type in your subclass.
However, the main problem at hand is that ActionScript generally does not allow function overloading (having more than one method of the same name, but with different parameters or return values), because each function is treated like a generic class member - the same way a variable is. You might call a function like this:
myClass.addNode (node);
but you might also call it like this:
myClass["addNode"](node);
Each member is stored by name - and you can always use that name to access it. Unfortunately, this means that you are only allowed to use each function name once within a class, regardless of how many parameters of which type it takes - nothing comes without a price: You gain flexibility in one regard, you lose some comfort in another.
Hence, you are only allowed to override methods with the exact same signature - it's a way to make you stick to what you decided upon when you wrote the base class. While you could obviously argue that this is a bad idea, and that it makes more sense to use overloading or allow different signatures in subclasses, there are some advantages to the way that AS handles functions, which will eventually help you solve your problem: You can use a type-checking function, or even pass one on as a parameter!
Consider this:
class... {
protected function check (node:Node) : Boolean {
return node is Node;
}
public function addNode (node:Node) : Boolean {
if (check(node)) return nodes.add(node);
return false;
}
}
In this example, you could override check (node:Node):
subclass... {
override protected function check (node:Node) : Boolean {
return node is AwareNode;
}
}
and achieve the exact same effect you desired, without breaking the interface contract - except, in your example, the compiler would throw an error if you passed in the wrong type, while in this one, the mistake would only be visible at runtime (a false return value).
You can also make this even more dynamic:
class... {
public function addNode (node:Node, check : Function ) : Boolean {
if (check(node)) return nodes.add(node);
return false;
}
}
Note that this addNode function accepts a Function as a parameter, and that we call that function instead of a class method:
var f:Function = function (node:Node) : Boolean {
return node is AwareNode;
}
addNode (node, f);
This would allow you to become very flexible with your implementation - you can even do plausibility checks in the anonymous function, such as verifying the node's content. And you wouldn't even have to extend your class, unless you were going to add other functionality than just type correctness.
Having an interface will also allow you to create implementations that don't inherit from the original base class - you can write a whole different class hierarchy, it only has to implement the interface, and all your previous code will remain valid.
I guess the question is really this: What are you trying to accomplish?
As to why you are getting an error, consider this:
public class AnotherNode extends Node { }
and then:
var alGraph:AdjacancyListGraph = new AdjacancyListGraph();
alGraph.addNode(new AnotherNode());
// Wont work. AnotherNode isn't compatable with the signature
// for addNode(node:AwareNode)
// but what about the contract?
var igraphADT:GraphADT = GraphADT(alGraph);
igraphADT.addNode(new AnotherNode()); // WTF?
According to the interface this should be fine. But your implemenation says otherwise, your implemenation says that it will only accept a AwareNode. There is an obvious mismatch. If you are going to have an interface, a contract that your object should follow, then you might as well follow it. Otherwise, whats the point of the interface in the first place.
I submit that architecture messed up somewhere if you are trying to do this. Even if the language were to support it, I would say that its a "Bad Idea™"
There's an easier way, then suggested above, but less safe:
public class Parent {
public function get foo():Function { return this._foo; }
protected var _foo:Function = function(node:Node):void { ... }}
public class Child extends Parent {
public function Child() {
super();
this._foo = function(node:AnotherNode):void { ... }}}
Of course _foo needs not be declared in place, the syntax used is for shortness and demonstration purposes only.
You will loose the ability of the compiler to check types, but the runtime type matching will still apply.
Yet another way to go about it - don't declare methods in the classes they specialize on, rather make them static, then you will not inherit them automatically:
public class Parent {
public static function foo(parent:Parent, node:Node):Function { ... }}
public class Child extends Parent {
public static function foo(parent:Child, node:Node):Function { ... }}
Note that in second case protected fields are accessible inside the static method, so you can achieve certain encapsulation. Besides, if you have a lot of Parent or Child instances, you will save on individual instance memory footprint (as static methods therefore static there exists only one copy of them, but instance methods would be copied for each instance). The disadvantage is that you won't be able to use interfaces (can be actually an improvement... depends on your personal preferences).
I'm designing a framework and in the process I have come across an interesting but most likely basic problem. I have a base class called CoreEngine and two other classes that extend it: CoreEngine1 and CoreEngine2. I created an interface that each of these classes would implement to increase the flexibility of my project. However, I have a problem... The definition of my methods in the interface do not match the definition in each inherited class! Each class must implement the following method:
function get avatar():AvatarBase;
The problem is that CoreEngine1 and CoreEngine2 expect a different type of avatar:
CoreEngine1
function get avatar():AvatarScaling
CoreEngine2
function get avatar():AvatarPlatform
As you can see, the return type for avatar in CoreEngine1 and CoreEngine2 do NOT match the type as specified in the interface. I was hoping that since both AvatarScaling and AvatarPlatform inherit AvatarBase that I wouldn't have a problem compiling. However, this is not the case. According to Adobe's documentation, the types MUST match the interface. I am trying to follow one of the core concepts of object oriented programming to extend the flexibility of my framework: "Program to an interface rather than an implementation". The first thing that comes to my mind is that the return type of the accessor method should be of an interface type (Maybe I just answered my own question).
I'm certain this is a common problem others have run into before. Architecturally, what do you think is the best way to solve this problem? Thanks in advance!
Regards,
Will
This is a limitation of how interfaces work and are declared.
If there's inheritance that can happen with the return types, as you've described with AvatarBase and subclasses, then I think the right approach is to make the return type the lowest common denominator and just handle the resulting object on the other end. So, if you're dealing with a CoreEngine1 object, you know you can cast the result from AvatarBase to AvatarScaling. Alternately, if you don't know the object type that you are calling get avatar() on, then you can type check the returned value. The type check would then only be needed if you're looking to call a method that exists on AvatarScaling but not on AvatarBase. I don't think returning an interface type will buy you much in this case because the only things that interface can implement would be things that all forms of Avatar share, which wouldn't be any different than methods in AvatarBase.
Like HotN and Dinko mentioned, it would be best to allow get avatar() to return AvatarBase allways and then cast the returned object as the concrete subclass.
Using Dinko's example:
public /* abstract */ class CoreEngine
{
public /* abstract */ function get avatar():AvatarBase {}
}
public function CoreEngine1 extends CoreEngine
{
override public function get avatar():AvatarBase { return new AvatarScaling(); }
}
public function CoreEngine2 extends CoreEngine
{
override public function get avatar():AvatarBase { return new AvatarPlatform(); }
}
public /* abstract */ class AvatarBase {}
public class AvatarScaling extends AvatarBase
{
public function someAvatarScalingMethod():void {}
}
public class AvatarPlatform extends AvatarBase
{
public function someAvatarPlatformMethod():void {}
}
To use a method from AvatarScaling, cast the returned object:
var c1:CoreEngine1 = new CoreEngine1();
var avatarScaling:AvatarScaling = AvatarScaling(c1.avatar());
avatarScaling.someAvatarScalingMethod();
hth
I think you answered your own question... the return type would still be AvatarBase, you need to follow the signature that you specified in the interface... but you can technically return ANY descendent of AvatarBase in that function. So doing something like
return new AvatarScaling();
in CoreEngine1 would be perfectly acceptable.
Of course in your calling function you will get back an AvatarBase instance, and you will have to know what this is in order to cast to a specific subclass.
CoreEngine1 ce1 = new CoreEngine1();
AvatarScaling avatar = ce1.avatar() as AvatarScaling;
Which naming convention for conversions is standard across most languages?
convert_from_typea_to_typeb(arg)
or
convert_to_typeb_from_typea(arg)
Or is there another standard?
I'm going for the OO approach here, (in the relevant namespace) have a Convert class with a bunch of overloads To<TypeName> like so:
public class Convert
{
public Foo ToFoo(Bar instance);
public Foo ToFoo(Baz instance);
public Bar ToBar(Foo instance);
public Bar ToBar(Baz instance);
public Baz ToBaz(Foo instance);
public Baz ToBaz(Bar instance);
}
addition since php came specifically into the conversation; you cannot really do "overloading" in php, but there is a way to do it:
class ConversionException extends Exception
{
}
class Convert
{
public static function ToFoo($instance)
{
$from_type = get_class($instance);
$my_convert_method = $from_type . 'ToFoo';
if (method_exists(__CLASS__, $my_convert_method))
{
return self::$my_convert_method($instance);
}
else
{
throw new ConversionException(sprintf('Cannot convert %s to Foo.', $from_type));
}
}
protected static function BarToFoo(Bar $instance)
{
/* conversion implementation here */
}
protected static function BazToFoo(Bar $instance)
{
/* conversion implementation here */
}
/* you get the point */
}
My answer, and purely subjective, would be the one that flows logically with source to destination.
ConvertStringToInt()
or
ConvertVisitorToCustomer()
I guess in C(++) you would do it with cast operators, so none of these names would fit.
In Objective-C I've seen something like NSPointFromCGPoint(...), or you would give the old type simply in the constructor.
The only thing that I've seen very rarely are those functions with convert_x_to_y :-)
There is no cross-language standard for this kind of thing. Most languages either provide a built-in way to do this (C/C++) or encourage you to find another way around it (Java/C#).
In most object-oriented languages you shouldn't need this sort of functionality. You should try to restructure your program so that you do not need to do any explicit conversions.
However, if you really need to do this, I'd say drop the "convert" at the beginning and do <source>_to_<target>. Examples: string_to_int, int_to_float, foo_to_bar, etc. (Of course, write these in whatever case your language prefers. For example, in C#: StringToInt; in JavaScript: stringToInt.)
imagine there are two interfaces arranged via composite pattern, one of them has a dispose method among other methods:
interface IComponent extends ILeaf {
...
function dispose() : void;
}
interface ILeaf {
...
}
some implementations have some more things in common (say an id) so there are two more interfaces:
interface ICommonLeaf extends ILeaf {
function get id() : String;
}
interface ICommonComponent extends ICommonLeaf, IComponent {
}
so far so good. but there is another interface which also has a dispose method:
interface ISomething {
...
function dispose() : void;
}
and ISomething is inherited by ICommonLeaf:
interface ICommonLeaf extends ILeaf, ISomething {
function get id() : String;
}
As soon as the dispose method is invoked on an instance which implements the ICommonComponent interface, the compiler fails with an ambiguous reference error because ISomething has a method called dispose and ILeaf also has a dispose method, both living in different interfaces (IComponent, ISomething) within the inheritace tree of ICommonComponent.
I wonder how to deal with the situation if
the IComponent, the ILeaf and the ISomething can't change.
the composite structure must also work for for the ICommonLeaf & ICommonComponent
implementations and the ICommonLeaf & ICommonComponent must conform to the ISomething type.
this might be an actionscript-3 specific issue. i haven't tested how other languages (for instance java) handle stuff like this.
You are searching for a solution to the Diamond Problem. C# has an approach to this but basically I would factor the method "dispose" out of your interfaces and create a new "IDisposable".
If the same name like "id" is used twice, it looks like a problem in your code with an ambiguous name. We started to add prefixes to properties and methods. Imagine you have a property "name" that belongs to two different things. Like the "displayName" and the "uniqueName".
This also helps with auto completion. If a DisplayObject is an ILayoutObject and yout type displayObject.layout you get everything layout releated.
It seems casting solves the ambiguity even though it's far from neat.
class SomeComponent implements ICommonComponent {}
var c : ICommonComponent = new SomeComponent();
trace(ISomething(c).dispose()); //compiles
trace(IComponent(c).dispose()); //compiles
trace(c.dispose()); //fails
As far as I'm aware, there's no neat way to deal with this problem in Actionscript.
The only thing I can think of is refactoring your interfaces to avoid name clashes, which, admitedly, it's not always possible.
Don't know about Java, but C# has a way to handle this through explicit interface implementation.
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 1 year ago.
Improve this question
I frequently find myself creating classes which use this form (A):
abstract class Animal {
public void Walk() {
// TODO: do something before walking
// custom logic implemented by each subclass
WalkInternal();
// TODO: do something after walking
}
protected abstract void WalkInternal();
}
class Dog : Animal {
protected override void WalkInternal() {
// TODO: walk with 4 legs
}
}
class Bird : Animal {
protected override void WalkInternal() {
// TODO: walk with 2 legs
}
}
Rather than this form (B):
abstract class Animal {
public abstract void Walk();
}
class Dog : Animal {
public override void Walk() {
// TODO: do something before walking
// custom logic implemented by each subclass
// TODO: walk with 4 legs
// TODO: do something after walking
}
}
class Bird : Animal {
public override void Walk() {
// TODO: do something before walking
// custom logic implemented by each subclass
// TODO: walk with 2 legs
// TODO: do something after walking
}
}
As you can see, the nice thing about form A is that every time you implement a subclass, you don't need to remember to include the initialization and finalization logic. This is much less error prone than form B.
What's a standard convention for naming these methods?
I like naming the public method Walk since then I can call Dog.Walk() which looks better than something like Dog.WalkExternal(). However, I don't like my solution of adding the suffix "Internal" for the protected method. I'm looking for a more standardized name.
Btw, is there a name for this design pattern?
I'm not sure if there is a standard naming convention for this. Besides WalkInternal, other alternatives might be DoWalk or WalkImpl.
Btw, is there a name for this design pattern?
Your first example uses aspects of the Template Method pattern and is similar to what Herb Sutter calls the "Non-virtual Interface Idiom":
http://www.gotw.ca/publications/mill18.htm
I prefer to name my virtual or abstract methods with the suffix Core, to indicate, that the method should contain the core logic to do something.
All argument checks and raising possible events I do in the method, that calls the Core-Methods.
abstract class Animal {
public void Walk() {
// TODO: do something before walking
// possible Argument checks and event raising
// custom logic implemented by each subclass
WalkCore();
// TODO: do something after walking
}
protected abstract void WalkCore();
}
class Dog : Animal {
protected override void WalkCore() {
// TODO: walk with 4 legs
}
}
class Bird : Animal {
protected override void WalkCore() {
// TODO: walk with 2 legs
}
}
I think there is no offical naming guideline for this, and it´s up to you. But it should be consistent for all classes and virtual/abstract methods you define.
The "Framework Design Guidelines" suggest to use the Core suffix if you follow the Template Method and want to provide extensibility points.
Good question. The pattern is valid and I use it a lot. I also agree that WalkInternal is not an ideal name.
In this example I believe you are not framing the problem correctly.
Rather than renaming the 'internal' method, look at your 'external' public method. It's called Walk, but it has code snippets (//do something before walking and //do something after walking) which clearly shows that it contains more than just the logic for 'Walking'. Maybe this method should be called Exercise or GoToTheShops - or whatever creative name you can think of that describes what you are doing. Whatever the method is, it's definitely a superset of Walking + some other pre / post walking actions.
A similar example that I've recently developed had a public method called Complete, and a virtual called Save, so that:
Every class needed to 'Complete'
Different implementations would have their own 'Save' method
'Complete' would also perform some validation, notification, etc
In summary, the abstract method should be called Walk, and instead you should rename your public method to something that more accurately describes the 'do something / Walk / do something' process.
edit: If the Walk class doesn't add any significant value or logic to the WalkInternal class then I would question whether it is required. If it does add logic, then it should be renamed to reflect its new function.
I use the convention of an underscore capitalized case for abstract overrides, so Dog._Walk, although I more than occasionally wonder if there wasn't a better way.
I like DoWalk better than WalkInternal - it's shorter & conveys the idea that its an override quickly and upfront. "Do" anything kind of rubs me the wrong way though, kind of like "My" object does. I like my underscore followed by capital letter convention best, still.
Good real life question though
One name for this pattern is "Template Method Pattern"
In C#, the method to be overridden by a derived class is preceded by "On". The logic behind this naming is that the derived class is custom responding to what is conceptually an internal event. This led to some confusion with C#'s other, now deprecated, use of "On" for raising events, but that's an old C# specific problem and it doesn't really exist anymore.
class BaseClass
{
protected virtual void OnInitialize() {};
private PreInitialize() {}
private PostInitialize() {}
void Initialize()
{
PreInitialize();
OnInitialize();
PostInitialize();
}
}
class DerivedClass : BaseClass
{
protected override void OnInitialize() { /*do whatever*/ }
}
For a method that provides a template method's primary behavior, I use names like WalkOverride. The base class implements it as either a protected abstract method (derived class is required to provide implementation) or a protected virtual empty/non-empty one (derived class may optionally provide/override implementation). Examples can be found in Microsoft's various XAML frameworks with methods such as MeasureOverride and ArrangeOverride. (The WalkCore pattern #Jehof mentions is used there to name the template method itself.)
For "events" to which the derived class can optionally respond for its own purposes (as opposed to defining the template method's behavior), I use names like OnWalking and OnWalked. Each of these is usually implemented in the base class as a protected virtual method with an empty method body.
Methods are means of taking action and going by that rule method names should be either verb or verb phrases.And its applicable to methods irrespective of where they are declared.For me Dog.Walk looks more natural than Dog.WalkInternal.And yes naming of method is more of a guideline than a design pattern :).If you are a .Net guy , then I will recommend "Framework Design GuideLines" book by Brad Adam and Krzystof Cwalina , which clearly address such problems.