I learned that there is a public part and a private part in an Ada specification file (*.ads) and only the public part should be considered of the user of the compilation unit (usually a package).
It is actually not usual to separate the public and private part of the specification in different files?
So, finally, the user of such a package knows about the internals of the packages on specification layer but can not use it. Am I right here?
Thanks and cheers,
Wolfgang
No, Ada does not allow you to separate the public and private part of a package specification.
The original chief designer of Ada, Jean Ichbiah, did some work on a language, which actually separated the public, private (data structure) and implementation parts of a package, but this didn't become a part of Ada.
Also:
The private part and body of a child package can see the private part of its parent.
The specification of a private child package can see the private part of its parent.
... so you can't always just ignore the private part of a package specification completely.
A practical example:
When I write unit-tests, I like to put the test suite in a child package of the package I am testing. That way my test cases are not limited to inspect the public view of the types declared in the package.
Related
Basic concept in DI is that dependency objects should be passed instead of creating them in the dependent object.
Only reasons I could find for this is in this answer:
To hide the construction details of dependency from dependent to make code less ugly.
To facilitate mocking in Unit Testing.
Are there any other reasons?
If not, can you please explain these reasons more to justify DI?
Let's look at the real life example. Let's say you have a car. Car needs an engine.
class Car
{
private $engine;
public function __construct()
{
$this->engine = new V6Engine();
}
}
The car has a dependency on the engine. In this case, the car itself needs to construct a new engine!
Does it make sense?
Well.. NO!
Also, the car is coupled to the specific version of the engine.
This makes more sense.
Someone else needs to provide the car engine. It could be some engine supplier, engine factory... It is not car's job to create engine!
class Car
{
private $engine;
public function __construct(Engine $engine)
{
$this->engine = new $engine;
}
}
interface Engine
{
public function start();
}
class V6Engine implements Engine
{
public function start()
{
echo "vrooom, vrooom V6 cool noise"
}
}
Also, you could easily swap the engine, you are not coupled to the specific engine. That new engine only needs to be able to start.
Martin Fowler has written a very good article about the inversion of control and dependency injection.
https://martinfowler.com/articles/injection.html
Please read it - because he will explain the DI much better than I can do :)))
Also, there is very good video by the Miško Hevery "The Clean Code Talks - Don't Look For Things!". You will be much clever after watching it :)
https://www.youtube.com/watch?v=RlfLCWKxHJ0
I would add that creating the object inside your service hides the scope of your service.
Requiring it as an hard dependency makes it explicit that your service needs an instance of such object in order to work. By making it part of the contract, the dependency is no more an implementation detail.
That also opens for flexibility, you may typehint against e.g. EngineInterface instead of a concrete implementation, meaning that you don't care about what implementation is passed to your service but rely on the contract imposed by the interface (imagine a mailer that send mails for production, but a no-op for testing).
I have been making my C++ functions callable from Qml by following the approach given in Qt documentation.
This require one of these conditions to be fulfilled :
Make the C++ function public and Q_INVOKABLE
or
Make the C++ function a public slot
This sometimes is not in sync with my class design. As in, the function which I want to be callable from Qml, is private according to my class design.
Q1. Can I make a function visible to Qml and still keep it private ?
Q2. Is it my design flaw to expect this kind of behavior ?
Well, if you do something private by design you consider that it's something to be used only within a class. Now you are now asking actually is how can I workaround my design. Obvious answer is - you can make a public wrapper in a class which will invoke your private method and publish this public wrapper into QML, but I would suggest to review design if you face such situation.
if we can access the private members through setters and getters then what is the use of private?
You need the private to enforce Encapsulation. It is one of the fundamental paradigm of Object Oriented programming to keep the implementation of something separate from the interface. This reduces the coupling between your different program parts and in the long run make it more maintainable.
Take the following example :
class toto {
private String someThing;
public String getSomething();
public void setSomething(String Something);
}
If you change above to simply put someThing public, sure you have less code, but if one day that someThing needs to change to a more complex object for some new functionality while the old code could still work fine with a string then you need to change everything. By isolating the internal representation of someThing you can evolve your system much more easily
class toto {
private ComplexSomeThing someThing;
public String getSomething(){ someThing.toString();}
public void setSomething(String something){ something = new ComplexSomeThing(something);}
public ComplexSomeThing (getComplexSomething();
public void setComplexSomething(ComplexSomething someThing);
}
There are other reasons that makes encapsulation a Good Thing (tm), this is just a silly example to illustrate the point.
EDIT
There is somewhat of a debate right now as to using protected vs private or to use concepts akin to properties in some languages (Delphi, C#) rather than getters and setters (as in Java).
Protected rather than private will allow easier changes by the clients of the code but it does expose the innards of your system more so there is a balance to strive for between usability of the API and it's maintainability. However the basic principle of encapsulation remains.
Whatever the option chosen one still needs to expose functionality that is coherent and on the same level of abstraction and hide the gory details of how this is done.
To me the debate is not to declare a jihad against private but to find a way to provide extensibility and flexibility while not breaking the coherence of the API.
Here some interesting reading about private if you want to dig further. However I must stress that before forming an opinion about private you should really master the concepts of encapsulation and polymorphism, their apparent simplicity does hides some subtle complexities.
Because the getters and setters can act as a proxy. They make it so that you can hide the actual insides of the class, and only let the outside classes access the data through methods. Allowing you to treat the inners of the class however you want.
Just because your getter/setter is named getName() and your property is called name, doesn't mean it will always be that way.
What if you wanted to change the variable to be fullName. If you directly accessed public variables, the change would break a lot of code. Instead, you can simply remap where getName() retrieves its data from.
One of my best examples of this is my own URL class, where I allow for creating and manipulating a URL. If you want to set the scheme, you can get $obj->setScheme(). However, you don't know whether I am manually making the string every time you change the URL, whether I am storing them as separate parts. This gives me flexibility as I can store your data however I want to.
Furthermore, I can preform manipulations on the data before storing it. In my URL class, I assume that all schemes and host names are lowercase. I can standardize this by converting all strings saved via setHost() to lowercase, and then storing them. If I used a public variable, you would have to assume that the client that put the data in was correctly storing it.
They can also validate information that is being passed in to make sure that it is valid data, and cause an error if it isn't.
No one forces you to put in getters and setters for every variable. Indeed, blindly using private members + dummy getters & setters for every variable is pointless, even though many "object oriented encapsulation" tutorials do this all the time for some reason. For one thing, such encapsulation is no encapsulation from concurrency viewpoint.
I think what you really want to understand is why we use public properties with private backing fields, instead of just using public fields. There are several questions on SO like this; here's one:
What is the difference between a Field and a Property in C#?
I think you have good answers so far (information hiding and all that). Just want to add a suggestion about using setters.
As you mentioned using accessors makes private variables a bit pointless and in some environments performance consequence of using getters and setters just makes it worthless.
On the other hand if you don't have such concerns, I think using getters isn't so bad, but you should think twice before using setters. They make your object mutable which is especially hard to maintain in concurrent environments.
What's the best object layout in ASP.net or at least.. what are the advantages and disadvantages of either case:
Public Class Dog
Public Breed as String
Public Type as String
Etc....
OR the use of properties and keeping variables private
Somewhat of a debate among our team about it. Just wanted to hear thoughts.
Never expose fields directly.
Use properties with private backing fields. This allows you to change implementation and to encapsulate logic around getting/setting them.
See what the Visual Basic Team have to say on this.
Also, read about the differences between fields and properties.
I am developing a dynamic mocking framework for Flex/AS3 and am having trouble with private/support types (ie. those declared outside the package {} in a class file).
In my ABC "file", I am declaring the instance with the PROTECTED_NAMESPACE class flag and with a PRIVATE_NS multiname. I have also experimented with giving it the same namespace as the class it is subclassing (eg. PRIVATE_NS("ContainerClass.as$123")).
No matter what I do, I always get the following error after loadBytes:
VerifyError: Error #1014: Class ContainerClass.as$123::PrivateClass could not be found.
I have experimented with loading the generated bytecode into the same ApplicationDomain as the private class (I use a child domain by default). I even tried registering a class alias before the load (though that was a bit of a stretch).
Am I forgetting anything or is it simply a restriction of the AVM?
Please note that I am fully aware that this is illegal in ActionScript 3.0, I am looking for whether this is actually possible in the AVM.
Edit: For those interested in the work so far, the project is asmock and is on sourceforge.
I'm no expert with ABC files but I just don't think this is possible in the AVM2. I did several tests a while ago with the AS3 Eval lib and they all failed.
Related to dynamic mocking, I have filed an issue in Adobe bugbase, asking for a dynamic proxy mechanism: http://bugs.adobe.com/jira/browse/ASC-3136
I'm not sure what you mean by PRIVATE_NS("ContainerClass.as$123"), My reading of avm2overview.pdf 4.4.1 is that private namespaces are not permitted to have a name, hence that the "<class name>$<number>" namespace in debug output is generated for your convenience. I would assume that would mean you would have to hack your abc into the same abc tag in the source swf to access the namespace constant index (and that sounds too much like hard work to me!)
I haven't actually managed to generate a loading swf, though, so take this with a grain of salt.
Having gone back to look at this problem in ernest, I can definitively answer this question: private classes can only be referenced from the LoaderContext that loaded them
I have been able to add support for private interfaces by reproducing the interface in the loaded ABC 'file', but it cannot be coerced/cast back to the original private interface.
This is still useful for my requirements, as a private interface can be used to combine multiple interfaces.