[Tutor] Help on Software Design decisions

[Alan Gauld]

On 29/11/16 02:02, Juan C. wrote:

>>> I have to build my own Moodle API to be consumed by my program,

I just noticed the last bit.
Is this a client side API or a server side API?
In other words are you building a set of services on the
server or are you building a module that makes it easy
for client side programs to access the server? I had
assumed the first but your responses make me think it
is probably the second.

> Well, basically get program information like title, id and units, within
> units get title, id and courses, within courses get title, id, assignments,
> and within assignments get title, id, due date and grade. 

For a client side API where you just populate the data that's not
unreasonable, the operations are more likely to be things like
open(), close(), read(), write()(), refresh(), etc.

> program to automate the process of getting assignments data and putting
> them on Trello and keep them up-to-date.

I've no idea what Trello is.

>> OK, Have you heard of CRC cards? These might be helpful here in
> 
> No, never heard about it...

They are a simple and concise way of recording requirements
(and some design) details for an OOP system. They may be less
useful in your scenario where you probably wind up with one
class doing most of the work and the others using it.

>>> - Inside Program init there would be attributes title, id and units;
> inside
>>> Unit init there would be attributes title, id and courses; inside Course
>>> init there would be attributes title, id, due_date, submitted, grade.
>>
>> The attributes are there to support the operations. What are the
>> operations (ie the responsibilities) of the classes. 

It doesn't sound like you know that yet. Once you have a
program to build using these classes you can add operations
to them. At the moment you are in the unfortunate position
of building a dumb API to some data. The functionality
you are hiding is infrastructure not application level.


>>> user = User('john.smith', 'password')  # will get all data needed
>>> user.program  # <Program 'Computer Science' (10260)>

> Well, I'm trying to illustrate how the program would work. The parse would
> occur inside User, there I would call the site using requests and scrap
> data from it using bs4. I would get the username and password provided and
> use requests + bs4 inside User to login and keep session. 

OK, In that case you possibly want to call your class
Users since you seem to intend to fetch all User objects at once?
Or is the User ID doing double duty as a security token for
the server and as a key into the data? Or should it look like:

user = User(loginID, passwd, userID)

> The second line,
> and all of them for that matter, are just illustration. 

The problem is that they don't do anything. In the interactive
interpreter they would print the values but in a real script the
line

user.program

Does nothing useful, it would need to be part of an assignment:

program = user.program

But since program is itself a class do you need to go back
to the server to fetch that program data? Or are you going
to slurp it all up with the call to the top level user?
If you fetch it as needed then your program attribute
probably needs to become a method

program = user.program()

Where the method fetches the program details from the
server and returns a Program object.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos