I have a class that generates a text file.
It is very simple class that has methods for:
creating file,
opening file
closing file
saving file
writing to file
etc
etc
There are some options i use when writing my text to file such as font size, color and max words.
These options are passed to the constructor.
Should I split this class in to two seperated classes:
fileMaker
fileMakerOptions
and use fileMakerOptions object hold responsibility for text size etc and pass to the constructor of fileMaker?
or would it be best to have file maker encapsulate everything related to making the file including the style options
If your class is simple. And if there are only few options. Then no, you should not create new class. Overrefactoring is very bad.
You should provide more information about your main class responsibility as far as count of options you want to handle. Anyway - the general idea of creating new additional instances is delete options handling responsibility from your main 'class' responsibility.
For me I decide, if the amount of options greater then 4-5 - then I creating separate option entity.
I only split up classes when an existing class becomes too difficult or gettign too many properties of functions OR when I know beforehand that it will be extended a lot.
In your case it depends on the complexity and amount of functions/properties.
Related
I've created the custom class ZMaterial that can be instantiated passing an ID to the constructor which sets the properties for a single material using SELECTs and BAPIs. This class is basically used to READ and UPDATE a single material.
Now I need to create a service to return a list of materials. I already have the procedural code for it in a static method (for now actually a function module), but I would like to keep using a full OOP approach and instantiate a list of my custom material object. The first approach I found is to enhance the static method to instantiate a list of my single material object after the selects are executed and I have the data in internal tables, but it does not seem the most OOP.
The second option in my mind is to create a new class ZMaterialList with one property being a list of objects ZMaterial and then a constructor with the necessary input parameters for the database select. The problem I see with this option is that I create a full class just for the constructor.
What do you think is the best way to proceed?
Create a separate class to produce the list of materials. The single responsibility principle says each class should do exactly one thing. In all but the most simple cases, using a thing is a different responsibility than producing it.
Don’t make a ZMaterialList class. A list’s focus would be managing the list items, i.e. adding, removing, iterating, sorting etc. But you should be fine with a regular STANDARD TABLE OF REF TO ZMaterial.
Make a ZMaterialReader, -Repository, -Query or -Factory class or the like, depending on the precise way you want to produce the ZMaterials. Readers read by keys, repositories read and write, queries use varying sets of selection criteria, factories instantiate with possibly different sets of inputs.
You can well let that class use the original FUNCTION underneath. It’s good style to exploit what’s already there. Just make sure you trust that code, put it in a test harness, and keep it afar from the rest of your oo code.
Extract all public interaction of ZMaterial to an interface and use only that interface. That allows you to offer alternative implementations of ZMaterial, ones that differ in the way they are produced or how they store their data.
Split single production from mass production. Reading MARA to retrieve a single material is okay. But you don’t want thousands of ZMaterials reading MARA individually - that wrecks performance.
Now you’ve got the interface, you could offer a second implementation of ZMaterial whose constructor receives all relevant data and relies on it already having been validated to avoid additional SELECTs.
You could also offer an implementation that doesn’t store its data at all but only stores pointers to rows in internal tables somewhere else. See the flyweight pattern for ideas.
If you expect mass updates on the materials, such as “reclassify all of these as B”, consider extracting these list-oriented operations to separate classes as well.
In a given domain, there can be multiple file formats representing similar objects or structures. For example, an object of type Track (meaning a sequence of geographical points) can be saved in .GPX, .KML, GeoJSON, WKT, ShapeFile, etc.
So, my class Track is supposed to read and save its data from files, which can be in different formats.
Question is:
Should my class implement the methods to read from each file type (that is, "know about" them), or should it use other classes, where each class would contain logic to interact with implementation details of each file type? What is the standard practice?
The first option would be coded like this:
trackCollection.Add(Track.loadFromGPX(gpx_fname))
trackCollection.Add(Track.loadfromKML(kml_fname))
# ...and so on with other filetypes
while the second option would probably be:
trackCollection.Add(GpxReader.getTrack(gpx_fname))
trackCollection.Add(KmlReader.getTrack(kml_fname))
It seems to me that some characteristics involving Single Responsability Principle, Information Hiding, and interdependence between classes might make one approach better than the other, but I am not experienced enough to figure which one, if any.
Considering that each file type may need to be parsed with a completely different library and logic, I would certainly prefer the second method (separate classes).
I would only use a "loadFromXXX" method for supporting arguments with different datatypes or methods that will share a lot of code. For example, in C++, you might have loadFromFile(std::ifstream& input) and loadFromString(std::string& str). loadFromFile() may end up parsing the file into a string and call loadFromString or it may parse the file line by line and just share some of the parse functions used in loadFromString.
In any case, it appears that the file formats you listed have very little in common and some (such as KML vs GeoJSON) require completely different parsers. As a result, there should be a separate "reader" or "parser" class for each file type. Otherwise you are bloating class Track and it will have very low cohesion. Separation of concerns would also suggest you split the parsing into another class.
Is it a good practice to define a category within the same .h/.m files of another class? I know it will build with no error and be exactly the same as if it was defined separately.
The main reason I want to do this is because I'm working on an open source control and I want it to have a single .h/.m file.
In general, the biggest problem with combining multiple classes and categories into the same header/implementation is impaired searchability. When a class is in a file with another class, the file name will no longer reflect the fact that the header/implementation contains your other class, making it much harder for others to look for your class.
If your project is small and self-contained, however, the searchability is less of an issue. When there is only one file to search, there is no question of where each particular piece of code is: it's all in that one file. It sounds like your project is both small and self-contained, so I see no problem in placing all code in a single source file if you want it that way.
Another alternative could be placing each class and category in a separate header/implementation pair of files, and then defining a header that includes them all. This would let you keep an ideal project organization, and let your users include a single header to use your component.
If you need this category in just one place I’d say that it’s not that bad having the category within the .m file.
Obviously, if you need that category in multiple places, you should definitely move to its own file: the convention is to name it in this way:
BaseClass+categoryName.{h,m}
e.g.:
NSString+reverseString.h
NSString+reverseString.m
This is purely a coding practice question concerning VB.NET structures. Where do you keep one?
As an example, I've created a structure for the simple purpose of keeping information organized, I'd like this structure to be stand-alone, not belonging to any class so I wouldn't have to access it through SomeClass.MyStructure but rather simply MyStructure. So, do I keep it in a separate class and import it into my namespace? Do I keep it in a module (Static class, essentially)? Do I just make a separate VB.NET code file and place is there (I would like it to live in a separate file). Just to clarify, I need this structure to be accesses by the whole application, not just a single class.
What do you usually do in such cases?
A structure is a Type, much like a Class.
So Yes, put it in a separate file. Then it will be 'in a namespace', the project-default one.
I've had this problem many times before, and I've never had a solution I felt good about.
Let's say I have a Transaction base class and two derived classes AdjustmentTransaction and IssueTransaction.
I have a list of transactions in the UI, and each transaction is of the concrete type AdjustmentTransaction or IssueTransaction.
When I select a transaction, and click an "Edit" button, I need to decide whether to show an AdjustmentTransactionEditorForm or an IssueTransactionEditorForm.
The question is how do I go about doing this in an OO fashion without having to use a switch statement on the type of the selected transaction? The switch statement works but feels kludgy. I feel like I should be able to somehow exploit the parallel inheritance hierarchy between Transactions and TransactionEditors.
I could have an EditorForm property on my Transaction, but that is a horrible mixing of my UI peanut butter with my Model chocolate.
Thanks in advance.
You need to map your "EditorForm" to a transaction at some point. You have a couple options:
A switch statement...like you, I think this stinks, and scales poorly.
An abstract "EditorForm" property in base Transaction class, this scales better, but has poor seperation of concerns.
A Type -> Form mapper in your frontend. This scales fairly well, and keeps good seperation.
In C#, I'd implement a Type -> Form mapper like this:
Dictionary <Type,Type> typeMapper = new Dictionary<Type,Type>();
typeMapper.Add(typeof(AdjustTransaction), typeof(AdjustTransactionForm));
// etc, in this example, I'm populating it by hand,
// in real life, I'd use a key/value pair mapping config file,
// and populate it at runtime.
then, when edit is clicked:
Type formToGet;
if (typeMapper.TryGetValue(CurrentTransaction.GetType(), out formToGet))
{
Form newForm = (Form)Activator.CreateInstance(formToGet);
}
You probably don't want to tie it to the inheritance tree--that will bind you up pretty good later when you get a slight requirements change.
The relationship should be specified somewhere in an external file. Something that describes the relationship:
Editing AdujustmentTransaction = AdjustmentTransactionEditorForm
Editing IssueTransaction = IssueTransactionEditorForm
With a little bit of parsing and some better language than I've used here, this file could become very generalized and reusable--you could reuse forms for different objects if required, or change which form is used to edit an object without too much effort.
(You might want users named "Joe" to use "JoeIssueTransactionEditorForm" instead, this could pretty easily be worked into your "language")
This is essentially Dependency Injection--You can probably use Spring to solve the problem in more general terms.
Do I miss something in the question? I just ask because the obvious OO answer would be: Polymorph
Just execute Transaction.editWindow() (or however you want to call it), and
overwrite the method in AdjustmentTransaction and IssueTrasaction with the required functionality. The call to element.editWindow() then opens the right dialog for you.
An alternative to the Dictionary/Config File approach would be
1) to define a interface for each of the transaction editors.
2) In your EXE or UI assembly have each of the forms register itself with the assembly that creates the individual transaction.
3) The class controlling the registration should be a singleton so you don't have multiple form instances floating around.
3) When a individual transaction is created it pulls out the correct form variable from the registration object and assigns it do an internal variable.
4) When the Edit method is called it just uses the Show method of the internal method to start the chain of calls that will result in the display of that transacton editor.
This eliminates the need for config files and dictionaries. It continues to separate the UI from the object. Plus you don't need any switch statement
The downside is having to write the interface for each every form in addition to the form itself.
If you have a great deal of different types of editors (dozens) then in that case I recommend that you use the Command Pattern
You have a master command that contains the dictonary recommend by Jonathan. That commands in turns will use that dictornary to execute one of a number of other command that calls the correct form with the correct object. The forms continue to be separate from the object themselves. The forms reside in the Command assembly. In addition you don't have to update the EXE to add another editor only the Command assembly. Finally by putting things inside of Command you can implement Undo/Redo a lot easier. (Implement a Unexecute as well as a Execute)