What is a good way to design a class? I'm trying to create a simple chat program. I want everything the objects in the screen use to be encapsulated. I've created a few classes, a logging class, a message pile class (for holding the messages which have been received and sent), a textbox class, and a button class. I want the message pile, the textbox, and the button to share the same string variable, except I want it encapsulated within the classes.
I did try creating a Base class. This would hold all the data and functions common to the textbox and button classes. Those three classes would derive from Base to use its shared variable. Only when I did this the variable was not shared. Is there a way to do this? Kind of like a global variable? Only within its own class and its derived ones? Both objects of the two derived classes should be able to access the Base class object's variables.
You are mixing up classes and objects. When you have a base class with some member variable then all derived classes can (potentially) access the member variable in the base class.
However when you instantiate the different derived classes, or one of them multiple times, then each object has a complete independent set of member variables, including the ones from the base class, because that's exactly what an object is.
If you want certain groups of objects to use the same "shared" variables then you could stick these shared things into a dedicated "shared" class. Then for each group of objecst that need to share these "variables", you create an instance of this "shared" class, and pass it to all of the objects in the group.
This is also more flexible than fiddling around with "static" class members, or whatever they are called in the language you are using, because you can have multiple of these "groups" of objects by having multiple "shared" objects and deciding exactly which "actual" objects share the same "shared" data/variables.
Without knowing more about what's going on it's hard to give any more recommendations on how to design the class and object hierarchy.
Related
C# 9 introduces record reference types. A record provides some synthesized methods like copy constructor, clone operation, hash codes calculation and comparison/equality operations. It seems to me convenient to use records instead of classes in general. Are there reasons no to do so?
It seems to me that currently Visual Studio as an editor does not support records as well as classes but this will probably change in the future.
Firstly, be aware that if it's possible for a class to contain circular references (which is true for most mutable classes) then many of the auto generated record members can StackOverflow. So that's a pretty good reason to not use records for everything.
So when should you use a record?
Use a record when an instance of a class is entirely defined by the public data it contains, and has no unique identity of it's own.
This means that the record is basically just an immutable bag of data. I don't really care about that particular instance of the record at all, other than that it provides a convenient way of grouping related bits of data together.
Why?
Consider the members a record generates:
Value Equality
Two instances of a record are considered equal if they have the same data (by default: if all fields are the same).
This is appropriate for classes with no behavior, which are just used as immutable bags of data. However this is rarely the case for classes which are mutable, or have behavior.
For example if a class is mutable, then two instances which happen to contain the same data shouldn't be considered equal, as that would imply that updating one would update the other, which is obviously false. Instead you should use reference equality for such objects.
Meanwhile if a class is an abstraction providing a service you have to think more carefully about what equality means, or if it's even relevant to your class. For example imagine a Crawler class which can crawl websites and return a list of pages. What would equality mean for such a class? You'd rarely have two instances of a Crawler, and if you did, why would you compare them?
with blocks
with blocks provides a convenient way to copy an object and update specific fields. However this is always safe if the object has no identity, as copying it doesn't lose any information. Copying a mutable class loses the identity of the original object, as updating the copy won't update the original. As such you have to consider whether this really makes sense for your class.
ToString
The generated ToString prints out the values of all public properties. If your class is entirely defined by the properties it contains, then this makes a lot of sense. However if your class is not, then that's not necessarily the information you are interested in. A Crawler for example may have no public fields at all, but the private fields are likely to be highly relevant to its behavior. You'll probably want to define ToString yourself for such classes.
All properties of a record are per default public
All properties of a record are per default immutable
By default, I mean when using the simple record definition syntax.
Also, records can only derive from records and you cannot derive a regular class from a record.
Are interfaces a layer between objects(different objects) and actions(different object types trying to perform same action)? and Interface checks what kind of object is it and how it can perform a particular action?
I'd say that it's better to think of an interface as a promise. In Java there is the interface construct that allows for inheritance of an API, but doesn't specify behavior. In general though, an interface is comprised of the methods an object presents for interacting with the object.
In duck-typed languages, if an object presents a particular set of methods (the interface) specific to a particular class, then that object is like the specifying class.
Enforcement of interface is complicated, since you need to specify some set of criteria for behavior. An interesting example would the design-by-contract ideas in Eiffel.
Are you asking about the term "interface" as used in a specific language (such as Java or Objective-C), or the generic meaning of the term?
If the latter, then an "interface" can be almost anything. Pour oil on water -- the line between them is an "interface". An interface is any point where two separate things meet and interact.
The term does not have a rigorous definition in computing, but refers to any place where two relatively distinct domains interact.
To understand interfaces in .net or Java, one must first recognize that inheritance combines two concepts:
Implementations of the derived type will include all fields (including private ones) of the base type, and can access any and all public or protected members of the base type as if it were its own.
Objects of the derived type may be freely used in place of objects of the base type.
Allowing objects to use members of more than one base type as their own is complicated. Some languages provide ways of doing so, but there can often be confusion as to which portion of which base object is being referred to, especially if one is inheriting from two classes which independently inherit from a third. Consequently, many frameworks only allow objects to inherit from one base object.
On the other hand, allowing objects to be substitutable for more than one other type of object does not create these difficulties. An object representing a database table may, for example, allow itself to be passed to a routine that wants a "thing that can enumerate contents, which are of type T (IEnumerable<T> in .net)", or a routine that wants a "thing that can have things of type T added to it" (ICollection<T> in .net), or a thing that wants a "thing that wants to know when it's no longer needed (IDisposable in .net)". Note that there are some things that want notification when they're no longer needed that do not represent enumerable collections, and there are other things that represent enumerable collections that can be abandoned without notification. Thus, neither type of object could inherit from the other, but if one uses an interface to represent "things which can enumerate their contents, which are of type T", or "things that want to know when they are no longer needed", then there's no problem having classes implement both interfaces.
I'm building a (very) simple FTP app in Cocoa, and I need to store information on the different types of servers that are supported. So, I've created a ServerType class, which stores all of the relevant information about a single type of server. I then have a ServerTypes class which is designed to manage all of the ServerType classes that are created.
My question is, how to set up the relationship between the two objects. Is there a preferred method to do so?
Also, since Objective-C doesn't support non-instance classes, where should I create an instance of ServerTypes that will have to be used throughout the entire program? Or is there a better way to do that? I need it to be KVC compliant so That I can bind one of the ServerType properties to an NSPopupBox.
I'm fairly new to Cocoa and Objective-C.
To manage a relationship between 2 objects, you have 2 ways: composition or inheritance.
You can inherit from a class to create a subclass then you will have a is-a relationship.
If one object contains another as an instance variable then you will have a has-a relationship.
Here, I think it would be the best to use composition where the ServerTypes objects has an array of all server type objects. Objective-C supports non-instance variable (if that's what you mean), by creating static variable. Then you can use it accross the whole program
What do you do with classes that have no member data, only methods?
Do you make them static?
In my case it is an repository class that executes queries against the database. Maybe I got the repository pattern wrong... (It does implement an interface)
Inherit from an Interface mean that you cannot use static. Simply create a class and instantiate it.
If it implements an interface, and gets passed around as that interface, then you can't make the members (or the class) static. The interface aspect means that although an instance won't have any actual fields, it still contains valuable information - its type.
You might want to make it a singleton, but there's no particular need to.
Why won't you make a database wrapper class, that maintains the connection to database opened/closed. Moreover, it can also open it automatically if new query is sent. You can include the functions your class has, running them right on the inner pointer to the database.
I guess this is the best database management pattern. If you use it, you should make a Factory method that returns the object of this class initialized on some specific database. Then you pass that object around.
Or if you are lazy and sure that you will need only 1 database, make it a singleton.
It depends. Most of the time it might be possible to make the class static, but sometimes you need to pass an instance of it around. Sounds like you might be having this situation. In this case perhaps you should consider a Singleton pattern, since more than 1 instance of the class is not likely to be needed?
I want to create properties dynamically, when the user retrieves the instances of my class.
Implementation in c++, but Put can't create properties on the fly.
Can someone point me to the function(s) I need to use to "fill" a empty class on the fly with properties and values.
I'm not sure you can, or at least not directly, as WMI classes need to be pre-defined. However you could associate with multiple instances of a WMI class which has Name and Value properties.