2

I'm going to write a simple password manager, which is going to store my accounts encrypted. Here is description of the classes ,
LoginManager - This class will be responsible for authenticating the user, since the data on the harddrive will be encrypted, it will succeed only if the data is succesfully decrypted, the first line of the data file will be [DECRYPTED], so that the program can understand that the data is succesfully decrypted and allow the user to procced to the user interface. Dependecies:

  • DataChecker
  • CryptographyManager
  • StorageManager
  • UserInterface

UserInterface - This class will be responsible for editing, searching, viewing and adding data(accounts). Dependecies:

  • DataManager

DataManager - The responsability of this class is to manage the data, it will containg an tree or hash table of the data. It must be able to search, edit and add new data to the data structure. Dependecies:

  • Data


Data - This class contains the data splitted into fields - ID, accout, comment, password. It should provide proper encapsulation.

DataChecker - The responsability of this class is to verify that the first line of given file is [DECRYPTED], said in another way to check if the data is succesfully decrypted, and encrypted(before closing the program the file must be encryptd).

StorageManager - This class is responsible for reading and writing data from the disk.

CryptographyManager - this class is responsible for storing the cryptography algorithm Dependecies:

  • CryptographyAlgorithm

CryptograpghyAlgorithm - This is interface for different cryptography algorithms, every class should implement methods for encrypting and decrypting.

And here is UML diagram: enter image description here

I think I've made this design over complicated. The program isn't so complicated to make use of any design pattern, so I tried to follow the solid principles. What bothers me the most is that CryptographyManager seems useless. I would like to know if I'm violating the SOLID principles.

  • Never seen interfaces inherit from concrete classes before. – candied_orange Sep 25 '16 at 17:33
  • Just noticed that I've reversed the arrows not only the ones for inheritance... – nameLess Sep 25 '16 at 17:36
  • DataChecker and UserInterface have a curious relationship. – candied_orange Sep 25 '16 at 17:37
  • You meant CryptographyManager, I fixed this also. – nameLess Sep 25 '16 at 17:43
  • 4
    Not sure when we stated doing code reviews here. This questions is totally off-topic and should not have been up-voted. – David Arno Sep 25 '16 at 21:31
1

Either some important SOLID concepts are being missed here or some UML concepts are.

First lets settle on a vocabulary:

enter image description here anotherchris.net: umlcheatsheet

Let me break down the diagram.

For now I'm simply taking the text in the boxes as gospel and trying to reconcile that with what the arrows tell me. They aren't agreeing with each other.

enter image description here

  1. Backwards arrow, the UserInterface does not have a LoginManager or even know it exists
  2. When connecting many objects to one try to do it together
  3. Backwards and wrong kind of arrow <|--- is not for association ...
  4. ---> is
  5. What's the point of even having these interfaces if you talk directly to the implementations? Swap these columns.
  6. Same as 5
  7. Just being picky, since AES isn't one of LoginManager's 4 things let's not mix visually mix it with them. Moving the two UserInterface boxes somewhere above CrytographyManager nicely cleans that up.
  8. DataManager has a one way associate with Data that's been missed.

Also, Interfaces and implementations should not have the same names. The c# people like to put an I prefix on every interface. Others prefer an 'Default' suffix if there is only one implementation or better yet something meaningful.

Infact I don't see what good these single implementations are doing us in this diagram. They don't show any behavioral choices like they would if there were multiple implementations. They just clutter it up. Even if you plan to do it this way, showing me here isn't helping.

UserInterface - This class will be responsible for editing, searching, viewing and adding data(accounts). Dependecies:

This is where a lot of real problems are hiding.

In what way is this a user interface? No users were mentioned in the design of this class. Seems like some DataHandler to me.

Also, how does UserInterface learn of DataManager? You don't have some hinky service locator hijinks or static globals planned do you? Why isn't DataManager in the constructor?

Most importantly, what does UserInterface really do that the other data objects don't do?

  • It's indeed more right to call UserInterface DataHandler, the UserInterface is wrapping up StorageManager(which is missing for some reason...) , CryptographyHandler and DataManager the idea is when the application is closed, the UserInterface class to tell the encrypt all the data from the datamanager, and gve it to the storageManager to write it on the disk. – nameLess Sep 25 '16 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.