Dave Bloomberg wrote:If anyone has any advice to give about how I write my code or how I create methods : Please do not hesitate to insert this comment , if you do find a big mistake, feel free to harras me
Ok, since you asked...
Let me preface my comments with this: Learn to sniff out Code smells
and when I say that the code is smelly, it's nothing personal. Rather, it's all about the code. You might also want to take a look at the 10 Commandments of Egoless Programming
because when you ask for critiques of your code, it's best that you put yourself in that mindset.
With that said, let's begin.
The biggest and most glaring smell in the code is the prevalence of static methods. When there are more static method than there are instance methods in a class like Hospital
, that raises a red flag and a big sign that flashes "Procedural code ahead!"
Indeed, there are many indications that you still have a way to go in terms of understanding object-oriented programming.
Here's one example:
Instances of a class like Appointment
should represent a single appointment. As such, an Appointment object should know only about one particular appointment and exhibit behavior pertaining only to that particular appointment. Yet, this method will print information about all
appointments. This kind of responsibility should not be given to any particular instance of an Appointment. If you're going to have some kind of abstraction that knows about multiple Appointment objects, I would think that something like a Schedule
would be more appropriate.
Moreover, the list of appointments isn't even something that an Appointment object manages. It's just given the list of Appointments and told to print them all out. That's another indication that the printAppointment()
method does not belong in the Appointment class. An instance method should represent behavior that is specific that a particular instance of the class. Instance methods should use one or more pieces of information that the instance manages. If it doesn't, then you have to question why that method is an instance method at all.
Object orientation is about behaviors and responsibilities and assigning those to an appropriate abstraction so that the job of managing the information related to those behaviors and responsibilities can be abstracted and encapsulated within the object. Externally, you should have not have to care about the details. All you should care about are the results.
Here's how I would have designed some of the interactions you're trying to represent:
The Schedule class would look something like this maybe:
One key to thinking and designing in a more object-oriented manner is to regard objects as things that you can delegate small, focused jobs to. Information that relates to that job should be managed by the object itself. Things that the object needs to perform its job would be passed in as parameters. Parameters can be things like collaborators (like the System.out object passed to the printTo()
method above) or values that may vary the behavior of an object in some way.
I'll pause here for now to let you digest some of this feedback.
I still have a lot more though.