I'm in a state of a design dilemma wherein I'm unable to decide whether an enum should be considered as a part of models or not. The definition I have for models is that they represent knowledge.
With that logic, an enum should be a model. Moreover, I have seen in some codebases that enums are stored as tables in the DB so that the knowledge is stored in the DB itself and can be accessed later for joins, or from code.
What do you guys usually do? For example, if you have a file called models.py which contains models, will you store the enums in it? Or will you create a new file enums.py?
ok under the assumption that models can be understood as classes:
If I design the namespaces and class-structures of a project I usually safe enumerations in separate files like "CarTypes.class", "Color.class" and put it in the same namespaces as the classes which will access those.
But that depends on the accessibility I have to grant other classes towards those enumerations. If only one class uses a enumeration or structure I will not put it in a separate file and rather will define the enum/struct inside the file of that particular class. But if it should be accessible over multiple classes or namespaces I definitely go for the first approach.
Hope that helped a bit. ^^
Related
I am designing a class diagram for an assignment. In this design, I use a separate class called Currency, to define currency values and their functionality. there are at least four other classes have to use this Currency class.
How can I show it in the class diagram ? I mean, do I need to draw relationships (connecting lines) from the Currency class to all the others ?
Is there a better way ?
What am I doing wrong here ?
There is nothing wrong and a reusability of a class is valuable. Actually that's a standard situation.
If you use this class in another class as an attribute you have two options to depict that:
draw an association relationship (line) from the class using to the class that is used.
put the attribute in a proper compartment of a class that is using and as a type of an attribute (after a colon) put the name of the used class.
The benefit of the first approach is that you immediately see the dependency between the classes.
If you use a class but not directly as an attribute type you use other relationship types that suit best to the situation you want to describe.
As I imagine one of your concerns is that you'll have a lot of relationships pointing to your class (in your case Currency). Don't worry about that. You don't have to put everything in a single diagram. Put a full specification of your class on one diagram with those relationships where it uses something else and then put only the class box with a name (without any compartment) on diagrams defining those elements that use your class. It will make your model readable. And with a support of some CASE tool you will be able to see all relationship and dependencies of this class anyway. By the way that's how the UML specification is written. Look for example how Namespace is used in the diagrams there (and many others as well).
Of course I'm not suggesting creating one diagram per one element to define it. No. Collect them in logical Packages (hey - that's exactly what Packages are for!) and make a class diagram per Package. If the Package becomes too large - you might need to split it into smaller subpackages.
For Currency your Package would be probably something like Utils. It can also contain other elements like Date, Address etc. Note - these are typical examples, probably every analyst/designer/programmer sooner or later has to cope with those elements. If you build them well, you'll be really able to reuse them in future applications as well.
One last thought. While you build "package based" Class diagram you might also need a diagram that shows just specific parts coming from several Packages to clarify some bit of your system/business/whatsoever. This is also absolutely fine. Again a benefit of CASE tool here is that it keeps consistency in your model.
There are some constants and enumerations in a project, and each one is used by some other classes.
As a design pattern, is it acceptable to create a class for constants and enumerations definition? Or is there a better way to define and use those constants?
It depends on the problem domain. Generally speaking it is rather standard practice to keep them in Java enumeration. The question is - how would you like to use those constants? I have such experience, that constants being hold in interfaces/enumerations are being duplicated and created over and over again due to lack of the knowledge of developers of past constants. In the result, there are many files as such Constants.java, BusinessLogic.java, AppConstants.java etc.. It causes big overwhelm over the purpose and then you don't know if the some constant, lets say APP_MODE should be used from Constants.java or AppConstants.java ?
One of the solutions is to keep those constants in one (or many?) properties files and inject thme using spring' #Value annotation.
You may group by using some prefixing, building groups separated by dot.
One of the advantages of the property files is that you keep one Java logic of using properties, but you still can provide property file (which may vary depending on application). A lot of flexibility, no redundancy.
Another solution is to create one Service to provide properties / constants from database. You can differentiate the values over diffrent environements, but that's another story.
If I were you I create a constant container class packege by package. Just span the logically coherent parts together. Otherwise you will increase the the coupling and dependency. And the most general constants (problem domain independent ones) take place in the utility package's constant container class.
I know you can generate classes from a CoreData model, but is it possible to code the models first and then generate the xcdatamodeld file from my model classes? Types and relationships would be inferred from the object model.
Meaning, write the code for the classes and get a data model from there? Absolutely not. Forget it. The data model contains more than the model classes, so some details can't be specified in a class declaration.
If you don't like the model editor, it's possible to design your model entirely in code. The model editor is intended as a convenience but is not required. But this doesn't mean designing your classes-- this means writing code that uses NSEntityDescription, NSRelationshipDescription, etc, to build the entire model at run time. I don't know why you'd want to do this, but it's an option.
It's possible that you could write something to generate the structure, but the model holds more information than the classes so it wouldn't do a complete job. Things like deletion rules on relationships. Indeed, knowing whether to create a relationship or a transformable attribute would be rather hard.
What's possible and what's reasonable are two different things. The xcmodel file format is much simpler (and stricter) than Objective-C, but what you're suggesting would require most of an Objective-C parser (including a C pre-processor and everything else). You're virtually asking for something that takes the LLVM IR and outputs the class definitions as an xcmodel. Using Xcode to create a model is generally much less work than writing class interfaces using Objective-C. This sounds like an exercise in pointless misery.
My Problem
I have a class with just a few fields but which represents a relatively complicated data structure. This class is central in my program and over time I found myself adding more and more functionality into it, making things a mess. Since (almost) all of its methods rely on its internal fields, I could not think of a way to move some of the methods elsewhere, even though most methods are independent of each other. How can I refactor this class to make it simpler and reduce the number of methods which are directly implemented in it?
More Information
The class in question represents a sort of automaton. It supports a ton of operations such as retrieving information about it, performing various binary operations between it and other automata, querying for specific information stored inside it, saving it to file, etc. Almost all of these operations depend on the precise implementation of the class - in my specific case I maintain an edge-set-based implementation, but other implementations were also used in the past and might be used again in the future.
Except for a narrow set of basic helper methods which are commonly used, most methods are independent of each other.
The language I am using is Java, but I'm hoping for general answers which could be applied to any statically-typed, object-oriented language.
What I've Tried
I tried refactoring it somehow to multiple types, but each of its operations require access to most of its fields, and I'm hesitant about migrating these operations elsewhere because I can't think of a way to do that without exposing the class's implementation.
I'm also not sure where I should migrate the operations to, assuming they are indeed independent of the implementation. An external utility class? An abstract base type? Will appreciate any input about this.
Perhaps you could remodel the data that your class holds, so that instead of holding the data directly, it holds objects that hold the data? Then you could move the methods that manipulate that data into the new classes, leaving the original class as a sort of container / dispatcher class.
I just want advice on whether I could improve structure around a particular class which handles all disk access functions
The structure of my program is that I have a class called Disk which gets data from flatfiles and databases on a, you guessed it, hard disk drive. I have functions like
LoadTextFileToStringList,
WriteStringToTextFile,
DeleteLineInTextFile
etc
which are kind of "generic methods"
In the same class I also have some more specific methods such as GetXFromDisk where X might be a particular field in a database table/query.
Should I separate out the generic methods from the specialised. Should I make another class which inherits the generic methods. At the moment my class is static as there is no need to have an internal state of the class.
I'm not really OOPing am I?
Thanks
Thomas
If you are using only static static functions you are not really OOPing as you said. It is writing procedural code in OO language.
You should look to create classes which represent objects in your problem domain like File and TextFile. These classes should have operations like DeleteLine, WriteLIne, Load etc.
Also, in which ever language you are programming, it is likely to have a good File IO library. Try to use that in your code as much as possible. If needed just write wrappers over the library classes to provide some additional functionality.
Well, what you seem to have in your code is a Utilities class where you bundle in all the file methods.
This could indicate some design issue but IMHO it is ok, since it is common to have utility classes in OOP designs.
It haves the benefit of being able to add extra methods or modify existing ones easy since you will not have any derived classes extending the Utility class to be affected.
For example java has static methods everywhere. E.g. Collection class.
I would suggest to have the class's contructor be private and have the naming such that is obvious that this is a Utilities class.