I am teaching myself how to use object oriented programming with MATLAB and have a question about access.
I have three current classes that need to interact with each other. One class, which I'll call main, is what the user will interface with (or the gui if I build one). Main stores all of the pertinent data that the use may want and has a few methods to perform some preprocessing and to construct the main object. Main also calls the constructors for the two other classes.
Another class, I'll call it instruction, loads information about the steps to process the data (this is a recursive process) and some other information.
The final class, which I'll call core, performs the core operations of the process.
Heres what my question is. Within main I have some "helper" methods that are used in the preprocessing. I want the access to these helper methods to be private so that the user cannot see or use them. Some of these helper functions also need to be used by the processes in core. My question is how do I grant access to the helper functions in main so that only main and core can access them? I have tried to understand the information provided here: http://www.mathworks.com/help/matlab/matlab_oop/selective-access-to-class-methods.html, but when I try something like:
classdef main < handle
%this is the main class
properties
core %the core object
instruction %the instruction object
end %properties
methods (Access = {?core,?main})
... %some code
end %methods
end %class
Matlab gives me this error:
Illegal value for attribute 'Access'.
Parameter must be a string.
Any help would be greatly appreciated!
Andrew
Btw, I realize that having three different classes is unnecessary here but as I stated I am just learning object oriented programming and when I started this project I thought it would be a good idea to have multiple classes because the total project will be over 5000 lines of code.
Is it possible you're using a relatively old version of MATLAB?
The ability to give access to class methods to specific classes was implemented in release 2012a.
If you're using a version of MATLAB older than that, you can only set method access attributes to public, protected or private.
Note that the documentation page you link to always refers to the current version of MATLAB (2014a at the moment). You can access old versions of the documentation via the website as well by logging into your MathWorks account.
If you have methods of main that need to be accessed by core, that could be a sign that you've designed your class relationships poorly. If core is a property of main, then perhaps it could be a method of core, and main could call it via core.
Selective access is needed quite rarely. The main reason for not using it, is that it breaks the encapsulation principle of OOP. I would consider changing your design, before implementing it.
For more information, check out the friend keyword in C++. Most likely you will find a lot of information on it, and why not to use it.
Related
I am working with a legacy scala codebase, and as is always the case modifying the code is quite difficult without touching different parts.
One of my new requirement in to make several decisions based on some input parameters. Problem is that these decisions are to be made at various points along the execution. So either I encapsulate all those parameters in a case class instance and pass it along. But it means I would have to modify multiple methods signatures, and I want to avoid this approach as much as possible.
Another approach can be to create a global object containing all those input parameters and accessible from different points in the execution. Is it a good approach in Scala?
No, using global mutable variables to pass “hidden” parameters is not a good idea, not in Scala and not in any other programming language. It makes the code hard to understand and modify, because a function's behaviour will now depend on which functions were invoked earlier. And it's extremely fragile, because you might forget setting one of those global parameters before invoking the function, which means that it will use whatever value was stored there before. This is the kind of thing that can appear to work for years, and then break when you modify a completely unrelated part of the program.
I can't stress this enough: do not use global mutable variables, period. The solution is to man up and change those method signatures. Depending on the details, dependency injection may or may not help in your particular case.
In C++ (at least as of a decade ago), there was speed advantage in defining the body of a class method in the header file, where the class is defined. No function call overhead was suffered because, in the compilation process, the invocation of such functions was replaced by the code in the body of the function. Subsquently, all source level optimizations (and all optimizations beyond source level) could be brought to bear.
Is there an analogous advantage to putting the body of class methods in the classdef file itself rather than in a separate m-file? I'm speaking specifically about the case where one defines a #myclass/myclass.m, with method m-files in the directory #myclass. The two options I'm considering is to have the code for the body of a method mymethod put into the classdef in #myclass/myclass.m versus being in a separate file #myclass/mymethod.m.
However, an very related auxiliary question would be how those two options compare with having everything defined in a myclass.m file, with no folder #myclass.
Please note that I have previously posted this to usenet
Summarizing the comments as the answer to this question: Using an #classFolder folder containing separate method m-files is faster than having a single m file containing the entireties of the function definitions in the classdef. This is the case even though OOP in general has sped up in 2015b.
I find this a happy answer because I see great value in separating the code implementation of a class's methods from the class definition itself. That's the whole idea of separating interface from implementation. I can look at the classdef and see only a map of the class rather than have those key information elements completely dispersed by the deluge of code that accompanies implementation.
It's just too bad that this doesn't work so well for weakly typed languages. What's listed in the classdef is just member names (properties or methods) with no specification of what class they are. So not as much information as in a strongly typed language. In fact, very little info about what the class, its properties, and its methods really are. Furthermore, there is nothing to ensure that the actual method implementation even complies with the argument list in the classdef. These kind of details helped prevent development errors in a strongly typed language, especially when one's body of classes get large.
I'm developing a robotics application in Matlab for my thesis. I'm experienced in C#, PHP, js, etc etc.
I would love if objects I create could somehow be passed by reference. I heard that there are things called "handle objects" and others called "value objects". I can't find any specific documentation on how to create a "handle object" and it seems they are usually graphics objects.
I have a few design patterns that are easy to implement when passing by reference is possible. I would like certain objects to share 'simulation spaces', without making each space a global variable. I would like to avoid passing IDs around everywhere, in an effort to keep objects synchronized. I would like to share environmental objects between robots, without worrying about the fact that passing this object actually copies it. (this will lead to bugs over time)
I'm starting to feel like my only solution will be to have a weird global 'object broker' that has the latest copy of many common system objects. I hope to avoid this sort of thing!
Any advice would be amazing!
Handle objects are created by the following syntax
classdef myClass < handle
properties
% properties here
end
methods
% methods here
end
end
A good place to start looking in the documentation is the classes start page. Note that value and handle classes have only been implemented in R2008a, and are reasonably bug-free since R2009a (though more recent releases have improved performance quite a bit).
If you're coming from other languages, this section about the differences between Matlab and other languages OOP can be useful.
Your classes should inherit from the handle abstract class
classdef MyHandleClass < handle
% // class stuff
Class with this semantics can be passed by reference in a java like way.
Consider also this section of the guide.
Would like to get some thoughts on how to best organize session vars within a scala / lift application.
I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:
declare an object that extends the SessionVar class
put that object into a file that contains a snippet (or any file)
access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)
Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.
For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)
Thanks.
This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.
If you need the session var only in one snippet, you should make it a private member of that class.
If you need it in several but not all snippets, put those snippets in a package and make the object private to that package. If you have a lot of them, you could create an extra file to hold them.
If you need it globally, put it into a central location, maybe inside a package object.
If possible, avoid using SessionVars completely.
SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.
How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).
If I have a function (say messUp that does not need to access any private variables of a class (say room), should I write the function inside the class like room.messUp() or outside of it like messUp(room)? It seems the second version reads better to me.
There's a tradeoff involved here. Using a member function lets you:
Override the implementation in derived classes, so that messing up a kitchen could involve trashing the cupboards even if no cupboards are available in a generic room.
Decide that you need to access private variables later on, without having to refactor all the code that uses the function.
Make the function part of an interface, so that a piece of code may require that its argument be mess-up-able.
Using an external function lets you:
Make that function generic, so that you may apply it to rooms, warehouses and oil rigs equally (if they provide the member functions required for messing up).
Keep the class signature small, so that creating mock versions for unit testing (or different implementations) becomes easier.
Change the class implementation without having to examine the code for that function.
There's no real way to have your cake and eat it too, so you have to make choices. A common OO decision is to make everything a method (unless clearly idiotic) and sacrifice the three latter points, but that doesn't mean you should do it in all situations.
Any behaviour of a class of objects should be written as an instance method.
So room.messUp() is the OO way to do this.
Whether messUp has to access any private members of the class or not, is irrelevant, the fact that it's a behaviour of the room, suggests that it's an instance method, as would be cleanUp or paint, etc...
Ignoring which language, I think my first question is if messUp is related to any other functions. If you have a group of related functions, I would tend to stick them in a class.
If they don't access any class variables then you can make them static. This way, they can be called without needing to create an instance of the class.
Beyond that, I would look to the language. In some languages, every function must be a method of some class.
In the end, I don't think it makes a big difference. OOP is simply a way to help organize your application's data and logic. If you embrace it, then you would choose room.messUp() over messUp(room).
i base myself on "C++ Coding Standards: 101 Rules, Guidelines, And Best Practices" by Sutter and Alexandrescu, and also Bob Martin's SOLID. I agree with them on this point of course ;-).
If the message/function doesnt interract so much with your class, you should make it a standard ordinary function taking your class object as argument.
You should not polute your class with behaviours that are not intimately related to it.
This is to repect the Single Responsibility Principle: Your class should remain simple, aiming at the most precise goal.
However, if you think your message/function is intimately related to your object guts, then you should include it as a member function of your class.