CODEWITHSUNDEEP
objectoop
aryaxt
aryaxt

Reputation: 77646

Object Oriented Programming - Best Practice?

Which of the following would you go with? And based on object oriented programming which one is the best practice?

A

Class Note
{
    //Some properties, etc
    public static Note getNoteFromServer();
    public void UpdateNoteOnServer();
}

B

Class Note
{
    //Some properties, etc
}

Class NoteManager
{
    public static Note getNoteFromServer();
    public static UpdateNoteOnServer(Note);
}

Upvotes: 0

Views: 2004

Answers (10)

Michael Caracena
Michael Caracena

Reputation: 1

C

Class Note
{
    //Some properties, etc
    public static Note LoadFrom(Whatever);
    public void SaveTo(Whatever);
}

Upvotes: 0

Robbie Tapping
Robbie Tapping

Reputation: 2556

I would go with "B" Reason why is that you may require "Note" to be used with another type of Controller class, like what you have done for NoteManager. Also gives you the ability to dissociate your Data Objects or DTO's or Model away from your actual controller classes.

Upvotes: 0

jfisher
jfisher

Reputation: 21

It seems to depend on how its going to be used in your program. If Note is the only class or is the parent class for derived classes then there is no point and having a "Manager", Keep It Simple Stupid (KISS). However if the Manager has to deal with other classes via Interfaces then I can see having a seperate class.

Upvotes: 1

guiman
guiman

Reputation: 1334

I think A is better, for 1 reason:

It implements the Object Oriented paradigm to the letter.

The problem i see with B is that a static method that receives an instance of the same class sounds redundant to me because, why would you use a static method to apply behaviour to an instance of the same class? The whole idea behind classes and instances is that Classes are the frame and instances cookies, if you need different cookies, modify your frame and get new ones.

Upvotes: 1

Bevan
Bevan

Reputation: 44337

To take a different viewpoint from my other answer, I'd suggest that your division into Note/NoteManager is the wrong one - not because Note has anything wrong with it, but because the term Manager is a bit of a code smell because it's very generic, inviting the use of the class as a general dumping ground.

If the class is responsible for note persistence, call it NoteRepository.

If it's responsible for validating the content of a single note, move the logic onto the Note.

If it's responsible for creating notes, providing a number of convenience methods for easily creating notes, call it NoteFactory.

And if it's responsible for all of the above, split it into separate pieces because it's doing too much.

Upvotes: 3

Bevan
Bevan

Reputation: 44337

"It Depends"

One of the things it depends upon is the language of implementation.

If you are working in C# or Java, then you'll likely want to go with the Note/NoteManager approach as this gives you the most flexiblity of implementation - because static members in those languages a kind of second class citizens.

To illustrate, in Delphi's original Object Pascal lanaguage, methods and properties that could be accessed without an instance were known as class members, not static members, and they could be virtual, and therefore overridden in descendent classes.

If you're working with a language that provides features like "virtual class (static) members" and a few others, then you might want to merge Note/NoteManager together.

Upvotes: 0

jmpcm
jmpcm

Reputation: 1852

I would say option B. In that way you separate concerns: you have a Note that can be reused anywhere (and not necessarily on a networked application), and you have a manager class that only cares with server communication.

You may also think on implement logic for multiple servers. For example, you may want to comunicate with data formats like JSON or XML. You may implement an interface (example, interface INoteManager) and then implement two classes with servers for each of the data types I mentioned (example, NoteManagerXml and NoteManagerJson).

The main point on this question is sepration of concerns. Hope I've helped! :)

Upvotes: 4

Blender
Blender

Reputation: 298582

I'd choose B, unless you want to end up like poor ol' PHP:

get_note_from_server_and_print_the_response($note, 'PHP, why must you be so disorganized?')

But seriously, it may seem intuitive to do A at the moment, but you'll eventually split A up, as those server operations will require more and more related functions, until you have a mammoth Note class which contains every function in your program...

Upvotes: 0

Cthos
Cthos

Reputation: 985

That's a pretty opinion based question you're asking there.

You're essentially asking (if I understand correctly) whether it is better to have a Class which contains only properties and another class to manage that object (Example B) or to have a class which does everything (Example A).

It really depends. If we're planning on using a MVC kind of framework, Example B would fit better, with Note being your Model, and NoteManager being the controller.

Personally, I would go with a hybrid of A and B, where NoteManager is handling controller actions, but the Model still has methods of its own to do things like managing a singleton instance. So maybe something like this?

Class Note
{
    //Some properties, etc
    public static Note getInstance(noteIdentifier);

    public void saveNote();
}

Class NoteManager
{
    // This handles view validation and calls Note.saveNote();
    public static UpdateNoteOnServer(Note);
}

Upvotes: 1

Pramendra Gupta
Pramendra Gupta

Reputation: 14873

As per my experience best practice is , as long as things are separated DRY is best practice. you can extends note to notemanager

Class Note
{
    //Some properties, etc
}

Class NoteManager 
{
    public static Note getNoteFromServer();
    public static UpdateNoteOnServer(Note);
}

Upvotes: 0

Related Questions