Let's say I have a class modeling some kind of object, for example a graph (in the graph theory sense).
I will have the graph structure and data inside the class, but what about other more complex behaviors? For example, I want to create a function that transforms the graph in a specific way, or that dumps the graph in JSON format. Should these functions be inside or outside the class?
My first thought is to put these kinds of functions inside the class, but if I put a lot of functions, each graph object will take way more memory right?
Are there clear guidelines for this question ? Also, is it language dependant?
There are not strong guidelines around this AFAIK, apart from OOP principles.
The function that dumps the graph in JSON format should be part of the class, because it directly uses the graph data-structure (which should be private), so instead of exposing that externally and using a different class to convert the graph to JSON, it's more convenient to have a method like graph.toJson() and get JSON string.
On the same idea, if you want to transform a graph into a tree, or to balance a tree, it's more convenient to call graph.toTree() or tree.balance(), so methods should be part of the class.
Generically, I would add the functionality outside of the class, only when it can be re-used and it doesn't depend on the internal state of the class.
When you add multiple methods on a class, this doesn't mean the object consumes more memory. Memory gets allocated when the method is called. When you just pass around graph objects, the main memory will be allocated by the graph data-structure.
There are some options to inject dependencies in FP. I want to compare here only the two:
Injection via parameter list
Injection via Reader
The 2nd case is more composable and less verbose, in case I invoke several methods with dependencies. It lets me pass a dependency once. But I still do not feel it, or do not have exact rules, when it is better to pass via Reader or not.
For instance, passing external dependency to a service, is more convenient via Reader. But for instance, an instance of Map or some DTO/case class objects, which can be considered just as a holder of some input data attributes.
During my current experience, I've found for instance, that when readers with different set of dependencies are used, it is getting more verbose to transform them to each other. And sometimes a code does not look clear.
I know, such questions are not good for [stackoverflow.com], but I believe this issue is not subjective and certain arguments can be given to choose a correct option.
I'm trying to add some re-usability to a Java library which has some common methods across classes, but whose methods are not part of a common hierarchy. I'm pretty certain I've seen it previously that Scala allows non-trait based contracts for parameter classes, but for the life of me I cannot find this information anywhere at the moment.
Does my memory serve me correctly? Would anybody be able to point me in the right direction for documentation on said language feature (if I am not mistaken)?
For some added context, I'm trying to reduce duplicate code when using some Google Java libraries where things like getNextPageToken(), setPageToken(), etc. are common between many classes, but are not implemented further up in the hierarchy where I would have the option to specify a common parent class as the parameter type. So essentially I'd like to enforce that these methods exist and offload the duplicate request & pagination code to a common function using said method contracts.
You probably want to use structural types:
example:
def method(param: { def getNextPageToken(): Unit })
param will be required to have getNextPageToken method with no parameters and returning Unit. It is handled using reflection.
I'm currently prototyping a small project in Plone and trying to KISS as much as possible while the requirements are still in flux. To that end, I've resisted creating any custom content types for now and have been using marker interfaces to distinguish between "types" of content.
Now that I'm looking at workflow, I've realised that they're bound to types, and there doesn't seem to be a mechanism for assigning them to markers. I think I could wrap portal_workflow with my own version that looks for markers and returns the appropriate workflow if found, however, this doesn't feel like a tenable approach.
Is there a way of assigning workflow to markers that I've missed, or should I just bite the bullet and create some lightweight custom content types instead?
There's not really a built-in feature to use markers, but at http://www.martinaspeli.net/articles/dcworkflows-hidden-gems, Martin Aspeli hints that it is possible:
Note that in Plone, the workflow chain of an object is looked up by
multi-adapting the object and the workflow to the IWorkflowChain
interface. The adapter factory should return a tuple of string
workflow names (IWorkflowChain is a specialisation of IReadSequence,
i.e. a tuple). The default obviously looks at the mappings in the
portal_workflow tool, but it is possible to override the mapping, e.g.
in resopnse to some marker interface.
I have class method that returns a list of employees that I can iterate through. What's the best way to return the list? Typically I just return an ArrayList. However, as I understand, interfaces are better suited for this type of action. Which would be the best interface to use? Also, why is it better to return an interface, rather than the implementation (say ArrayList object)? It just seems like a lot more work to me.
Personally, I would use a List<Employee> for creating the list on the backend, and then use IList when you return. When you use interfaces, it gives you the flexability to change the implementation without having to alter who's using your code. If you wanted to stick with an ArrayList, that'd be a non-generic IList.
# Jason
You may as well return IList<> because an array actually implements this interface.
The best way to do something like this would be to return, as you say, a List, preferably using generics, so it would be List<Employee>.
Returning a List rather than an ArrayList means that if later you decide to use, say, a LinkedList, you don't have to change any of the code other than where you create the object to begin with (i.e, the call to "new ArrayList())".
If all you are doing is iterating through the list, you can define a method that returns the list as IEnumerable (for .NET).
By returning the interface that provides just the functionality you need, if some new collection type comes along in the future that is better/faster/a better match for your application, as long as it still implements IEnumerable you can completely rewrite your method, using the new type inside it, without changing any of the code that calls it.
Is there any reason the collection needs to be ordered? Why not simply return an IEnumerable<Employee>? This gives the bare minimum that is required - if you later wanted some other form of storage, like a Bag or Set or Tree or whatnot, your contract would remain intact.
I disagree with the premise that it's better to return an interface. My reason is that you want to maximize the usefulness a given block of code exposes.
With that in mind, an interface works for accepting an item as an argument. If a function parameter calls for an array or an ArrayList, that's the only thing you can pass to it. If a function parameter calls for an IEnumerable it will accept either, as well as a number of other objects. It's more useful
The return value, however, works opposite. When you return an IEnumerable, the only thing you can do is enumerate it. If you have a List handy and return that then code that calls your function can also easily do a number of other things, like get a count.
I stand united with those advising you to get away from the ArrayList, though. Generics are so much better.
An interface is a contract between the implementation and the user of the implementation.
By using an interface, you allow the implementation to change as much as it wants as long as it maintains the contract for the users.
It also allows multiple implementations to use the same interface so that users can reuse code that interacts with the interface.
You don't say what language you're talking about, but in something .NETish, then it's no more work to return an IList than a List or even an ArrayList, though the mere mention of that obsolete class makes me think you're not talking about .NET.
An interface is essentially a contract that a class has certain methods or attributes; programming to an interface rather then a direct implementation allows for more dynamic and manageable code, as you can completely swap out implementations as long as the "contract" is still held.
In the case you describe, passing an interface does not give you a particular advantage, if it were me, I would pass the ArrayList with the generic type, or pass the Array itself: list.toArray()
Actually you shouldn't return a List if thats a framework, at least not without thinking it, the recommended class to use is a Collection. The List class has some performance improvements at the cost of server extendability issues. It's in fact an FXCop rule.
You have the reasoning for that in this article
Return type for your method should be IList<Employee>.
That means that the caller of your method can use anything that IList offers but cannot use things specific to ArrayList. Then if you feel at some point that LinkedList or YourCustomSuperDuperList offers better performance or other advantages you can safely use it within your method and not screw callers of it.
That's roughly interfaces 101. ;-)