The Controller class provides two ways of handling events: the listeners and control configs. Why do we need control if the class already implements Observable? Is there a reason to prefer one over the other?
Related
I am developing an application in which one part is a logging mechanism. I have defined a business logic when in every setter of each class an event is raised with the reference to the object that was changed and old value of the changed attribute. I have created a class called Logger that listens to that events and creates a log.
But, I don't want to have a event handler for each of the events. I would like the Logger to catch events, which parameters is an interface, let's call it 'Logging'. So from Logger's point of view, the logging would be unified.
The question is, how to use this Logging interface. I don't want my business classes to implement it. Could you give me some ideas what would be the best approach to do this in a nice OO design?
Thank you.
I am reading about SOLID principles and I stopped here on "Dependency inversion principle" which means the objects should passed already instantiated to anther object, which means composition cannot be applied with Dependency inversion principle am right? or there is something I miss?
UPDATE **************************************************
suppose you have a class and this class has an attribute which is reference to anther object, we have 2 solution(for me):
Create the object outside the class and pass it to the class.(Dependency)
Create the object inside the class it self(composition).
thank you.
Your confusion comes from your understanding of composition. The object that is owned by another is dependent of the lifetime of the owning object. That doesn't mean that you have to create the owned object inside the owning class.
If you create objects in a class, this class is tightly coupled to the created class. You can't exchange the implementation without changing the class which creates the other.
Example:
In the picture above you have the class Client, which uses the class Server. Lets say this is a composition and the Client has an attribute of the type Server.
If you create an instance of the class server inside the client class, it could look like this:
public class Client {
private Server server;
public Client(){
this.server = new Server();
}
}
Now lets say you want to exchange the implementation of the Server. You need to change the implementation of the Client class, because the only way to exchange it, is to create an instance of another class (maybe called AnotherServer).
public class Client {
private AnotherServer anotherServer;
public Client(){
this.anotherServer = new AnotherServer();
}
}
This shows you, that the Client class is highly dependent of the class Server.
To easily change the used implementation of the Server and thus modify the Client's behaviour it would be better to compose the Client out of abstractions (abstract classes or interfaces). Doing so means you can't create the needed object in the owning class, because you can only create concrete classes. Creating classes means calling the constructor and being dependent of that class which was created.
A better way to achieve composition (– the Client is composed out of a Server –) is by injecting it through a setter method or the constructor. Like this you can hide implementation classes behind an interface.
Example:
In the second picture we protect the Client from the knowledge about the Server's concrete implementation. It only depends on the server interface. This dependency is not that dramatic, because the Client defines the interface. He decides about needed function of the Server interface. To indicate, that the interface for the servers belongs to the Client it is called "ClientServer".
To compose your Client you have to create the concrete classes for the ClientServer interface outside the class and inject it through the constructor or a setter method.
...
FirstServer first = new FirstServer();
Client client = new Client(first);
client.setServer(new SecondServer());
...
Like this you can easily exchange the used Server implementation in the Client, even at runtime.
This mechanism is called the dependency inversion principle (DIP). But Why? The Client class is still dependent of the server interface. If the interface changes, the Client has to change too. Yes, this is correct. But the Client decides which functions he needs in that interface. So normally the interface changes, when the Client says that it needs to be changed. The interface changes because the Client changes.
Because the concrete servers "FirstServer" and "SecondServer" implement the interface ClientServer they are dependent of that interface too. And because inheritance is a stronger dependency than the composition, the concrete server classes are more dependent of the interface than the Client class.
That's why the dependencies are inverted. The concrete server classes now depend on the "Client-ClientServer"-conglomerate.
So the answer to your question is: You can't reach DIP when you create your class inside another class. But you can reach DIP with composition by defining an interface an injecting the concrete classes which inherit this interface.
Taken from Wikipedia:
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
And you said:
which means the objects should passed already instantiated to another object
Dependency Inversion principle has nothing against a programming implementation detail like class constructors, which are meant to initialize the object being constructed.
Unless you define constructor parameters typed as implementations rather than abstractions, and/or the dependencies being injected are of a higher layer than the target dependency, you're not violating the whole principle.
Suppose Class1 and Class2 use same method method1. In that situation I can use protocol. Instead of protocol I can declare a super class called Superclass and implement method1 in that class. Now i can extend Class1 and Class2. After that I can use method1. So why I need protocol? and what is the advantage of using protocol?
Objective-C doesn't have multiple inheritance, but you can implement multiple protocols. Consequently, protocols give a contractual guarantee (which is checked by the compiler) that the class implements the desired methods, but without demanding that a particular ancestor class be in the inheritance chain.
Protocols are used for sending the messages from one object to another. In addition to this it define a list of required and/or optional methods that a class implements. If a class adopts a protocol, it must implement all required methods in the protocols it adopts.
Refer the below example when to use protocol:-
Consider you have one window which contains two ViewController class named as colorWellViewcontoller and chartReportViewController. Now colorWellViewcontoller class has one action method connected to the colorWell, which will trigger when user change the color. Now you want if color well color has been changed then same color should be applied in your chartReportViewController charts.
So in the above scenarios, You want to send the message e.g. color info to the another view controller whenever action method is called. So in this case you can use protocol.
What is the best (read: most technically correct) way to handle GUI's for class objects?
Say, for example, that I have a class to deal with I/O. Let's call it clsIO. I also have a form to allow the user to change various options/properties of this class, let's call it frmIO. The frmIO GUI is specific to the clsIO, it will not be used anywhere else in the application.
My application will always create an instance of the clsIO, it will load its default settings and begin its operation. The user may or may not need to show the frmIO 'settings form' so that he can configure it.
To me, it appears that the best way to handle this is to store an object reference to the form inside the class, and provide a ShowConfigForm() method, rather than instantiate the form, which in turn instantiates the class.
Is this sound design?
EDIT
I plan to reuse this class/form combo across multiple projects. I have already developed it in its own project, so i can easily transfer/import to other projects that may require it.
Simple pseudo code with my current design:
class clsIO
{
public bool Active{get;set;}
public int Port{get;set;}
public ShowConfigForm()
{
frmIO settings = new frmIO(this);
settings.Show();
}
}
class frmIO
{
private clsIO _IO;
public frmIO(clsIO IO){_IO = IO;};//constructor
private btnEnable_Click()
{
_IO.Active = true;
//etc etc
}
}
Here I only need to instantiate the clsIO. Not the other way around.
The way you've done, there's a tight coupling from clsIO to the frmIO ( which is the GUI class). This is not a good practice as this tight coupling will stop you form doing Unit Testing etc.. also in case you need clsIO to be re-used for some other operation, this tight coupling to fromIO stops you from doing so.
There need to be another class that puts them together by first instantiating the clsIO and then frmIO by passing the clsIO instance into frmIO.
This way you separate the concerns of each class and give the responsibility of wiring thins up to another one, which would be cleaner.
Furthermore you can improve the design by extracting an interface from clsIO class and using the interface type within the frmIO to refer to clsIO. this will help you to have a loose coupling bewteen the 2 classes.
let me know if you me to provide a code sample, if what I described doesnt make much sense.
Usually you would have a class containing the configuration. The form itself has a reference to that settings class. If the user changes a setting in the form, the form tells it to the settings class/object.
Now you can register your clsIO as an observer on the settings. Meaning whenever something changes, the clsIO gets notified and can update its operations (this way around, the settings would contain references to all of its observers). This is known as the observer pattern. Has its strength if many 'unknown' objects observe something. I mean, settings may be something, which would impact on many different classes/objects. The observers only decide on the settings, but never change them.
If you want to keep it simple, without much effort, just add a reference to the settings in your clsIO. It's a design you can choose. This one is simpler, so if its a small and simple application, it should be sufficient.
But what I think you should really do is, separate the form from the values. A form is just a view, while the actual values are contained in another class.
I'm attempting to map an entity hierarchy using NHibernate almost all of which have events. When attempting to build a session factory however, I get error messages similar to the following:
Core.Domain.Entities.Delivery: method
remove_Scheduled should be virtual
Delivery is an entity in my domain model with an event called Scheduled. Since events cannot be declared virtual I'm at a loss as to how to proceed here. Why would NHibernate need events to be virtual?
Public members must be declared virtual if you use lazy loading because NHibernate will create proxy objects for your entities at runtime. So do not use lazy loading or just declare the event as virtual - that is not so common, but it is possible.
NHibernate creates proxy classes for all lazy loaded entities and uses them where an entity is referenced but not yet loaded. Accessing this proxy triggers loading the real entity from the database. This approach requires to inherit from your entity class at runtime and override the public members hence this members to be virtual.
And there is another solution. You can add proxy="ISomeInterface" to the class declaration. Then you do not need virtual members while proxys just implement the given interface.
I have experienced the same problem with implementing INotifyPropertyChanged on my lazy loaded objects. The problem is that you actually deal with two different .NET instances so that when you fire the NPC event in your real instance you will not receive it from any reference to the proxy. Making it virtual allows the proxy to 'forward' this event. Unfortunately defining events as virtual/overridable is not possible in VB.NET (2005) and hence we had to introduce a C# project with a base class implementing only these virtual events just to get around the VB issue. see also https://forum.hibernate.org/viewtopic.php?f=25&t=990162&start=0
If there are other ways I would be keen to know myself since our method makes proxies a bit less transparant than they should be. Also in the area of auto reconnecting the session when lazy loaded objects need to be initialized seem a bit of a pain.
Regards,
Theo
how does your mapping look like ?
Did you map an event ?
I haven't encountered this issue before, but, then again, I always specify the 'lazy=false' attribute on my class mapping, so that my properties don't have to be declared as virtual. (Since i do not like to declare properties as virtual, if my business model doesnt requires this)
<class name="MyClass" table="MyTable" lazy="false">
</class>